Haiku's gcc toolchain for ARM - The fPIC mystery

Alexander von Gluck IV kallisti5@unixzen.com
Fri Feb 15 14:52:00 GMT 2019


I'm one of the developers with Haiku (an open source implementation of the BeOS)

We maintain a small fork of GCC with our platform support. (we have tried to upstream
before, but haven't had the man-hours available to write the tests)

After updating to gcc 7.3 and applying our platform support patches, our ARM bootstrap
process has started to fail within the ICU build.

This issue seems to be less of an ICU issue, and more of a "the first C++ source code
we build with our toolchain refuses to do so" issue.

The issue is documented with detail here:


The first thing that uses our static libstdc++.a gets the following error:

arm-unknown-haiku/lib/libstdc++.a(istream-inst.o): relocation R_ARM_REL32 against external or
undefined symbol `_ZTIN10__cxxabiv115__forced_unwindE' can not be used when making a shared object;
recompile with -fPIC

PIC is definitely default in our SPEC:

./arm-unknown-haiku-g++ -dM -E - < /dev/null | grep PIC
#define __PIC__ 2
./arm-unknown-haiku-g++ -fPIC -dM -E - < /dev/null | grep PIC
#define __PIC__ 2
./arm-unknown-haiku-g++ -fpic -dM -E - < /dev/null | grep PIC
#define __PIC__ 1
./arm-unknown-haiku-g++ -fno-pic -dM -E - < /dev/null | grep PIC

libstdc++.* definitely seems to be compiled PIC per the symbols (*REL* in everything)

Base specs:

ARM specs:

Script that builds our cross-compiler (ignore gcc4, it's actually 7.3)

Any help, ideas, or troubleshooting steps would be appreciated.

This issue has been haunting us for a while... i'd like to get back to work on
our ARM port :-)


 -- Alex

More information about the Gcc-help mailing list