libtool
[Top][All Lists]
Advanced

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

Re: relinking makes libtool link to the wrong library


From: Ralf Wildenhues
Subject: Re: relinking makes libtool link to the wrong library
Date: Fri, 11 Jan 2008 17:39:00 +0100
User-agent: Mutt/1.5.17 (2007-12-11)

* Simon Josefsson wrote on Fri, Jan 11, 2008 at 04:47:44PM CET:
> Ralf Wildenhues <address@hidden> writes:
> 
> > 1) ../lib/libgnutls.la has dependency_libs entry that contains -L/usr/lib
> > and -L/usr/local/lib, both wrongly I think.  Why is that?  To find out,
> > please send `libtool --debug --mode=link' output (not relink) for the
> > creation of ../lib/libgnutls.la.
> >
> > (I assume that your libz is in /usr/lib not /usr/local/lib.
> > If that's a false assumption, then the -L/usr/local/lib would have a
> > reason to be there.)
> 
> See libtool-debug2.txt.bz2 below.

> I suspect /usr/lib is from libtasn1, and -L/usr/local/lib is from
> libgcrypt.  Exactly how they are propagated I'm not sure.

They are from ../lgl/liblgnu.la and /usr/local/lib/libgcrypt.la.

> > 2) ../lgl/liblgnu.la has dependency_libs entry that contains
> > -L/usr/local/lib.  That doesn't look right either:
> >
> > | ++ dlname=
> > | ++ library_names=
> > | ++ old_library=liblgnu.a
> > | ++ dependency_libs=' -L/usr/local/lib /usr/local/lib/libgcrypt.la 
> > /usr/lib/libgpg-error.la'
> 
> This is from libgcrypt.la, lgl/Makefile.am:
> 
> if GL_COND_LIBTOOL
> liblgnu_la_LDFLAGS += $(LTLIBGCRYPT)
> endif
> 
> And from lgl/Makefile:
> 
> LTLIBGCRYPT = -L/usr/local/lib -lgcrypt -lgpg-error
> 
> Is this a gnulib bug?  I.e., should that be LIBADD?

Well.  Where to put these flags is somewhat debatable, but for your
situation it would surely be better if they were in LIBADD.  But what
would actually be better is if that instead were
  LTLIBGCRYPT = /usr/local/lib/libgcrypt.la /usr/local/lib/libgpg-error.la

(assuming both files exist).

Rationale: libtool cannot remove a -L/usr/local/lib from the command
line once it gets it, because it cannot know that removing it does not
lead to an error.

> > 4) "-lopencdk -llzo2" don't belong in LDFLAGS, they belong in
> > *_LIBADD/*_LDADD.  Put them after the ../lib-just-built-lib.la args
> > for good measure.
> 
> Hm.  Where does -L belong?  Also LDFLAGS?

In general, that depends (for both -L and -l).  Do you want -L to apply
to all libraries you need, or just those that come after where you put
it.  LDFLAGS is expanded early in the command line, LIBADD/LDADD later,
and LIBS last.

See, to the general class of relink problems you're having one of, I
don't think there is a solution that works in all cases, with complex
library dependencies.  Example: you want to link against /dir1/libfoo,
and /dir2/libbar.  Each of /dir1 and /dir2 contain both a libfoo and a
libbar.  Obviously that won't work, right?  So some sanity must be
expected from the user.

I think there is a solution in your case though, not sure.

>  The -lopencdk comes
> 'pkg-config --libs opencdk' which output '-L/usr/local/lib -lopencdk'.

What?  Are you aware that you're linking against /usr/lib/libopencdk?

> I could use pkg-config --libs-only-l and --libs-only-L but would prefer
> not to.

Huh?  In your first mail, I don't see
  -L/usr/local/lib -lopencdk

anywhere.

Of course, it would be cool if pkg-config could give you
  /usr/local/lib/libopencdk.la

(assuming such a beast existed).


Hmm.  Concluding, on your system you have
  libopencdk  in /usr/lib and in /usr/local/lib  (you want the latter)
  libgnutls   in /usr/lib and putting it in /usr/local/lib

Seems to me that in your case a
  make install LDFLAGS=-L/usr/local/lib

would be a suitable hack.

And that just listing the opencdk and -llzo2 stuff in LIBS would help
and possibly be enough to do without the hack.

Hope that helps.

Cheers,
Ralf




reply via email to

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