bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libgmp: link to the correct shared library


From: Bruno Haible
Subject: Re: libgmp: link to the correct shared library
Date: Fri, 24 Jul 2020 00:30:50 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-179-generic; KDE/5.18.0; x86_64; ; )

Hi Paul,

> > This test fails when I build this gnulib module in my usual way:
> >    ./configure --prefix=/PREFIX64 \
> >                CPPFLAGS="-I/PREFIX64/include -Wall" \
> >                LDFLAGS="-L/PREFIX64/lib"
> 
> I don't see why this should be expected to work. Instead, you can tell 
> 'configure' to pass -rpath to the linker, so that the executable it produces 
> runs with the correct libraries. Something like this, say:
> 
>      ./configure --prefix=/PREFIX64 \
>                 CPPFLAGS="-I/PREFIX64/include -Wall" \
>                 LDFLAGS="-L/PREFIX64/lib -Wl,-rpath=/PREFIX64/lib"
> 
> This is a common issue when using dynamically-linked libraries in nonstandard 
> locations, and the longstanding way to address the issue is to use -rpath.

Yes, using rpath in the particular link command is the solution, and this is
what the 'havelib' module does.

But adding -Wl,-rpath=/PREFIX64/lib to LDFLAGS is not the solution, because it
affects all programs. If, say, we change the 'factor' program in GNU coreutils
to use GMP, so that it can factor integers with more than 20 digits, anyone who
wants to use their own installed GMP would get programs (from 'expr' to 'mkdir')
that all spend time, during program startup, to look up their libraries in
/PREFIX64/lib. This is not welcome.

Also, adding -Wl,-rpath=/PREFIX64/lib to LDFLAGS will have ill consequences
when the package contains shared libraries and uses libtool to create them. See
<https://lists.gnu.org/archive/html/bug-gnulib/2020-05/msg00102.html>.

> >     * modules/libgmp (Depends-on): Add havelib.
> 
> This approach requires all libgmp-using packages to also use havelib and do 
> all 
> the libtool stuff. Emacs, coreutils etc. build without libtool and I would 
> rather not introduce a dependency on libtool to them.

This is a misunderstanding. 'havelib' does not depend on libtool. *Creating*
a library is what requires libtool. *Linking* with a library does not require
libtool.

Do you think there is something to add to the documentation
https://www.gnu.org/software/gnulib/manual/html_node/Searching-for-Libraries.html
 ?

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]