FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > ArchLinux > ArchLinux Pacman Development

 
 
LinkBack Thread Tools
 
Old 03-18-2011, 01:18 PM
Lukas Fleischer
 
Default libalpm linked against libarchive/libfetch deps (was: SyncFirst and dependencies)

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
 
Old 03-19-2011, 08:36 AM
Xavier Chantry
 
Default libalpm linked against libarchive/libfetch deps (was: SyncFirst and dependencies)

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
 
Old 03-19-2011, 09:38 AM
Xavier Chantry
 
Default libalpm linked against libarchive/libfetch deps (was: SyncFirst and dependencies)

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 ...
 
Old 03-19-2011, 07:27 PM
Lukas Fleischer
 
Default libalpm linked against libarchive/libfetch deps (was: SyncFirst and dependencies)

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.
 
Old 03-20-2011, 06:40 AM
Xavier Chantry
 
Default libalpm linked against libarchive/libfetch deps (was: SyncFirst and dependencies)

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
 

Thread Tools




All times are GMT. The time now is 06:21 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org