dMZX Forums: linker fail on Debian armhf -> Archived MegaZeux Bugs -> Tracker

Hello. I downloaded Megazeux 2.84c on my machine (an efika smartbook running Debian/armhf).

I unpacked the tarball and went to

./config.sh --platform unix-devel
make

Unfortunately, I got this error:

/usr/bin/ld: src/.build/board.o: relocation R_ARM_THM_MOVW_ABS_NC against `__sta
ck_chk_guard' can not be used when making a shared object; recompile with -fPIC
src/.build/board.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libcore.so] Error 1

Knowing very little of make and makefiles, I went on IRC (slashnet/#mzx) wher users GetMobile and lolilover.

In particular, lolilover, after some diagnosing, suggested to use the --disable-modular option. That worked and the compile completed without errors.

I report this to document the behaviour, hopefully that will help next mzx versions to have a smoother compile on armhf.

I can test any fix on my machine.

I was "GetMobile" at the time on #mzx, and now that I'm home from my vacation I'm working on tracking down the issue under a VM.

Alright, I can confirm that this is 100% reproducible on a basic Debian 7 installation in an armhf VM

/usr/bin/ld: src/.build/board.o: relocation R_ARM_THM_MOVW_ABS_NC against `__stack_chk_guard' can not be used when making a shared object; recompile with -fPIC
src/.build/board.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libcore.so] Error 1

This, for the oddly curious, is the list of packages I had installed over the base install provided by the debian netinstall:

xserver-xorg
build-essential
libvorbis-dev
libogg-dev
libsdl12-dev
slim
icewm
xterm
sudo
links2

So its fairly safe to assume this would happen on pretty much any debian-armhf system.

So, trying a few workarounds that come to mind

First, I ran with make V=1 to see what flags were actually being used. I noticed -fstack-protector-all and remembered lancer saying something about it seeming to be related to the issue, so I tried removing lines 135-140 from the makefile.

This simply changed the symbol being relocated against:

/usr/bin/ld: src/.build/board.o: relocation R_ARM_THM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC
src/.build/board.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
make: *** [libcore.so] Error 1

Frankie ran against something similar when he tried the same, iirc.

I put the -fstack-protector-all back in as it seemed to not be the actual culprit anymore.

Then, I decided to take the compiler's advice and add -fPIC, sticking this below line 128 in the makefile.

ifeq (${SUBPLATFORM},linux-arm)
CFLAGS += -fPIC
CXXFLAGS += -fPIC
endif

This enabled the compile and link to complete without errors, producing a working, modular copy of Megazeux on Debian 7 ARMhf.

I don't know if it's needed on non hard-float ARM platforms (platform.inc/config.sh have no way of telling armhf "ARM with hardware floating point" from armel "normal ARM" at the moment), or if enabling -fPIC has any other reprecussions in MZX, so I'm hesitant to recommend this patch for general use, but it seems to work just fine so far.

I'm uploading a VM image (along with kernel and initrd) to aid others in testing MZX on debian-armhf. It should work on qemu 1.4.0 as long as you have a qemu-system-arm binary and "qemu-system-arm -M ?" returns "vexpress-a9" as a valid option. It comes with a shell script that'll run qemu with the proper options.

It should be up in about 3 hours, I'm having to limit my upload traffic on the VM tarball to 30KB/s in order to still be able to do work

Updating status to: Proposed Fix

(for those unwilling to read the whole thread, the proposed fix is adding this to the Makefile at roughly line 129)

ifeq (${SUBPLATFORM},linux-arm)
CFLAGS += -fPIC
CXXFLAGS += -fPIC
endif

Updating severity to: 3 - Medium

So, the fix was to just... to do what the error message told you to do :S I'll add it to the master branch in a little bit.

Updating status to: Fixed
Issue fixed in: GIT (debytecode)

Pushed it a while ago but forgot to post. Fixed in GIT 94276c2.

http://www.putlocker...A95AC5492274BC1 Here's the ARMhf VM I promised earlier.

So just to answer a question I asked earlier, I checked compiling on ARMel ("normal" ARM) using the normal makefile first, then using one modified as per the submitted fix. I found out two things.

• ARMel doesn't *need* the -fPIC fix (it compiles and runs fine without the change to the makefile)
  
• Having the -fPIC fix in the makefile (which does trigger since the subplatform is the same) doesn't cause any problems

This issue also occurs on MIPS architecture, and is fixed by a similar modification to the makefile, substituting ${SUBPLATFORM},linux-arm with ${SUBPLATFORM},linux-mips

If you think I should open a new bug (since this one is about armhf) say so

We should just enable -fPIC across the board if CONFIG_MODULAR is enabled. The only reason I didn't do this is that it isn't required for x86. On the x86 platform, register pressure means it can be slightly slower to run PIC, and the ABI does not require PIC to link shared objects.

However, for AMD64 PIC is required by the ABI. Many other platforms are the same. In most cases they have special registers for the GOT/PC-offset, which makes PIC code only negligibly slower. As you noted, MIPS and some ARM Linux ABIs will require PIC to link shared objects.

--ajs.

Updating status to: Confirmed

Moving this back to "Confirmed" so I don't forget to do what you said. Unfortunately I have been busy lately. : (

Fixed as ajs suggested in GIT 57b5773. Anyone who had issues here should confirm that the fix still works.

Setting up new armhf and mips VMs to test with, since my old VMs have since disappeared into the gaping hole that is "changes in website management" (re: putlocker). Will be able to report in a few hours if I'm lucky.

Confirmed fixed in armhf. Will report on mips later (It took me 6 hours to set up the armhf vm />)

Well that was extremely difficult, but confirmed fixed on mips.

Updating status to: Fixed

Issue fixed in: GIT

Moving to: Archived MegaZeux Bugs