> requires dynamic R_X86_64_32 reloc which may overflow at runtime;
> recompile with -fPIC
> /usr/local/bin/ld: error:
> build/release/host/lib/rtl/libflx_gc_static.a(flx_gc_static.o):
> requires dynamic R_X86_64_32 reloc which may overflow at runtime;
> recompile with -fPIC
> /usr/local/bin/ld: error:
> build/release/host/lib/rtl/libflx_gc_static.a(flx_gc_static.o):
> requires dynamic R_X86_64_32 reloc against
> '_ZTIN3flx3rtl19flx_out_of_memory_tE' which may overflow at runtime;
> recompile with -fPIC
> /usr/local/bin/ld: error:
> build/release/host/lib/rtl/libflx_gc_static.a(flx_gc_static.o):
> requires dynamic R_X86_64_32 reloc which may overflow at runtime;
> recompile with -fPIC
> collect2: error: ld returned 1 exit status
I don’t understand what’s happening here.
On Linux, the object files ending in _static.o are *deliberately* compiled
WITHOUT -fPIC.
The files ending in _dynamic.o are compiled WITH -fPIC
That’s the difference between them. -fPIC is required for dynamic linkage
and generates “relocatable code”. But this costs extra instructions for every subroutine call.
So for static linkage, you don’t want -fPIC and the compiler is wrong it cannot overflow at run time.
On MacOS, there is no difference, ALL code is position independent because
MacOS does NOT support static linkage of frameworks including the C run time library.
On Windows it’s messy: contrary to popular belief the Windows linker does not support
dynamic linkage, it ONLY has static linkage. So the compiler is forced to do the hackery
required instead .. that’s what export and import do. So in practice everyone on Windows
uses DLLs, with hacked static links, in other words, Windows really doesn’t support
static linkage even though the linker can ONLy do static linkage .. .Windows is weird :-)
Anyhow the message above is saying the garbage collector requires dynamic relocation
against the error handling routine for out of memory.
I’m noting that the boostrap version of flx is running and trying to build the Felix build tools
which are used to rebuild flx and everything else.
So the Python buildscript has successfully built the bootstrap flx, but that version of flx
is not building the build tools:
build/release/host/bin/flx --felix=build.fpc --static -c -od
build/release/host/bin src/tools/flx_build_flxg.flx
BOOTFLX
[bootflx] build/release/host/bin/flx --felix=build.fpc --static -c -od
build/release/host/bin src/tools/flx_build_flxg.flx
build/release/host/bin/flx is the bootstrap version of flx.
It is trying to build “flx_build_flxg” which is the Felix program that
builds the compiler, flxg.
Of course the compiler flxg is ALREADY built, but it was built by Python script.
So you need to make this a GitHub issue. I’m running a Mac so I don’t get this error.
However Travis regularly builds Felix on Linux and doesn’t get the error either.
So my GUESS at the moment it’s a change in the GNU linker model with version 9.
My guess is that they’re dropping support for static linkage, as Apple has done.
More precisely, dropping support for non-position independent (PIC) code.
However it could be a BUG in the build scripts, where just one object file uses -fPIC
which means all the others have to as well. Since I run MacOS I would never notice
that.
However, I do get some weirdo relocation error once when I run flx. As far as I can tell
that one is a BUG in clang’s C++ standard library that has never been fixed so it is
probably unrelated ...
—
John Skaller
ska...@internode.on.net