My issue is the build of a static library using gcc-3.4.0 which later
is to be linked to an application in an environment not having a gcc
package installed.
Additional information which I very much believe is not specific to this
issue: the library is Berkeley-DB 4.2.52, OS is Solaris 9, application
is Apache 2.0.49, target environment usesSun WorkShop 6 (Forte-C)
compiler.
The problem is that the library uses certain functions (i.e. udivdi3
and muldi3) that gcc assumes are available through libgcc.a but the
environment doing the final linking does not have that GCC library
available and the link fails with unresolved symbols.
I'm looking for a solution telling gcc to embed it's functions into
the library but had no luck trying build options which sound promising
including -fno-builtin and -ffreestanding.
Currently my workaround is to modify the build environment of the static
library telling ar(1) to explicitly attach _udivdi3.o and _muldi3.o
objects to the library where I previously extracted these objects from
libgcc.a using ar(1). This resolves the first wave of undefined symbols
but seems to require more/other symbols.
I find this problem very interesting because it is the first time for
many years that I experience a C application linking a C library depend
on using the same compiler altough this is business as usual for C++.
It would be problematic to create a library to be distributed in binary
form only, i.e. for commercial purposes, because the library vendor and
the customer must share common compiler tools.
PS: I'm not interested in discussions which try to
solve this problem by redefining the issue :-)
Thanks for your input.
--
Thomas.Lotterer@xxxxxx, Cable & Wireless
