Re: [PATCH] Add missing sysroot resolution
Hi Paolo At OE we needed such a feature for long time. I am working on deploying 2.4 these days. There might be more we need to get it going so far its looking good. Thanks -Khem On 10/9/10, Paolo Bonzini wrote: >> Paolo, I'm sorry if I made you though this patch was fixing my problem >> (in fact after a quick test, it does not). I just wanted to point it >> out, because Openembedded like buildroot, are projects which try to >> crosscompile source packages. I though it might be a good start to >> investigate the problem. > > It is anyway, and it's a real bug, so thanks for pointing me to it and > to Openembedded! > > Paolo > -- Sent from my mobile device -Khem
Re: [PATCH] Add missing sysroot resolution
> Paolo, I'm sorry if I made you though this patch was fixing my problem > (in fact after a quick test, it does not). I just wanted to point it > out, because Openembedded like buildroot, are projects which try to > crosscompile source packages. I though it might be a good start to > investigate the problem. It is anyway, and it's a real bug, so thanks for pointing me to it and to Openembedded! Paolo
Re: [PATCH] Add missing sysroot resolution
Le samedi 09 octobre 2010 à 10:55 +0200, Paolo Bonzini a écrit : > On 10/09/2010 10:51 AM, Ralf Wildenhues wrote: > > * Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:43:12AM CEST: > >> I'm applying this patch since it's pretty obvious. > > > > Thank you. > > > > Is this fixing (part) of the reported bug? > > Lionel pointed us to the patch, so I assumed it fixed all of it. I > still haven't built his stuff. It looks really interesting, as does > OpenEmbedded, and it's really cool that the sysroot feature is already > getting this much exposure. I was worried that it would remain confined > in the "unused feature" limbo and would bitrot. > > It's also nice because it shows that these people _are_ > autoreconfing/relibtoolizing as part of their build systems. It gives > me much more confidence on the backwards-compatibility of libtool 2.4! > > > Do you know how to expose it, so we can cover it in the testsuite? > > Not yet, I'll look into it next week. I need to build Lionel's recipe > and then distill a testcase. > > > For future sysroot patches, feel free to also (or first) commit them to > > the sysroot branch and merge them to master. > > Ok, I was undecided about the status of the sysroot branch. > Hi, Paolo, I'm sorry if I made you though this patch was fixing my problem (in fact after a quick test, it does not). I just wanted to point it out, because Openembedded like buildroot, are projects which try to crosscompile source packages. I though it might be a good start to investigate the problem. And yes, I personally prefer to autoreconf/libtoolize packages rather than patching a generated libtool script :) Regards, -- Lionel Landwerlin
Re: somewhat misleading -no-undefined documentation
[ 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
Matěj Týč
Ralf Wildenhues
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
Re: [RFC PATCH] Strip trailing slashes from libdir and destdir
* Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:51:34AM CEST: > I found this patch at OpenEmbedded, > http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-October/025133.html > > It looks to me like the code can be simplified by unconditionally > stripping trailing slashes from $libdir and $destdir (i.e. not > introducing the new variables). Ideas? Probably ok, but I'd really like coverage for the bug this fixes. I know there is a bug, it's been reported more than once, but I don't recall that I had an exposer. The Automake 1.11+ code exposed this IIRC, because it started installing more than one library at once, and with a directory as destination argument (rather than directory/libfile.la). Thanks, Ralf > * libltdl/config/ltmain.m4sh (func_mode_install): Check if > $destdir ends with $libdir only after stripping trailing slashes > from both. Patch from Gary Thomas and > Nitin A Kamble . For people added to THANKS you can omit email addresses in the ChangeLog. > --- a/libltdl/config/ltmain.m4sh > +++ b/libltdl/config/ltmain.m4sh > @@ -2164,8 +2164,15 @@ func_mode_install () > func_append dir "$objdir" > > if test -n "$relink_command"; then > + # Strip any trailing slash from the destination. > + func_stripname '' '/' "$libdir" > + destlibdir=$func_stripname_result > + > + func_stripname '' '/' "$destdir" > + s_destdir=$func_stripname_result The indentation is wrong. > # Determine the prefix the user has applied to our future dir. > - inst_prefix_dir=`$ECHO "$destdir" | $SED -e "s%$libdir\$%%"` > + inst_prefix_dir=`$ECHO "X$s_destdir" | $Xsed -e "s%$destlibdir\$%%"` > > # Don't allow the user to place us outside of our expected > # location b/c this prevents finding dependent libraries that > @@ -2173,7 +2180,7 @@ func_mode_install () > # At present, this check doesn't affect windows .dll's that > # are installed into $libdir/../bin (currently, that works fine) > # but it's something to keep an eye on. > - test "$inst_prefix_dir" = "$destdir" && \ > + test "$inst_prefix_dir" = "$s_destdir" && \ > func_fatal_error "error: cannot install \`$file' to a directory not > ending in $libdir" > > if test -n "$inst_prefix_dir"; then
Re: [PATCH] Add missing sysroot resolution
* Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:55:44AM CEST: > On 10/09/2010 10:51 AM, Ralf Wildenhues wrote: > >* Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:43:12AM CEST: > >>I'm applying this patch since it's pretty obvious. > >Is this fixing (part) of the reported bug? > > Lionel pointed us to the patch, so I assumed it fixed all of it. I > still haven't built his stuff. It looks really interesting, as does > OpenEmbedded, and it's really cool that the sysroot feature is > already getting this much exposure. I was worried that it would > remain confined in the "unused feature" limbo and would bitrot. > > It's also nice because it shows that these people _are_ > autoreconfing/relibtoolizing as part of their build systems. It > gives me much more confidence on the backwards-compatibility of > libtool 2.4! Indeed! Good you say this (all of the above), because I forgot to mention any of it. > >Do you know how to expose it, so we can cover it in the testsuite? > > Not yet, I'll look into it next week. I need to build Lionel's > recipe and then distill a testcase. Cool. Thanks. > >For future sysroot patches, feel free to also (or first) commit them to > >the sysroot branch and merge them to master. > > Ok, I was undecided about the status of the sysroot branch. Oh, I don't care much either way, but as long as we're still fixing things with, might as well document the fixes on the branch. For some kind of future code-archeology niceness or so. ;-) Cheers, Ralf
Re: [PATCH] Add missing sysroot resolution
On 10/09/2010 10:51 AM, Ralf Wildenhues wrote: * Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:43:12AM CEST: I'm applying this patch since it's pretty obvious. Thank you. Is this fixing (part) of the reported bug? Lionel pointed us to the patch, so I assumed it fixed all of it. I still haven't built his stuff. It looks really interesting, as does OpenEmbedded, and it's really cool that the sysroot feature is already getting this much exposure. I was worried that it would remain confined in the "unused feature" limbo and would bitrot. It's also nice because it shows that these people _are_ autoreconfing/relibtoolizing as part of their build systems. It gives me much more confidence on the backwards-compatibility of libtool 2.4! Do you know how to expose it, so we can cover it in the testsuite? Not yet, I'll look into it next week. I need to build Lionel's recipe and then distill a testcase. For future sysroot patches, feel free to also (or first) commit them to the sysroot branch and merge them to master. Ok, I was undecided about the status of the sysroot branch. Paolo
Re: [PATCH] Add missing sysroot resolution
Hi Paolo, * Paolo Bonzini wrote on Sat, Oct 09, 2010 at 10:43:12AM CEST: > I'm applying this patch since it's pretty obvious. Thank you. Is this fixing (part) of the reported bug? Do you know how to expose it, so we can cover it in the testsuite? For future sysroot patches, feel free to also (or first) commit them to the sysroot branch and merge them to master. Thanks, Ralf > * libltdl/config/ltmain.m4sh (func_mode_link): Resolve sysroot > when fetching the install directory of dependent libraries. > Reported by Lionel Landwerlin , > patch by Khem Raj . > * THANKS: Reorder entries, add Khem and Lionel.
[RFC PATCH] Strip trailing slashes from libdir and destdir
I found this patch at OpenEmbedded, http://lists.linuxtogo.org/pipermail/openembedded-devel/2010-October/025133.html It looks to me like the code can be simplified by unconditionally stripping trailing slashes from $libdir and $destdir (i.e. not introducing the new variables). Ideas? Paolo * libltdl/config/ltmain.m4sh (func_mode_install): Check if $destdir ends with $libdir only after stripping trailing slashes from both. Patch from Gary Thomas and Nitin A Kamble . --- libltdl/config/ltmain.m4sh | 11 +-- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh index af46cb8..2add022 100644 --- a/libltdl/config/ltmain.m4sh +++ b/libltdl/config/ltmain.m4sh @@ -2164,8 +2164,15 @@ func_mode_install () func_append dir "$objdir" if test -n "$relink_command"; then + # Strip any trailing slash from the destination. + func_stripname '' '/' "$libdir" + destlibdir=$func_stripname_result + + func_stripname '' '/' "$destdir" + s_destdir=$func_stripname_result + # Determine the prefix the user has applied to our future dir. - inst_prefix_dir=`$ECHO "$destdir" | $SED -e "s%$libdir\$%%"` + inst_prefix_dir=`$ECHO "X$s_destdir" | $Xsed -e "s%$destlibdir\$%%"` # Don't allow the user to place us outside of our expected # location b/c this prevents finding dependent libraries that @@ -2173,7 +2180,7 @@ func_mode_install () # At present, this check doesn't affect windows .dll's that # are installed into $libdir/../bin (currently, that works fine) # but it's something to keep an eye on. - test "$inst_prefix_dir" = "$destdir" && \ + test "$inst_prefix_dir" = "$s_destdir" && \ func_fatal_error "error: cannot install \`$file' to a directory not ending in $libdir" if test -n "$inst_prefix_dir"; then -- 1.7.2.3
[PATCH] Add missing sysroot resolution
I'm applying this patch since it's pretty obvious.
* libltdl/config/ltmain.m4sh (func_mode_link): Resolve sysroot
when fetching the install directory of dependent libraries.
Reported by Lionel Landwerlin ,
patch by Khem Raj .
* THANKS: Reorder entries, add Khem and Lionel.
Cc: Lionel Landwerlin
Cc: Khem Raj
---
THANKS |6 --
libltdl/config/ltmain.m4sh |3 ++-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/THANKS b/THANKS
index ff3ab7d..5aa0c3c 100644
--- a/THANKS
+++ b/THANKS
@@ -42,6 +42,7 @@
Christian Cornelssen cc...@cs.tu-berlin.de 2002-11-05
Jan Kratochvil project-libt...@jankratochvil.net 2003-01-28
Raja R. Harinath harin...@acm.org 2003-02-25
+ Paolo Bonzinibonz...@gnu.org
2003-03-01
Richard Nicholas Somer Dawe r...@phekda.freeserve.co.uk 2003-03-12
Peter O'Gorman pe...@pogma.com 2003-03-14
Ralph Schleicher r...@nunatak.allgaeu.org
2003-03-13
@@ -55,7 +56,6 @@
Benjamin Reedran...@befunk.com
2004-02-08
Ralf Wildenhues ralf.wildenh...@gmx.de2004-02-12
Nick Hudson sk...@netbsd.org 2004-03-29
- Paolo Bonzinibonz...@gnu.org
2003-03-01
Noah Jeffrey Misch n...@cs.caltech.edu 2004-07-05
Thorsten Glaser t...@66h.42h.de 2004-10-11
Peter Rosin p...@lysator.liu.se 2005-04-12
@@ -118,11 +118,13 @@
John Wolfe j...@sco.com
Josh Hursey jjhur...@open-mpi.org
Joseph Beckenbach IIIj...@best.com
- Lennart Poettering lenn...@poettering.net
Karl Berry k...@freefriends.org
Kenneth Albanowski kja...@kjahds.com
Kevin Ryde use...@zip.com.au
+ Khem Raj raj.k...@gmail.com
Kurt D. Zeilenga k...@openldap.org
+ Lennart Poettering lenn...@poettering.net
+ Lionel Landwerlin llandwer...@gmail.com
Maciej Helminiak di...@wp.pl
Maciej W. Rozyckima...@linux-mips.org
Mahesh Narayanamurthimahesh.m...@gmail.com
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 1078e75..af46cb8 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -8478,7 +8478,8 @@ EOF
*.la)
func_basename "$deplib"
name="$func_basename_result"
- eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p' $deplib`
+ func_resolve_sysroot "$deplib"
+ eval libdir=`${SED} -n -e 's/^libdir=\(.*\)$/\1/p'
$func_resolve_sysroot_result`
test -z "$libdir" && \
func_fatal_error "\`$deplib' is not a valid libtool archive"
func_append newdependency_libs " ${lt_sysroot:+=}$libdir/$name"
--
1.7.2.3
