HOWTO compile shared C-libraries (e.g libpng) with gcc that do not depend on libgcc anymore

[Lars Holowko_2]

I tried to compile perl 5.8.1 and 5.8.2 on hp-ux 11.23 with gcc 3.3.1/2 what failed like this

cp op.c opmini.c
`sh cflags "optimize='-O3'" opmini.o` -fPIC -DPERL_EXTERNAL_GLOB opmini.c
CCCMD = gcc -DPERL_CORE -c -D_POSIX_C_SOURCE=199506L -D_REENTRANT -D_HPUX_SOURCE -fno-strict-aliasing -I/opt/mfgd
ep/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -O3 -Wall
rm -f opmini.c
LD_LIBRARY_PATH=/usr/local/src/perl-5.8.2 gcc -L/opt/mfgdep/lib/hpux32 -L/usr/lib/hpux32 -o miniperl \
miniperlmain.o opmini.o -L /usr/local/src/perl-5.8.2 -Wl,+s -Wl,+b/opt/mfgperl/lib/5.8.2/IA64.ARCHREV_0-thread-multi/COR
E -lperl -lcl -lpthread -lnsl -lnm -ldl -ldld -lm -lsec -lc
LD_LIBRARY_PATH=/usr/local/src/perl-5.8.2 ./miniperl -w -Ilib -MExporter -e '' || gmake minitest
/bin/sh: 13992 Memory fault(coredump)
gmake[1]: Entering directory `/usr/local/src/perl-5.8.2'
cp ext/re/re.pm ext/re/re.tmp && sh mv-if-diff ext/re/re.tmp lib/re.pm
gmake[2]: Entering directory `/usr/local/src/perl-5.8.2'
LD_LIBRARY_PATH=/usr/local/src/perl-5.8.2 ./miniperl -Ilib configpm configpm.tmp
/bin/sh: 14003 Memory fault(coredump)
gmake[2]: *** [lib/Config.pm] Error 139
gmake[2]: Leaving directory `/usr/local/src/perl-5.8.2'
gmake[1]: [minitest] Error 2 (ignored)

Turning down optimization does not have any effect.

So I tried to compile perl with HP's ansic and perl itself was built ok. But all the supporting libs I have previously compiled with gcc (zlib, gdbm, jpeg-6, libpng, ...) seem to depend on gcc's libgcc. Building the perl extension modules results in error messages like: 'unresoled symbol __uudiv in ...' which is defined in libgcc.

How do to I tell gcc to compile all the libgcc stuff in the shared libraries themselves that I do not have to distribute libgcc on every machine I install the compiled packages on and ansic does not complain about missing symbols anymore?


By the way: gcc was compiled with:

configure --disable-nls --enable-threads=posix --enable-shared --enable-languages=c,
c++,objc --with-gnu-as --with-as=/usr/local/bin/as --prefix=/usr/local


Kind regards,

Lars

[Elmar P. Kolkman]

I think a recompile with adding the object files from libgcc.a to your module could solve your problem, if libgcc.a contains the real functions.
As for the libgcc you need to distribute: it would only be the .sl file you need to distribute...

Also remember you have to run 'CC= perl Makefile.pl' again for the modules you previously compiled with gcc to use the other compiler, because some of the compile options are different for the two compilers.

[Lars Holowko_2]

Thanks Elmar,

You are right. That this is a workaround, but I don't like it. Libtool, which is used by most libraries, does not work with a libgcc.a when you want to build the latter. Many of the libraries use libtool which does not seem to be smart enough to compile with a libgcc.a. To get around that, you have to rerun the ld command libtool produces with the manual addition of -L/usr/local/lib/gcc-lib/ia64.../3.3.2 -lgcc.

I have to support more OSes and think there is too much fiddeling involved. Do you or anyone else have another idea?

[Elmar P. Kolkman]

I don't have the possibility to check right now, but doesn't libtool support some environment variable containing its library paths?
Another option would be to run libtool with --mode link -R