Build openoffice-devel with clang when it is the native compiler

[truckman]

Summary

My plan is to set USES=compiler:c++11-lib to select
clang when it is the native compiler. In that
case silgraphite and boost will also be built with
clang, so we can use the native versions.

This diff is incomplete. It assumes that clang is always
used, whereas various things need to be made conditional.

The bridges changes were inspired by some of the stuff
in s5abi_macosx_x86-64, with various tweaks to make
things compile.

The build gets fairly far. It currently fails in the
connectivity module, when building libdbase.so with this
command:

  .................c++ -Wl,-z,combreloc -Wl,-z,defs -Wl,-z,origin -Wl,-rpath,'$ORIGIN' -shared -Wl,-O1 -Wl,--version-script ../../../unxfbsdx.pro/misc/component_dbase.map -L../../../unxfbsdx.pro/lib -L../lib -L/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solenv/unxfbsdx/lib -L/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib -L/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solenv/unxfbsdx/lib -L/usr/local/openjdk7/lib -L/usr/local/openjdk7/jre/lib/amd64 -L/usr/local/openjdk7/jre/lib/amd64/server -L/usr/local/openjdk7/jre/lib/amd64/native_threads -L/usr/local/lib ../../../unxfbsdx.pro/slo/DCode.o ../../../unxfbsdx.pro/slo/DResultSet.o ../../../unxfbsdx.pro/slo/DStatement.o ../../../unxfbsdx.pro/slo/DPreparedStatement.o ../../../unxfbsdx.pro/slo/dindexnode.o ../../../unxfbsdx.pro/slo/DIndexIter.o ../../../unxfbsdx.pro/slo/DDatabaseMetaData.o ../../../unxfbsdx.pro/slo/DCatalog.o ../../../unxfbsdx.pro/slo/DColumns.o ../../../unxfbsdx.pro/slo/DIndexColumns.o ../../../unxfbsdx.pro/slo/DIndex.o ../../../unxfbsdx.pro/slo/DIndexes.o ../../../unxfbsdx.pro/slo/DTable.o ../../../unxfbsdx.pro/slo/DTables.o ../../../unxfbsdx.pro/slo/DConnection.o ../../../unxfbsdx.pro/slo/Dservices.o ../../../unxfbsdx.pro/slo/DDriver.o ../../../unxfbsdx.pro/slo/dbase_version.o -o ../../../unxfbsdx.pro/lib/libdbase.so -luno_cppu -luno_cppuhelpergcc3 -lvos3gcc3 -lsvl -ltl -lucbhelper4gcc3 -luno_sal -ldbtools -lfile -lutl -lcomphelpgcc3 -Wl,--as-needed -pthread -lm -Wl,--no-as-needed

with this error:

./usr/bin/ld: .../../../unxfbsdx.pro/slo/DTable.o: relocation R_X86_64_PC32 against `_ZThn192_N12connectivity4file10OFileTable7acquireEv' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

The reason for this error is unclear. DTable.o shows this symbol as
undefined. The symbol is defined in libfile.so, which is specified as
on the linker command line. Nothing else is defining this symbol and
-fPIC is being used.

.Compiling: connectivity/source/drivers/dbase/DTable.cxx
c++  -fmessage-length=0 -c -O2 -fno-strict-aliasing -DENABLE_LAYOUT=0 -DENABLE_LAYOUT_EXPERIMENTAL=0   -fvisibility=hidden -I. -I../../../unxfbsdx.pro/inc/dbase -I../inc -I../../inc -I../../../inc/pch -I../../../inc -I../../../unx/inc -I../../../unxfbsdx.pro/inc -I. -I/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/inc/stl -I/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/inc/external -I/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/inc -I/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solenv/unxfbsdx/inc -I/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solenv/inc -I/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/res -I/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solenv/inc/Xp31 -I/usr/local/openjdk7/include -I/usr/local/openjdk7/include/freebsd -I/usr/local/openjdk7/include/bsd -I/usr/local/openjdk7/include/linux -I/usr/local/openjdk7/include/native_threads/include -I/usr/local/include  -I/wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/inc/offuh -I. -I../../../res -I. -pipe  -fvisibility-inlines-hidden -g1 -Wall -Wextra -Wendif-labels -Wshadow -Wno-ctor-dtor-privacy     -Wno-non-virtual-dtor   -fPIC -DFREEBSD -DUNX -DVCL -DGCC -DC341 -DX86_64 -DX86_64  -D_PTHREADS -D_REENTRANT -DNEW_SOLAR -D_USE_NAMESPACE=1 -DHAVE_STL_INCLUDE_PATH -DHAVE_GCC_VISIBILITY_FEATURE -D__DMAKE -DUNIX -DCPPU_ENV=gcc3 -DGXX_INCLUDE_PATH=/usr/include/c++/v1 -DSUPD=420 -DPRODUCT -DNDEBUG -DOSL_DEBUG_LEVEL=0 -DOPTIMIZE -DCUI -DSOLAR_JAVA   -DSHAREDLIB -D_DLL_   -fexceptions -DEXCEPTIONS_ON  -o ../../../unxfbsdx.pro/slo/DTable.o /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/connectivity/source/drivers/dbase/DTable.cxx

[pfg]

(Just guessing) It may be an ld (binutils issue). 10-stable has received several updates but perhaps you could try the ports binutils w/o gold as well.

[truckman]

Tried using binutils, but no change. It actually looks like a clang bug.

% objdump -r DTable.o | grep 'FileTable.*acquire'
000000000000c4a8 R_X86_64_PC32     _ZThn192_N12connectivity4file10OFileTable7acquireEv+0xfffffffffffffffc
000000000000eb2c R_X86_64_PLT32    _ZN12connectivity4file10OFileTable7acquireEv+0xfffffffffffffffc
000000000000f5b7 R_X86_64_PLT32    _ZN12connectivity4file10OFileTable7acquireEv+0xfffffffffffffffc
0000000000000018 R_X86_64_64       _ZN12connectivity4file10OFileTable7acquireEv
0000000000000160 R_X86_64_64       _ZThn8_N12connectivity4file10OFileTable7acquireEv
0000000000000190 R_X86_64_64       _ZThn16_N12connectivity4file10OFileTable7acquireEv
00000000000001c0 R_X86_64_64       _ZThn24_N12connectivity4file10OFileTable7acquireEv
00000000000001f0 R_X86_64_64       _ZThn32_N12connectivity4file10OFileTable7acquireEv
0000000000000228 R_X86_64_64       _ZThn48_N12connectivity4file10OFileTable7acquireEv
0000000000000298 R_X86_64_64       _ZThn80_N12connectivity4file10OFileTable7acquireEv
00000000000002d8 R_X86_64_64       _ZThn120_N12connectivity4file10OFileTable7acquireEv
0000000000000310 R_X86_64_64       _ZThn128_N12connectivity4file10OFileTable7acquireEv
0000000000000340 R_X86_64_64       _ZThn136_N12connectivity4file10OFileTable7acquireEv
0000000000000370 R_X86_64_64       _ZThn144_N12connectivity4file10OFileTable7acquireEv
00000000000003a8 R_X86_64_64       _ZThn152_N12connectivity4file10OFileTable7acquireEv
0000000000000428 R_X86_64_64       _ZThn176_N12connectivity4file10OFileTable7acquireEv
0000000000000510 R_X86_64_64       _ZThn184_N12connectivity4file10OFileTable7acquireEv
0000000000000548 R_X86_64_64       _ZThn192_N12connectivity4file10OFileTable7acquireEv
00000000000005a8 R_X86_64_64       _ZThn304_N12connectivity4file10OFileTable7acquireEv

[truckman]

What's strange is that I don't see any calls to OFileTable::acquire in the source or in the disassembly from objdump -d. The offsets in the objdump -r output to make any sense when comparing with the disassembly.

[pfg]

If it's a clang bug, I guess a newer version of clang may behave differently ... but I am clueless :(.

[truckman]

The build succeeds with clang 3.5. I switched back to the internal boost and graphite because they are compiled with the base compiler and mixing c++ compiler versions is risky.

[pfg]

About the compiler choice: AOO already depends on many libraries (jpeg, openssl, python ...) that are built with the native compiler so it is better to build by default with gcc on FreeBSD 8 and 9, and clang for FreeBSD 10 an upper.

I got some feedback from Herbert Duerr (Apache) to consider about the clang build issue:

There was this change to clang:
http://llvm.org/viewvc/llvm-project?view=revision&revision=160034
which seems to solve a similar problem in mozilla, but it doesn't apply to our clang.

There are some suggestions for workarounds here:

http://stackoverflow.com/questions/14779260/linker-error-relocation-r-x86-64-pc32-against-undefined-symbol-despite-compila?rq=1

but we should probably stick to the working clang 3.5+.

[truckman]

Mixing libraries from different C compilers is ok, it's just C++ that is an issue.

[pfg]

The changes look good to me. The one thing I wonder about is why we have to add -DHAVE_STL_INCLUDE_PATH for clang but not for gcc.

[truckman]

Work here was merged into https://reviews.freebsd.org/D2055 and committed.