[lttng-dev] Odd dependency for lttng-ust - resolved

[lttng-dev] Odd dependency for lttng-ust - resolved

[Thibault, Daniel]

-----Message d'origine-----
Date: Mon, 21 Jan 2013 14:34:29 -0500
Subject: Re: [lttng-dev] Odd dependency for lttng-ust
-----Message d'origine (int?rieur)-----
De?: Mathieu Desnoyers [mailto:mathieu.desnoyers at efficios.com] 
Envoy??: 21 janvier 2013 13:39

As the error messages suggests, please try:
LDFLAGS=-L/usr/local/lib ./configure
instead of "./configure"

Mathieu
-----Fin du message d'origine (int?rieur)-----
   Interesting, that prefix does allow configure to complete successfully.  lttng-tools runs into the same problem as lttng-ust, and requires the same LDFLAGS prefix for its configure.  No other problems arise.

   So how do we fix userspace-rcu so the bootstrap -configure - make - install sequence doesn't run into this problem?  I'm presuming here that userspace-rcu's install needs to be touched up.  Or maybe lttng-ust's (and lttng-tools's) bootstrap.

   (It's a problem because the ReadMe for the lttng-ust and lttng-tools packages stipulate a plain ./configure invocation: as they currently stand, the instructions fail)
-----Fin du message d'origine-----

   I've finally stumbled onto what was causing ./configure to fail for lttng-ust and lttng-tools.

   According to the ld-linux man pages, the Linux default library/header paths are just /lib and /usr/lib: they do not include /usr/local/lib.  However, /etc/ld.so.conf.d/libc.conf (installed by the Ubuntu libc-bin package) adds /usr/local/bin to the system loader's path, so any application that relies on /usr/local/bin libraries will find them.  Why does ./configure fail, then?

   It turns out this particular failure is a known bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42756, January 2010) with the gold linker from the binutils-gold package (specified by the lttng-tools ReadMe): unlike the linker it replaces, gold's linker does not look into /usr/local/lib by default and ignores the ld.so.conf instructions.  Hence the explicit LDFLAGS=-L/usr/local/lib prefix requirement.

   Until this old gold bug is fixed (which looks unlikely considering its age), maybe each package's configure.ac could be made to explicitly look into /usr/local/lib when /lib and /usr/lib fail?  Or the ReadMe files of lttng-ust and lttng-tools could be modified to mention the workaround?

Daniel U. Thibault
R & D pour la d?fense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
Cyber s?curit? pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
Protection des syst?mes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
2459 route de la Bravoure
Qu?bec, QC? G3J 1X5
CANADA
Vox?: (418) 844-4000 x4245
Fax?: (418) 844-4538
NAC?: 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada?/ Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>

[lttng-dev] Odd dependency for lttng-ust - resolved

[Alexandre Montplaisir]

Hi Daniel,

On 13-01-25 12:32 PM, Thibault, Daniel wrote:
> [...]
>
>    Until this old gold bug is fixed (which looks unlikely considering its age), maybe each package's configure.ac could be made to explicitly look into /usr/local/lib when /lib and /usr/lib fail?  Or the ReadMe files of lttng-ust and lttng-tools could be modified to mention the workaround?
>

I'm not sure if they are any distro that uses gold by default, instead
of the more venerable/tested "ld". I know Ubuntu doesn't.

I think in your case the problem was because you still had the libraries
from Ubuntu's older package installed in /usr/lib, and as you mentioned,
the linker looks in that location before trying /usr/local/lib. In such
a "custom" setup, you would need to override LDFLAGS. But someone that
has nothing installed in /usr/lib should get the libraries in
/usr/local/lib selected by the linker automatically.

Cheers,
Alexandre

[lttng-dev] Odd dependency for lttng-ust - resolved

[Thibault, Daniel]

-----Message d'origine-----
De?: Alexandre Montplaisir [mailto:alexmonthy at voxpopuli.im] 
Envoy??: 25 janvier 2013 12:57

On 13-01-25 12:32 PM, Thibault, Daniel wrote:
> [...]
>    Until this old gold bug is fixed (which looks unlikely considering its age), maybe each package's configure.ac could be made to explicitly look into /usr/local/lib when /lib and /usr/lib fail?  Or the ReadMe files of lttng-ust and lttng-tools could be modified to mention the workaround?

I'm not sure if they are any distro that uses gold by default, instead of the more venerable/tested "ld". I know Ubuntu doesn't.

I think in your case the problem was because you still had the libraries from Ubuntu's older package installed in /usr/lib, and as you mentioned, the linker looks in that location before trying /usr/local/lib. In such a "custom" setup, you would need to override LDFLAGS. But someone that has nothing installed in /usr/lib should get the libraries in /usr/local/lib selected by the linker automatically.

Cheers,
Alexandre
-----Fin du message d'origine-----

   Nope, my /usr/lib is clean.  The problem is unavoidable on a clean system because lttng-tools's README lists GNU Gold (2.22 or better) in its requirements when building from git.  On the other hand, if you had a liburcu package installed and it were not too old, configure's checks would be passed.  You could run into trouble during the make though, depending on which liburcu (/usr/lib vs. /usr/local/lib) it linked against.  But that scenario is moot as Mathieu rightly warned against mixing old and new stuff together.

   "But someone that has nothing installed in /usr/lib should get the libraries in /usr/local/lib selected by the linker automatically."  Only if using ld.bfd or if binutils-gold were not installed -in which latter case one would not be following the instructions.  (See http://stackoverflow.com/questions/5873516/shared-library-in-usr-local-lib-not-found for a very similar problem and its diagnostic; this is the page that clinched it for me)

Daniel U. Thibault
R & D pour la d?fense Canada - Valcartier (RDDC Valcartier) / Defence R&D Canada - Valcartier (DRDC Valcartier)
Cyber s?curit? pour les missions essentielles (CME) / Mission Critical Cyber Security (MCCS)
Protection des syst?mes et contremesures (PSC) / Systems Protection & Countermeasures (SPC)
2459 route de la Bravoure
Qu?bec, QC  G3J 1X5
CANADA
Vox : (418) 844-4000 x4245
Fax : (418) 844-4538
[Valcartier]\\vsi-wdut-o980, [Secteur-SI]\\edge
NAC : 918V QSDJ <http://www.travelgis.com/map.asp?addr=918V%20QSDJ>
Gouvernement du Canada / Government of Canada
<http://www.valcartier.drdc-rddc.gc.ca/>
 LinkedIn: <http://ca.linkedin.com/in/daniel-u-thibault/>
 Research Gate: <https://www.researchgate.net/profile/Daniel_Thibault/>

[lttng-dev] Odd dependency for lttng-ust - resolved

[Christian Babeux]

>    Nope, my /usr/lib is clean.  The problem is unavoidable on a clean system because lttng-tools's README lists GNU Gold (2.22 or better) in its requirements when building from git.  On the other hand, if you had a liburcu package installed and it were not too old, configure's checks would be passed.  You could run into trouble during the make though, depending on which liburcu (/usr/lib vs. /usr/local/lib) it linked against.  But that scenario is moot as Mathieu rightly warned against mixing old and new stuff together.

The README has been clarified in commit
ee10cdeb41ab238ebdc9ae3d1b2a4dbbe930df9b.

The bottom line is:

With GNU ld: ./configure *should* work as is if "/usr/local/lib" is
correctly specified in /etc/ld.so.conf. Note that this is
_distribution specific_ and you might have to use
LDFLAGS=-L/usr/local/lib ./configure on other distros.

With GNU Gold: Use LDFLAGS=-L/usr/local/lib ./configure if
dependencies have been installed in /usr/local/*.

Thanks,

Christian