🚀 go-pugleaf

guenther@stolaf.edu (Philip Guenther) writes:

>>>>>> On 17 May 1993 14:12:09 GMT, ivo@tiger (Ivo Hofacker) said:

>> This has probably come up before:

>> When building X11R5 shared libraries with gcc, clients built with cc
>> fail because libgcc.a is not linked in. The problem could probably
>> be solved by including part or all of libgcc.a in those libraries.

>> Has anybody tried this ?  --

>Yeah, we did that here.  The solution was to add the following line to
>.../mit/lib/X/Imakefile.  It tells ld to link in the required routines
>from libgcc.a.

>REQUIREDLIBS= `gcc -v 2>&1 | awk '{print $$4}' | sed -e 's/specs$$/libgcc.a/'`

>This solution is actually from the Solaris 2 patches to X, but it'll
>work under Sunos4.* too.  They really ought to just say this to the
>README.X11 that comes with gcc.  They patch everything else in that
>patch.

This is supposedly fixed in gcc 2.4. In gcc 2.4 the function _builtin_saveregs
is inlined, rather than defined in libgcc.a.

It was pointed out to me that this trick doesn't work on Sun3s, but
probably only when compiling with gcc w/o -m68881. Gcc will try to
link in all kinds of floating point functions that haven't been compiled
as PIC.

It works for _builtin_saveregs, because it doesn't reference any external
symbols. So it doesn't matter for this function whether it's compiled
PIC or not.

Note that gcc compiled binaries may not work with cc compiled libraries
in this scenario. The binaries will use _builtin_saveregs() from libX11.so.
The Sun C compiled libraries will not contain that symbol.
(So you get in trouble when you make an executable with gcc, link it
with gcc compiled libraries, but later try to execute that executable on
a system with cc compiled libraries. The only gcc binaries that have this
problem are those that use variadic functions and are compiled with gcc
prior to gcc 2.4.0)

Casper