ghc-android icon indicating copy to clipboard operation
ghc-android copied to clipboard

Linking fail with "unsupported ELF machine number 0"

Open Tener opened this issue 10 years ago • 9 comments

I have a problem with ghc-android. Basically whenever I try to link executable (libraries are fine) I get the following error: /home/tener/dokumenty/projekty/mygame/ghc-for-android/ghc-android-joeyh/installdir/.ghc/android-14/arm-linux-androideabi-4.8/bin/../lib/gcc/arm-linux-androideabi/4.8/../../../../arm-linux-androideabi/bin/ld: fatal error: /home/tener/dokumenty/projekty/mygame/ghc-for-android/ghc-android-joeyh/demo/foreign-jni/.cabal-sandbox/lib/arm-linux-android-ghc-7.8.2/foreign-jni-0.1.0.0/libHSforeign-jni-0.1.0.0.a(JNI.o): unsupported ELF machine number 0

This happens both on "clean" Debian stable and on my host Arch Linux system.

This should probably be reported to https://github.com/joeyh/ghc-android since I was building based on stable-ghc-snapshot branch of this repo, but it has "Issues" disabled and this one is upstream anyway, so here you go.

I tried googling this error but I have no clues about why it fails.

Tener avatar May 30 '14 19:05 Tener

I recently ran into this problem too. Did you build your library with cabal? I did. I turned out that the ARM cross compiler wrapper script for cabal did not redefine the "strip" program. I had to add the following flag:

--with-strip=arm-linux-androideabi-strip

I then reinstalled the library and I did not get any more link errors.

sseefried avatar Nov 03 '14 07:11 sseefried

I think what I did was disabling the library stripping altogether. Looks like your fix is more complete. A good question would by: why does the wrong strip is being called at all?

On Mon, Nov 3, 2014 at 8:25 AM, Sean Seefried [email protected] wrote:

I recently ran into this problem too. Did you build your library with cabal?

— Reply to this email directly or view it on GitHub https://github.com/neurocyte/ghc-android/issues/29#issuecomment-61446280 .

Tener avatar Nov 03 '14 17:11 Tener

I think cabal just picks up the first ld it can, which is the host linker for me.

Sean

On 4 November 2014 04:01, Krzysztof Skrzętnicki [email protected] wrote:

I think what I did was disabling the library stripping altogether. Looks like your fix is more complete. A good question would by: why does the wrong strip is being called at all?

On Mon, Nov 3, 2014 at 8:25 AM, Sean Seefried [email protected] wrote:

I recently ran into this problem too. Did you build your library with cabal?

— Reply to this email directly or view it on GitHub < https://github.com/neurocyte/ghc-android/issues/29#issuecomment-61446280> .

— Reply to this email directly or view it on GitHub https://github.com/neurocyte/ghc-android/issues/29#issuecomment-61510184 .

sseefried avatar Nov 03 '14 23:11 sseefried

Is anyone still looking into this? I updated the scripts to ghc 8.0.1 and I'm running into this issue on ARM. It works fine on x86, but ARM cross compilation causes this linker error. I'm using @sseefried's scripts, which do define --with-strip correctly.

I looked inside the .a files it tries to link (in the above error, that would be JNI.o inside libHSforeign-jni.a, in my case it's Applicative.o in libHSbase-4.9.0.0.a). These files show "no machine":

Applicative.o: ELF 32-bit LSB  relocatable, no machine, version 1 (SYSV), not stripped

as opposed to e.g. crtbegin.o:

crtbegin.o: ELF 32-bit LSB  relocatable, ARM, EABI5 version 1 (SYSV), not stripped

As we can see, it says "not stripped". It could still be due to strip, if it's somehow damaging the object files without performing the stripping.

Any idea where I could start looking?

iphydf avatar Sep 19 '16 13:09 iphydf

It does the same for aarch64:

Applicative.o: ELF 64-bit LSB  relocatable, no machine, version 1 (SYSV), not stripped

iphydf avatar Sep 19 '16 16:09 iphydf

Interestingly, Applicative.o is the only .o file that has no machine. In the process library, the only .o file with no machine is Cmd.o. In directory, it's Directory.o. In my own-built zlib, there is no broken file. It looks like (I haven't looked at all the core library .a files) there is exactly one broken .o file per archive. I currently have no idea how that would happen.

iphydf avatar Sep 19 '16 16:09 iphydf

I have verified: every core library has exactly one broken .o file:

  • array: Array.o
  • base: Applicative.o
  • binary: Binary.o
  • bytestring: ByteString.o
  • containers: IntMap.o
  • deepseq: DeepSeq.o
  • directory: Directory.o
  • filepath: FilePath.o
  • haskeline: Haskeline.o
  • hoopl: Hoopl.o
  • hpc: Util.o
  • integer-gmp: Integer.o
  • pretty: PrettyPrint.o
  • process: Cmd.o
  • time: Calendar.o
  • transformers: Backwards.o

Each of these is the first module in the exposed-modules list of the package's cabal file.

iphydf avatar Sep 19 '16 17:09 iphydf

I found this in the log, which might be a lead:

"inplace/bin/ghc-cabal" check libraries/directory
"inplace/bin/ghc-cabal" configure libraries/directory dist-install "" \
  --with-ghc="/home/androidbuilder/ghc-build/build-android-21-aarch64-linux-android-4.9/ghc/inplace/bin/ghc-stage1" \
  --with-ghc-pkg="/home/androidbuilder/ghc-build/build-android-21-aarch64-linux-android-4.9/ghc/inplace/bin/ghc-pkg"  \
  --disable-library-for-ghci \
  --enable-library-vanilla \
  --disable-library-profiling \
  --disable-shared \
  --configure-option=CFLAGS="-Wall -fno-stack-protector    -Werror=unused-but-set-variable -Wno-error=inline" \
  --configure-option=LDFLAGS="  " \
  --configure-option=CPPFLAGS="   " \
  --gcc-options="-Wall -fno-stack-protector    -Werror=unused-but-set-variable -Wno-error=inline   " \
  --configure-option=--host=aarch64-unknown-linux-android --with-gcc="/home/androidbuilder/.ghc/android-21/aarch64-linux-android-4.9/bin/aarch64-linux-android-gcc" \
  --with-ld="/home/androidbuilder/.ghc/android-21/aarch64-linux-android-4.9/bin/aarch64-linux-android-ld.gold" \
  --with-ar="/home/androidbuilder/.ghc/android-21/aarch64-linux-android-4.9/bin/aarch64-linux-android-ar"  

As we can see, the GHC build system does not add --with-strip. I don't know whether ghc-cabal has or uses this flag. I do see in the build system that there is a STRIP_CMD that defaults to strip. I also see the following in the logs:

"inplace/bin/ghc-cabal" copy \
  libraries/binary dist-install \
  "strip" \
  '' \
  '/home/androidbuilder/.ghc/android-21/aarch64-linux-android-4.9' \
  '/home/androidbuilder/.ghc/android-21/aarch64-linux-android-4.9/lib/aarch64-unknown-linux-android-ghc-8.0.1' \
  '/home/androidbuilder/.ghc/android-21/aarch64-linux-android-4.9/share/doc/ghc-8.0.1/html/libraries' \
  'v'

which I believe comes from this Makefile code:

"$(ghc-cabal_INPLACE)" copy                        \
                       $p $(INSTALL_DISTDIR_$p)    \
                       "$(STRIP_CMD)"              \
                       '$(DESTDIR)'                \
                       '$(prefix)'                 \
                       '$(ghclibdir)'              \
                       '$(docdir)/html/libraries'  \
                       '$(GhcLibWays)'))

So I will try setting STRIP_CMD to the cross-toolchain strip and rebuild.

iphydf avatar Sep 19 '16 18:09 iphydf

So, to anyone trying to solve this problem: setting STRIP_CMD in build.mk solves the problem.

iphydf avatar Sep 19 '16 19:09 iphydf