[pacman-dev] SyncFirst and dependencies
Hi, I'm not really sure if this actually is a bug or intended behaviour but upgrading pacman man my freshly installed system with [testing] enabled just broke pacman: $ pacman pacman: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory After some investigation, I figured out that "liblzma.so" is part of xz-utils which was renamed to "xz" sometime ago. When doing the first full system upgrade, pacman asked me to upgrade itself, first. As "SyncFirst" packages seem to be pulled in without dependency resolution, I ended up in having pacman 3.5.0, but an old xz-utils, resulting in some broken pacman depending on some shared library of a package that hasn't been upgraded yet. Is that intended? Unfortunately, I'm in a rush and I don't have any time to analyze this in detail right now...
On Fri, Mar 18, 2011 at 12:55 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Hi,
I'm not really sure if this actually is a bug or intended behaviour but upgrading pacman man my freshly installed system with [testing] enabled just broke pacman:
$ pacman pacman: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory
After some investigation, I figured out that "liblzma.so" is part of xz-utils which was renamed to "xz" sometime ago. When doing the first full system upgrade, pacman asked me to upgrade itself, first. As "SyncFirst" packages seem to be pulled in without dependency resolution, I ended up in having pacman 3.5.0, but an old xz-utils, resulting in some broken pacman depending on some shared library of a package that hasn't been upgraded yet.
Is that intended? Unfortunately, I'm in a rush and I don't have any time to analyze this in detail right now...
dep resolution is done, but if the deps are not precise enough, it does not help. Another example where sodeps could have been useful :) As far as I can see, libarchive 2.8.4-2 got a versioned dep on xz >= 5 but pacman only depends on libarchive 2.8.0
On Fri, Mar 18, 2011 at 01:10:01PM +0100, Xavier Chantry wrote:
On Fri, Mar 18, 2011 at 12:55 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Hi,
I'm not really sure if this actually is a bug or intended behaviour but upgrading pacman man my freshly installed system with [testing] enabled just broke pacman:
$ pacman pacman: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory
After some investigation, I figured out that "liblzma.so" is part of xz-utils which was renamed to "xz" sometime ago. When doing the first full system upgrade, pacman asked me to upgrade itself, first. As "SyncFirst" packages seem to be pulled in without dependency resolution, I ended up in having pacman 3.5.0, but an old xz-utils, resulting in some broken pacman depending on some shared library of a package that hasn't been upgraded yet.
Is that intended? Unfortunately, I'm in a rush and I don't have any time to analyze this in detail right now...
dep resolution is done, but if the deps are not precise enough, it does not help. Another example where sodeps could have been useful :)
As far as I can see, libarchive 2.8.4-2 got a versioned dep on xz >= 5 but pacman only depends on libarchive 2.8.0
Right, ye. I literally only had 10 minutes to figure this out and made wrong assumptions, thank your for clearifying. The pacman package in [testing] should be fixed anyway - before moving it to [core]. Otherwise, all fresh installs will break on the first system upgrade. Opened a Flyspray ticket [1]. [1] https://bugs.archlinux.org/task/23325
On Fri, Mar 18, 2011 at 02:02:06PM +0100, Lukas Fleischer wrote:
On Fri, Mar 18, 2011 at 01:10:01PM +0100, Xavier Chantry wrote:
On Fri, Mar 18, 2011 at 12:55 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Hi,
I'm not really sure if this actually is a bug or intended behaviour but upgrading pacman man my freshly installed system with [testing] enabled just broke pacman:
$ pacman pacman: error while loading shared libraries: liblzma.so.5: cannot open shared object file: No such file or directory
After some investigation, I figured out that "liblzma.so" is part of xz-utils which was renamed to "xz" sometime ago. When doing the first full system upgrade, pacman asked me to upgrade itself, first. As "SyncFirst" packages seem to be pulled in without dependency resolution, I ended up in having pacman 3.5.0, but an old xz-utils, resulting in some broken pacman depending on some shared library of a package that hasn't been upgraded yet.
Is that intended? Unfortunately, I'm in a rush and I don't have any time to analyze this in detail right now...
dep resolution is done, but if the deps are not precise enough, it does not help. Another example where sodeps could have been useful :)
As far as I can see, libarchive 2.8.4-2 got a versioned dep on xz >= 5 but pacman only depends on libarchive 2.8.0
Right, ye. I literally only had 10 minutes to figure this out and made wrong assumptions, thank your for clearifying. The pacman package in [testing] should be fixed anyway - before moving it to [core]. Otherwise, all fresh installs will break on the first system upgrade.
Opened a Flyspray ticket [1].
Well, it actually is a bit more than just a wrong dependency. ioni and me figured that libalpm 6.0.0 is linked against all libfetch and libarchive dependencies as well whereas 5.0.3 isn't, so there must have been some changes in the build system causing these trouble. I `git bisect`'ed the commit that introduced this regression. f489e969 [1] includes autotools upgrades and probably some more changes which seem to trigger this. Maybe someone else can have a closer look (I unfortunately don't have any more time and this is a rather large commit). I added these information to the related ticket [2] as well. [1] http://projects.archlinux.org/pacman.git/commit/?id=f489e969 [2] https://bugs.archlinux.org/task/23325
On Fri, Mar 18, 2011 at 3:18 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Well, it actually is a bit more than just a wrong dependency. ioni and me figured that libalpm 6.0.0 is linked against all libfetch and libarchive dependencies as well whereas 5.0.3 isn't, so there must have been some changes in the build system causing these trouble. I `git bisect`'ed the commit that introduced this regression. f489e969 [1] includes autotools upgrades and probably some more changes which seem to trigger this. Maybe someone else can have a closer look (I unfortunately don't have any more time and this is a rather large commit).
I added these information to the related ticket [2] as well.
[1] http://projects.archlinux.org/pacman.git/commit/?id=f489e969 [2] https://bugs.archlinux.org/task/23325
This commit definitely changes the command line. All deps coming from $(pkg-config --libs --static libarchive) appear after /usr/lib/libarchive.so After : make.log:libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto -O2 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1 Before : make-good.log:gcc -std=gnu99 -shared .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1
On Sat, Mar 19, 2011 at 10:36 AM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Fri, Mar 18, 2011 at 3:18 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Well, it actually is a bit more than just a wrong dependency. ioni and me figured that libalpm 6.0.0 is linked against all libfetch and libarchive dependencies as well whereas 5.0.3 isn't, so there must have been some changes in the build system causing these trouble. I `git bisect`'ed the commit that introduced this regression. f489e969 [1] includes autotools upgrades and probably some more changes which seem to trigger this. Maybe someone else can have a closer look (I unfortunately don't have any more time and this is a rather large commit).
I added these information to the related ticket [2] as well.
[1] http://projects.archlinux.org/pacman.git/commit/?id=f489e969 [2] https://bugs.archlinux.org/task/23325
This commit definitely changes the command line. All deps coming from $(pkg-config --libs --static libarchive) appear after /usr/lib/libarchive.so
After : make.log:libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto -O2 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1
Before : make-good.log:gcc -std=gnu99 -shared .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1
still did not get to the bottom of this, but all these libarchive deps comes from libarchive.la : # Libraries that this one depends upon. dependency_libs=' -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto' This is needed for a static build of pacman, but an alternative is to use pkg-config --static --libs libarchive somewhere in the Makefile, which gives the same dep list. Anyway, removing the .la file 'fixes' the problem, but well ...
On Sat, Mar 19, 2011 at 11:38:13AM +0100, Xavier Chantry wrote:
On Sat, Mar 19, 2011 at 10:36 AM, Xavier Chantry <chantry.xavier@gmail.com> wrote:
On Fri, Mar 18, 2011 at 3:18 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Well, it actually is a bit more than just a wrong dependency. ioni and me figured that libalpm 6.0.0 is linked against all libfetch and libarchive dependencies as well whereas 5.0.3 isn't, so there must have been some changes in the build system causing these trouble. I `git bisect`'ed the commit that introduced this regression. f489e969 [1] includes autotools upgrades and probably some more changes which seem to trigger this. Maybe someone else can have a closer look (I unfortunately don't have any more time and this is a rather large commit).
I added these information to the related ticket [2] as well.
[1] http://projects.archlinux.org/pacman.git/commit/?id=f489e969 [2] https://bugs.archlinux.org/task/23325
This commit definitely changes the command line. All deps coming from $(pkg-config --libs --static libarchive) appear after /usr/lib/libarchive.so
After : make.log:libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto -O2 -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1
Before : make-good.log:gcc -std=gnu99 -shared .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_files.o .libs/be_package.o .libs/cache.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -lfetch -lssl /usr/lib/libarchive.so -Wl,--hash-style=gnu -Wl,--as-needed -Wl,-soname -Wl,libalpm.so.5 -o .libs/libalpm.so.5.0.1
still did not get to the bottom of this, but all these libarchive deps comes from libarchive.la : # Libraries that this one depends upon. dependency_libs=' -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto'
This is needed for a static build of pacman, but an alternative is to use pkg-config --static --libs libarchive somewhere in the Makefile, which gives the same dep list.
Anyway, removing the .la file 'fixes' the problem, but well ...
Yes, this definitely is a libtool issue. It just seems to link all indirect library dependencies. We can circumvent this by linking with "-Wl,--as-needed" but I'm not sure whether this is a valid workaround (especially since I'm not sure how this will affect other platforms). I will submit that patch for further testing tho.
Also includes a Debian patch (from #347650) that makes libtool play nicely with "-Wl,--as-needed". Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- lib/libalpm/Makefile.am | 2 +- ltmain.sh | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletions(-) diff --git a/lib/libalpm/Makefile.am b/lib/libalpm/Makefile.am index 1bda571..4c329b8 100644 --- a/lib/libalpm/Makefile.am +++ b/lib/libalpm/Makefile.am @@ -52,7 +52,7 @@ libalpm_la_SOURCES += \ md5.h md5.c endif -libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) +libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) -Wl,--as-needed libalpm_la_LIBADD = $(LTLIBINTL) # vim:set ts=2 sw=2 noet: diff --git a/ltmain.sh b/ltmain.sh index 6c02b18..4e98c79 100755 --- a/ltmain.sh +++ b/ltmain.sh @@ -5790,6 +5790,11 @@ func_mode_link () arg=$func_stripname_result ;; + -Wl,--as-needed|-Wl,--no-as-needed) + deplibs="$deplibs $arg" + continue + ;; + -Wl,*) func_stripname '-Wl,' '' "$arg" args=$func_stripname_result @@ -6150,6 +6155,15 @@ func_mode_link () lib= found=no case $deplib in + -Wl,--as-needed|-Wl,--no-as-needed) + if test "$linkmode,$pass" = "prog,link"; then + compile_deplibs="$deplib $compile_deplibs" + finalize_deplibs="$deplib $finalize_deplibs" + else + deplibs="$deplib $deplibs" + fi + continue + ;; -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads) if test "$linkmode,$pass" = "prog,link"; then compile_deplibs="$deplib $compile_deplibs" -- 1.7.4.1
On Sat, Mar 19, 2011 at 09:28:34PM +0100, Lukas Fleischer wrote:
Also includes a Debian patch (from #347650) that makes libtool play nicely with "-Wl,--as-needed".
Signed-off-by: Lukas Fleischer <archlinux@cryptocrack.de> --- lib/libalpm/Makefile.am | 2 +- ltmain.sh | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletions(-)
Oh, and in case it turns out there's no proper solution, we might still consider adding this patch to the PKGBUILD only, so other platforms won't be affected.
On 20/03/11 06:28, Lukas Fleischer wrote:
Also includes a Debian patch (from #347650) that makes libtool play nicely with "-Wl,--as-needed".
Signed-off-by: Lukas Fleischer<archlinux@cryptocrack.de> --- lib/libalpm/Makefile.am | 2 +- ltmain.sh | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/Makefile.am b/lib/libalpm/Makefile.am index 1bda571..4c329b8 100644 --- a/lib/libalpm/Makefile.am +++ b/lib/libalpm/Makefile.am @@ -52,7 +52,7 @@ libalpm_la_SOURCES += \ md5.h md5.c endif
-libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) +libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) -Wl,--as-needed
This part is not needed. With the changes below the build obeys the given LDFLAGS. Unless of course we want to make this the default.
libalpm_la_LIBADD = $(LTLIBINTL)
# vim:set ts=2 sw=2 noet: diff --git a/ltmain.sh b/ltmain.sh index 6c02b18..4e98c79 100755 --- a/ltmain.sh +++ b/ltmain.sh @@ -5790,6 +5790,11 @@ func_mode_link () arg=$func_stripname_result ;;
+ -Wl,--as-needed|-Wl,--no-as-needed) + deplibs="$deplibs $arg" + continue + ;; + -Wl,*) func_stripname '-Wl,' '' "$arg" args=$func_stripname_result @@ -6150,6 +6155,15 @@ func_mode_link () lib= found=no case $deplib in + -Wl,--as-needed|-Wl,--no-as-needed) + if test "$linkmode,$pass" = "prog,link"; then + compile_deplibs="$deplib $compile_deplibs" + finalize_deplibs="$deplib $finalize_deplibs" + else + deplibs="$deplib $deplibs" + fi + continue + ;; -mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads) if test "$linkmode,$pass" = "prog,link"; then compile_deplibs="$deplib $compile_deplibs"
This hack will do until libtool gets it fixed. Just to clarify what the issues is here, libtool likes to reorder arguments that you pass to it. That puts -Wl,--as-needed after all the -lfoo statements which stops it working. And this is a hack as it requires -Wl,--as-needed to be separately specified (-Wl,--as-needed,--something-else will not work). But this fix is in widespread use while we wait for the proper fix so I will give it an ack. Allan
On Sat, Mar 19, 2011 at 6:29 PM, Allan McRae <allan@archlinux.org> wrote:
On 20/03/11 06:28, Lukas Fleischer wrote:
Also includes a Debian patch (from #347650) that makes libtool play nicely with "-Wl,--as-needed".
Signed-off-by: Lukas Fleischer<archlinux@cryptocrack.de> --- lib/libalpm/Makefile.am | 2 +- ltmain.sh | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/Makefile.am b/lib/libalpm/Makefile.am index 1bda571..4c329b8 100644 --- a/lib/libalpm/Makefile.am +++ b/lib/libalpm/Makefile.am @@ -52,7 +52,7 @@ libalpm_la_SOURCES += \ md5.h md5.c endif
-libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) +libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) -Wl,--as-needed
This part is not needed. With the changes below the build obeys the given LDFLAGS. Unless of course we want to make this the default.
libalpm_la_LIBADD = $(LTLIBINTL)
# vim:set ts=2 sw=2 noet: diff --git a/ltmain.sh b/ltmain.sh index 6c02b18..4e98c79 100755 --- a/ltmain.sh +++ b/ltmain.sh @@ -5790,6 +5790,11 @@ func_mode_link () arg=$func_stripname_result ;;
+ -Wl,--as-needed|-Wl,--no-as-needed) + deplibs="$deplibs $arg" + continue + ;; + -Wl,*) func_stripname '-Wl,' '' "$arg" args=$func_stripname_result @@ -6150,6 +6155,15 @@ func_mode_link () lib= found=no case $deplib in + -Wl,--as-needed|-Wl,--no-as-needed) + if test "$linkmode,$pass" = "prog,link"; then + compile_deplibs="$deplib $compile_deplibs" + finalize_deplibs="$deplib $finalize_deplibs" + else + deplibs="$deplib $deplibs" + fi + continue + ;;
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads) if test "$linkmode,$pass" = "prog,link"; then compile_deplibs="$deplib $compile_deplibs"
This hack will do until libtool gets it fixed. Just to clarify what the issues is here, libtool likes to reorder arguments that you pass to it. That puts -Wl,--as-needed after all the -lfoo statements which stops it working. And this is a hack as it requires -Wl,--as-needed to be separately specified (-Wl,--as-needed,--something-else will not work). But this fix is in widespread use while we wait for the proper fix so I will give it an ack.
So the tl;dr part of all this- include the ltmain.sh changes but not the Makefile.am ones, correct? -Dan
On Sun, Mar 20, 2011 at 11:01:27AM -0500, Dan McGee wrote:
On Sat, Mar 19, 2011 at 6:29 PM, Allan McRae <allan@archlinux.org> wrote:
On 20/03/11 06:28, Lukas Fleischer wrote:
Also includes a Debian patch (from #347650) that makes libtool play nicely with "-Wl,--as-needed".
Signed-off-by: Lukas Fleischer<archlinux@cryptocrack.de> --- lib/libalpm/Makefile.am | 2 +- ltmain.sh | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/Makefile.am b/lib/libalpm/Makefile.am index 1bda571..4c329b8 100644 --- a/lib/libalpm/Makefile.am +++ b/lib/libalpm/Makefile.am @@ -52,7 +52,7 @@ libalpm_la_SOURCES += \ md5.h md5.c endif
-libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) +libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) -Wl,--as-needed
This part is not needed. With the changes below the build obeys the given LDFLAGS. Unless of course we want to make this the default.
libalpm_la_LIBADD = $(LTLIBINTL)
# vim:set ts=2 sw=2 noet: diff --git a/ltmain.sh b/ltmain.sh index 6c02b18..4e98c79 100755 --- a/ltmain.sh +++ b/ltmain.sh @@ -5790,6 +5790,11 @@ func_mode_link () arg=$func_stripname_result ;;
+ -Wl,--as-needed|-Wl,--no-as-needed) + deplibs="$deplibs $arg" + continue + ;; + -Wl,*) func_stripname '-Wl,' '' "$arg" args=$func_stripname_result @@ -6150,6 +6155,15 @@ func_mode_link () lib= found=no case $deplib in + -Wl,--as-needed|-Wl,--no-as-needed) + if test "$linkmode,$pass" = "prog,link"; then + compile_deplibs="$deplib $compile_deplibs" + finalize_deplibs="$deplib $finalize_deplibs" + else + deplibs="$deplib $deplibs" + fi + continue + ;;
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads) if test "$linkmode,$pass" = "prog,link"; then compile_deplibs="$deplib $compile_deplibs"
This hack will do until libtool gets it fixed. Just to clarify what the issues is here, libtool likes to reorder arguments that you pass to it. That puts -Wl,--as-needed after all the -lfoo statements which stops it working. And this is a hack as it requires -Wl,--as-needed to be separately specified (-Wl,--as-needed,--something-else will not work). But this fix is in widespread use while we wait for the proper fix so I will give it an ack.
So the tl;dr part of all this- include the ltmain.sh changes but not the Makefile.am ones, correct?
Yes, sounds reasonable. Fix libtool ignoring "-Wl,--as-needed" but leave the decision whether to actually strip indirect dependencies to the packager.
On Sat, Mar 19, 2011 at 6:29 PM, Allan McRae <allan@archlinux.org> wrote:
On 20/03/11 06:28, Lukas Fleischer wrote:
Also includes a Debian patch (from #347650) that makes libtool play nicely with "-Wl,--as-needed".
Signed-off-by: Lukas Fleischer<archlinux@cryptocrack.de> --- lib/libalpm/Makefile.am | 2 +- ltmain.sh | 14 ++++++++++++++ 2 files changed, 15 insertions(+), 1 deletions(-)
diff --git a/lib/libalpm/Makefile.am b/lib/libalpm/Makefile.am index 1bda571..4c329b8 100644 --- a/lib/libalpm/Makefile.am +++ b/lib/libalpm/Makefile.am @@ -52,7 +52,7 @@ libalpm_la_SOURCES += \ md5.h md5.c endif
-libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) +libalpm_la_LDFLAGS = -no-undefined -version-info $(LIB_VERSION_INFO) -Wl,--as-needed
This part is not needed. With the changes below the build obeys the given LDFLAGS. Unless of course we want to make this the default.
libalpm_la_LIBADD = $(LTLIBINTL)
# vim:set ts=2 sw=2 noet: diff --git a/ltmain.sh b/ltmain.sh index 6c02b18..4e98c79 100755 --- a/ltmain.sh +++ b/ltmain.sh @@ -5790,6 +5790,11 @@ func_mode_link () arg=$func_stripname_result ;;
+ -Wl,--as-needed|-Wl,--no-as-needed) + deplibs="$deplibs $arg" + continue + ;; + -Wl,*) func_stripname '-Wl,' '' "$arg" args=$func_stripname_result @@ -6150,6 +6155,15 @@ func_mode_link () lib= found=no case $deplib in + -Wl,--as-needed|-Wl,--no-as-needed) + if test "$linkmode,$pass" = "prog,link"; then + compile_deplibs="$deplib $compile_deplibs" + finalize_deplibs="$deplib $finalize_deplibs" + else + deplibs="$deplib $deplibs" + fi + continue + ;;
-mt|-mthreads|-kthread|-Kthread|-pthread|-pthreads|--thread-safe|-threads) if test "$linkmode,$pass" = "prog,link"; then compile_deplibs="$deplib $compile_deplibs"
This hack will do until libtool gets it fixed. Just to clarify what the issues is here, libtool likes to reorder arguments that you pass to it. That puts -Wl,--as-needed after all the -lfoo statements which stops it working. And this is a hack as it requires -Wl,--as-needed to be separately specified (-Wl,--as-needed,--something-else will not work). But this fix is in widespread use while we wait for the proper fix so I will give it an ack.
Applied this but still seeing problems...hmm. /bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -pedantic -D_GNU_SOURCE -fvisibility=internal -fgnu89-inline -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -g -Wall -Werror -no-undefined -version-info 6:0:0 -Wl,--hash-style=gnu -Wl,--as-needed -o libalpm.la -rpath /usr/lib add.lo alpm.lo alpm_list.lo backup.lo be_local.lo be_package.lo be_sync.lo conflict.lo db.lo delta.lo deps.lo diskspace.lo dload.lo error.lo group.lo handle.lo log.lo package.lo pkghash.lo remove.lo sync.lo trans.lo util.lo version.lo -lfetch -lssl -larchive -lssp libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_local.o .libs/be_package.o .libs/be_sync.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/diskspace.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/pkghash.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -Wl,--as-needed -lfetch -lssl /usr/lib/libarchive.so -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto -lssp -march=x86-64 -mtune=generic -O2 -Wl,--hash-style=gnu -Wl,-soname -Wl,libalpm.so.6 -o .libs/libalpm.so.6.0.0 libtool: link: (cd ".libs" && rm -f "libalpm.so.6" && ln -s "libalpm.so.6.0.0" "libalpm.so.6") libtool: link: (cd ".libs" && rm -f "libalpm.so" && ln -s "libalpm.so.6.0.0" "libalpm.so") libtool: link: ar cru .libs/libalpm.a add.o alpm.o alpm_list.o backup.o be_local.o be_package.o be_sync.o conflict.o db.o delta.o deps.o diskspace.o dload.o error.o group.o handle.o log.o package.o pkghash.o remove.o sync.o trans.o util.o version.o libtool: link: ranlib .libs/libalpm.a libtool: link: ( cd ".libs" && rm -f "libalpm.la" && ln -s "../libalpm.la" "libalpm.la" ) dmcgee@galway ~/projects/pacman-maint (maint) $ ldd lib/libalpm/.libs/libalpm.so linux-vdso.so.1 => (0x00007fff38dff000) libfetch.so => /usr/lib/libfetch.so (0x00007faf13b0e000) libarchive.so.2 => /usr/lib/libarchive.so.2 (0x00007faf138cb000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007faf1350e000) libssp.so.0 => /usr/lib/libssp.so.0 (0x00007faf1330c000) libc.so.6 => /lib/libc.so.6 (0x00007faf12fab000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007faf12d4e000) libacl.so.1 => /lib/libacl.so.1 (0x00007faf12b47000) libattr.so.1 => /lib/libattr.so.1 (0x00007faf12943000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007faf12719000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007faf124f7000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007faf122e7000) libz.so.1 => /usr/lib/libz.so.1 (0x00007faf120ce000) libdl.so.2 => /lib/libdl.so.2 (0x00007faf11eca000) /lib/ld-linux-x86-64.so.2 (0x00007faf13f76000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007faf11cac000)
On Sun, Mar 20, 2011 at 11:29:32AM -0500, Dan McGee wrote:
Applied this but still seeing problems...hmm.
/bin/sh ../../libtool --tag=CC --mode=link gcc -std=gnu99 -pedantic -D_GNU_SOURCE -fvisibility=internal -fgnu89-inline -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-all -D_FORTIFY_SOURCE=2 -g -Wall -Werror -no-undefined -version-info 6:0:0 -Wl,--hash-style=gnu -Wl,--as-needed -o libalpm.la -rpath /usr/lib add.lo alpm.lo alpm_list.lo backup.lo be_local.lo be_package.lo be_sync.lo conflict.lo db.lo delta.lo deps.lo diskspace.lo dload.lo error.lo group.lo handle.lo log.lo package.lo pkghash.lo remove.lo sync.lo trans.lo util.lo version.lo -lfetch -lssl -larchive -lssp libtool: link: gcc -std=gnu99 -shared -fPIC -DPIC .libs/add.o .libs/alpm.o .libs/alpm_list.o .libs/backup.o .libs/be_local.o .libs/be_package.o .libs/be_sync.o .libs/conflict.o .libs/db.o .libs/delta.o .libs/deps.o .libs/diskspace.o .libs/dload.o .libs/error.o .libs/group.o .libs/handle.o .libs/log.o .libs/package.o .libs/pkghash.o .libs/remove.o .libs/sync.o .libs/trans.o .libs/util.o .libs/version.o -Wl,--as-needed -lfetch -lssl /usr/lib/libarchive.so -lacl -lattr -lexpat -llzma -lbz2 -lz -lcrypto -lssp -march=x86-64 -mtune=generic -O2 -Wl,--hash-style=gnu -Wl,-soname -Wl,libalpm.so.6 -o .libs/libalpm.so.6.0.0 libtool: link: (cd ".libs" && rm -f "libalpm.so.6" && ln -s "libalpm.so.6.0.0" "libalpm.so.6") libtool: link: (cd ".libs" && rm -f "libalpm.so" && ln -s "libalpm.so.6.0.0" "libalpm.so") libtool: link: ar cru .libs/libalpm.a add.o alpm.o alpm_list.o backup.o be_local.o be_package.o be_sync.o conflict.o db.o delta.o deps.o diskspace.o dload.o error.o group.o handle.o log.o package.o pkghash.o remove.o sync.o trans.o util.o version.o libtool: link: ranlib .libs/libalpm.a libtool: link: ( cd ".libs" && rm -f "libalpm.la" && ln -s "../libalpm.la" "libalpm.la" )
dmcgee@galway ~/projects/pacman-maint (maint) $ ldd lib/libalpm/.libs/libalpm.so linux-vdso.so.1 => (0x00007fff38dff000) libfetch.so => /usr/lib/libfetch.so (0x00007faf13b0e000) libarchive.so.2 => /usr/lib/libarchive.so.2 (0x00007faf138cb000) libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007faf1350e000) libssp.so.0 => /usr/lib/libssp.so.0 (0x00007faf1330c000) libc.so.6 => /lib/libc.so.6 (0x00007faf12fab000) libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007faf12d4e000) libacl.so.1 => /lib/libacl.so.1 (0x00007faf12b47000) libattr.so.1 => /lib/libattr.so.1 (0x00007faf12943000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007faf12719000) liblzma.so.5 => /usr/lib/liblzma.so.5 (0x00007faf124f7000) libbz2.so.1.0 => /lib/libbz2.so.1.0 (0x00007faf122e7000) libz.so.1 => /usr/lib/libz.so.1 (0x00007faf120ce000) libdl.so.2 => /lib/libdl.so.2 (0x00007faf11eca000) /lib/ld-linux-x86-64.so.2 (0x00007faf13f76000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007faf11cac000)
ldd(1) lists dependencies recursively - so this one includes indirect dependencies as well. Use `readelf -d` instead.
On Sat, Mar 19, 2011 at 9:27 PM, Lukas Fleischer <archlinux@cryptocrack.de> wrote:
Yes, this definitely is a libtool issue. It just seems to link all indirect library dependencies. We can circumvent this by linking with "-Wl,--as-needed" but I'm not sure whether this is a valid workaround (especially since I'm not sure how this will affect other platforms). I will submit that patch for further testing tho.
Just to clarify with what was said in the other thread : arch uses -Wl,--as-needed by default (makepkg.conf LDFLAGS) and this flag can be seen in my two outputs above. But not in the right place, and that's what the debian patch fixes. And there was definitely a behavior change with that pacman libtool upgrade in the usage of dependency_libs from .la files, but I cannot tell whether it's a feature or a bug :)
participants (4)
-
Allan McRae
-
Dan McGee
-
Lukas Fleischer
-
Xavier Chantry