Re: clang and static linking?

From: Steve Kargl <sgk_at_troutmask.apl.washington.edu>
Date: Fri, 9 Nov 2012 18:14:53 -0800
On Sat, Nov 10, 2012 at 01:33:40AM +0100, Dimitry Andric wrote:
> On 2012-11-10 00:25, Dimitry Andric wrote:
> ...
> > The more difficult way out is to not define any duplicate functions in
> > libc.a and libm.a.  For the shared libraries, this should not be a
> > problem, since the dynamic linker will figure out which of the two
> > copies will get precedence.  The functions must stay available for
> > backwards compatibility reasons anyway.
> >
> > For static libraries, this compatibility seems to be unnecessary, as
> > they will only be used to link new programs.  Therefore, it would
> > probably be best to remove the whole isnan.o member from libc.a, and
> > move all the isnan functions to libm.a instead.
> >
> > Currently, isnan() is commented out in lib/msun/src/s_isnan.c, maybe we
> > can enable it whenever PIC is not defined?  Then we could simply skip
> > building lib/libc/gen/isnan.c for libc.a.
> 
> More concretely, here is a patch that seems to achieve the above:
> - Only define isnan, isnanf, __isnan and __isnanf in libc.so, not in
>    libc.a and libc_p.a.
> - Define isnan in libm.a and libm_p.a, not in libm.so.  I don't think
>    there is a need to define __isnan in the .a files, so I left that out.

> Index: lib/libc/gen/isnan.c
> ===================================================================
> --- lib/libc/gen/isnan.c	(revision 242841)
> +++ lib/libc/gen/isnan.c	(working copy)
> _at__at_ -35,6 +35,7 _at__at_
>   *     binary compat until we can bump libm's major version number.
>   */

Dimitry,

Your patch fixes the initial problem I saw with using gfortran
and openmpi.  Note, gfortran ignores -fno-builtins and I rarely
build C code with -static and -fno-builtins that uses isnan[f].

Unless someone objects, I think your patch is fine.

-- 
Steve
Received on Sat Nov 10 2012 - 01:14:53 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:32 UTC