Ken McDonell <kenj@xxxxxxxxxxxxxxxx> writes:
> [...]
> === pmmgr ===
> g++ -O2 -g -march=i386 -mtune=i686 -[...]
> pmmgr.o: In function `__exchange_and_add':
> /usr/lib/gcc/i686-redhat-linux/4.7.2/../../../../include/c++/4.7.2/ext/atomicity.h:48:
> undefined reference to `__atomic_fetch_add_4'
> [...]
This one is an interesting issue. It turns out gcc for -march=i386
cannot compile c++ code via normal system headers. (e.g. [1], [2])
That's normally fine since people don't generally build -march=i386
binaries any more -- 32-bit Fedora uses -march=i686, for which the
c++config.h file's "#define _GLIBCXX_ATOMIC_BUILTINS 1" is fine.
What brings out i386 in the PCP builds is the joint effort of our
top level configure.in:
dnl Remove 4th name component, if present, from target, target_os,
dnl build and build_os. Squash all x86 cpus into one LCD form - i386
[...]
target_cpu=`echo $target_cpu | sed '[s/i[3-6]86/i386/]' | sed
'[s/powerpc/ppc/]'`
and build/rpm/GNUmakefile:
eval $(RPMPROG) -ba $$DEFS \
--target $(TARGET_CPU)-$(TARGET_VENDOR)-$(TARGET_OS) \
--clean $(SPEC)
Can someone explain why we do either of these and override distro defaults?
If this is unchangeable, it may be possible to add autoconf-based
LLDLIBS=-latomic that may result in linkable binaries. However,
running the resulting binaries on an actual i386 (<< i686) hardware
may well fail with SIGILL.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=455712
[2]
http://stackoverflow.com/questions/5560882/glibcxx-atomic-builtins-not-defined-in-gcc-4-4-5
- FChE
|