bug-libtool
[Top][All Lists]
Advanced

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

Re: -no-undefined (was: libposix)


From: Bruno Haible
Subject: Re: -no-undefined (was: libposix)
Date: Tue, 5 Oct 2010 11:46:05 +0200
User-agent: KMail/1.9.9

Hello Ralf,

> > 1)   libposix_la_LDFLAGS += -no-undefined
> > 
> >    This should ensure that on all platforms, the linking of libposix.so will
> >    fail if there are undefined references. Without waiting for a program to
> >    be linked with libposix.
> 
> That would be nice, but unfortunately that is not the case.
> Adding -no-undefined is a promise made by the developer that
> the library does not depend on libraries not listed.

And the module descriptions of gnulib modules make the promise to the
developer that the 'Link:' fields are complete. 

> However, the developer cannot know or guarantee that she links
> against (installed) libraries which themselves may depend on
> undefined references.

If a gnulib module contains a 'Link:' directive that triggers undefined
references, it is a bug in that gnulib module. For example, if linking
with readline requires "-lreadline -lncurses" and not just "-lreadline",
then it would be the duty of the gl_FUNC_READLINE macro to determine
complete values for $(LTLIBREADLINE) and $(LIBREADLINE). Look at
m4/readline.m4: It already handles precisely that problem.

> This is one reason libtool does not use -Wl,-z,defs on GNU/Linux
> even with -no-undefined. 

I don't know what -Wl,-z,defs means. I trust the libtool developers to
implement -no-undefined correctly on all platforms. What I know, is that
the absence of -no-undefined prevents libtool from creating shared libraries
on some platforms (I think, Cygwin and AIX, maybe others). Creating shared
objects with incomplete references (like what may be required for some
X11 programs that want to use libXaw3d instead of libXaw) is outside the
scope of gnulib-tool.

Bruno



reply via email to

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