[Top][All Lists]

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

Re: autoconf 2.50: Libdnet may be linked in unnecessarily with libX11

From: Maciej W. Rozycki
Subject: Re: autoconf 2.50: Libdnet may be linked in unnecessarily with libX11
Date: Mon, 11 Jun 2001 16:12:09 +0200 (MET DST)


> > 2. Libdnet is available and X11 support DECnet but libX11 and other
> > relevant libraries are ELF and explicitly linked against libdnet, so they
> > include appropriate DT_NEEDED entries in their dynamic sections.
> But this probably does not. If you exclude libdnet at this point you won't
> be able to link statically.

 But if you want to link statically you should rerun configure anyway
(with CFLAGS set to something like "-static").  The script will then
detect static libX11 needs libdnet and will add it to LIBS accordingly.  I
can't see any problem here. 

> I wish somebody more experienced with libtool would comment on the issue.
> I don't have a certain opinion in this case. This change would be helpful
> for package builders trying to simplify dependencies.

 Well, I'm not sure how this relates to libtool -- the macro can get
invoked whether libtool is used or not.

> On the other hand, developers sometimes want to link statically after
> the project has been confiured and compiled. They will have to guess what
> is missing when it doesn't link.

 I don't think it's guaranteed to work -- one should probably reconfigure
the project anyway. 

> I personally believe that autoconf should primarily cater to developers.
> Package builders can (and should) build in the controlled environment.
> Besides, they know better what the system it's going to be, so they should
> tell it to configure instead of expecting configure to guess it.

 I know no way to tell the macro not to use libdnet even if it thinks it
has to.  It's simple the other way (just set LIBS before invoking
configure) and the developer knows if he needs libdnet for static linking
or not, anyway.

> > No need to link against libdnet explicitly as libX11 already carries an
> > appropriate dependency.
> Please don't mix two separate cases. It's true only in one of them.

 They both just happen to be handled by a single change.

> You have my support for the first case - no DECNET in libX11. I cannot
> make a certain decision on the second case. I don't like relying on ELF,
> but recompiling X to make a package for your friend (i.e. not for the
> whole world) would be an overkill.

 It's not relying on ELF but on a successful link of XOpenDisplay().  If
the function calls dnet_conn(), as it does in the case of XFree86 with
DECnet support, this will fail if libdnet does get linked in either
implicitly or explicitly.  In the latter case the following test will add
-ldnet to LIBS if the library exists.

> If you get support for the second case from another maintainer feel free
> to apply your patch. Otherwise it should be possible to check for symbols
> in libX11.

 Hmm, XFree86 seems to define _X11TransDNETFuncs in libX11 if DECnet is
supported.  It's the only DECnet-related symbol apart from a reference to
dnet_conn() there.  I'm not sure if it is safe to check for the symbol.


+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail: address@hidden, PGP key available        +

reply via email to

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