libtool
[Top][All Lists]
Advanced

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

Re: somewhat misleading -no-undefined documentation


From: Ralf Wildenhues
Subject: Re: somewhat misleading -no-undefined documentation
Date: Sat, 9 Oct 2010 12:27:35 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

[ adding libtool-patches ]

Hi Matěj,

* Matěj Týč wrote on Sun, Oct 03, 2010 at 12:12:00AM CEST:
> I have thought so far that if you want to make a DLL, you can't get
> involved with any other library, because libtool needs -no-undefined
> flag in order to make DLLs and you are supposed to use it only if the
> library is self-contained.
> I was quite surprised when I have cheated libtool, supplied the
> -no-undefined parameter and it worked although I thought that it
> shouldn't and after some investigation, I have stumbled across an old
> mailing list thread, where another person had the same issue:
> http://lists.gnu.org/archive/html/libtool/2006-03/msg00012.html
> Having looked at the documentation thoroughly, I had to admit that the
> documentation is correct, but if you try to read through it quickly, it
> is likely that you leave with the impression expressed in the beginning
> of this e-mail.
> Therefore I suggest that you stress this in the documentation, feel free
> to use this patch (there is also a patch if you look at the old
> message).

Thanks for the report and patch.

> --- a/doc/libtool.texi
> +++ b/doc/libtool.texi
> @@ -1517,7 +1517,8 @@ of library paths.  Useful if the program is only
> used in the build tree,
>  e.g., for testing or generating other files.
>  
>  @item -no-undefined
> -Declare that @var{output-file} does not depend on any other libraries.
> +Declare that @var{output-file} does not depend on any other libraries
> +in the sense that after linking it will not have any unresolved
> symbols.
>  Some platforms cannot create shared libraries that depend on other
>  libraries (@pxref{Inter-library dependencies}).

This isn't quite right yet, because it may be misinterpreted in a way
that symbols may not even be resolved to dependent libraries.  I don't
think we support such systems any more, if there still are any more of
them out there.

> @@ -3263,7 +3264,8 @@ library systems and simple dynamic library
> systems.
>  
>  Some platforms, such as AIX, do not even allow you this
>  flexibility.  In order to build a shared library, it must be entirely
> -self-contained (that is, have references only to symbols that are found
> +self-contained or it must have dependencies known at the link time
> +(that is, have references only to symbols that are found
>  in the @file{.lo} files or the specified @samp{-l} libraries), and you
>  need to specify the @option{-no-undefined} flag.  By default, libtool
>  builds only static libraries on these kinds of platforms.

Good point.

I kinda like Simon's patch you referenced (wow, that's old!), so how
about this patch which takes from both your suggestions?
(I'm attributing this to Simon because he got it started, for lack of a
better way to specify multiple authors in a git commit.)

Thanks,
Ralf

2010-10-09  Simon Josefsson  <address@hidden>
            Matěj Týč <address@hidden>
            Ralf Wildenhues  <address@hidden>

        docs: improve description of -no-undefined.
        * doc/libtool.texi (Link mode): Fix -no-undefined description.
        (Inter-library dependencies): Use Windows not AIX as example
        system.  Clarify need for symbol resolution at library creation
        time.

diff --git a/doc/libtool.texi b/doc/libtool.texi
index cd5a181..076b67b 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -1517,9 +1517,12 @@ of library paths.  Useful if the program is only used in 
the build tree,
 e.g., for testing or generating other files.
 
 @item -no-undefined
-Declare that @var{output-file} does not depend on any other libraries.
-Some platforms cannot create shared libraries that depend on other
-libraries (@pxref{Inter-library dependencies}).
+Declare that @var{output-file} does not depend on any libraries other
+than the ones listed on the command line, i.e., after linking, it will
+not have unresolved symbols.  Some platforms require all symbols in
+shared libraries to be resolved at library creation (@pxref{Inter-library
+dependencies}), and using this parameter allows @command{libtool} to
+assume that this will not happen.
 
 @item -o @var{output-file}
 Create @var{output-file} from the specified objects and libraries.
@@ -3261,12 +3264,13 @@ in order to guarantee that all the required libraries 
are found.  This
 restriction is only necessary to preserve compatibility with static
 library systems and simple dynamic library systems.
 
-Some platforms, such as AIX, do not even allow you this
+Some platforms, such as Windows, do not even allow you this
 flexibility.  In order to build a shared library, it must be entirely
-self-contained (that is, have references only to symbols that are found
-in the @file{.lo} files or the specified @samp{-l} libraries), and you
-need to specify the @option{-no-undefined} flag.  By default, libtool
-builds only static libraries on these kinds of platforms.
+self-contained or it must have dependencies known at link time (that is,
+have references only to symbols that are found in the @file{.lo} files
+or the specified @samp{-l} libraries), and you need to specify the
address@hidden flag.  By default, libtool builds only static
+libraries on these kinds of platforms.
 
 The simple-minded inter-library dependency tracking code of libtool
 releases prior to 1.2 was disabled because it was not clear when it was




reply via email to

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