Re: [PATCH] Avoid -lm and -lpthread in libjava on darwin

[Jack Howarth <howarth@bromo.med.uc.edu>]

On Thu, Aug 12, 2010 at 11:09:46PM +0200, Ralf Wildenhues wrote:
> * Andrew Pinski wrote on Thu, Aug 12, 2010 at 08:23:13PM CEST:
> > On Thu, Aug 12, 2010 at 11:20 AM, Richard Henderson <rth@redhat.com> wrote:
> > > Is this patch necessary with the remove-outfile patch in place?
> > 
> > Yes because libtool calls ld directly for libjava.  I wish it did not
> > but it does.
> 
> * Jack Howarth wrote on Thu, Aug 12, 2010 at 08:24:30PM CEST:
> > The remove-outfile patch is necessary to make sure that the gcc
> > compilers don't shift libSystem forward in the linkage and
> > disrupt the logic behind libgcc_ext when -ldl, -lm or -lpthread
> > is passed to the compiler. The libjava patch covers the hardcoding
> > of -lpthread and -lm into the linker flags that are passed via
> > libtool directly to the linker.
> 
> So do I understand correctly that this ought to be fixed in libtool?
> Is the requirement to have libSystem last one that is specific to GCC
> or common to all software built with GCC?

Ralf,
  The requirement to keep libSystem last is a result of the addition of
libgcc_ext in FSF gcc-4.5 and later. The libgcc_ext shared library uses
versioned stubs to export those additional symbols from libgcc_s which aren't
present in Apple's versioned libgcc's. This is discussed in the
long and winding http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888.
  Basically we need to insure that the linkage stays as...

	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)
	/sw/lib/gcc4.6/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)

without my remove-outfile patch, if you pass -ldl, -lm or -lpthread to the gcc compiler,
it will change the linkage to...

	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
	/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)
	/sw/lib/gcc4.5/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)

which breaks the logic used by libgcc_ext. The same problem can arise if a program
manually links via libtool with ld (even in the presence of the remove-outfile patch).
Hence the second libjava patch which prevents -lm and -lpthread from being used in the
libjava build on darwin.
         Jack
ps Note that testresults with the two patches from last night eliminated the failures
in gcc.dg/torture/builtin-math-7.c (PR42333) by insuring that the non-buggy FSF libgcc
___divdc3 routine is used instead of the less accurate one from the compiler-rt.llvm.org
project code. This is just as well since Apple doesn't seem interested in fixing that one...

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42333#c47

> 
> Thanks,
> Ralf