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 User Repository

 
 
LinkBack Thread Tools
 
Old 11-11-2009, 03:34 AM
Ray Rashif
 
Default status of libtool slaying

I remember the consensus used to be !libtool by default and now it's libtool
in makepkg.conf, so what happened?

In any case, on my system:

~$ for i in `ls /usr/lib/*.la`; do pacman -Qo $i | awk '{print $5}'; done |
sort -u

fam
gnutls
kdemod-meanwhile
libarchive
libgphoto2
libsasl
moonlight
mpg123
neon
 
Old 11-11-2009, 07:22 AM
Ronald van Haren
 
Default status of libtool slaying

On Wed, Nov 11, 2009 at 5:34 AM, Ray Rashif <schivmeister@gmail.com> wrote:
> I remember the consensus used to be !libtool by default and now it's libtool
> in makepkg.conf, so what happened?
>

some packages need the libtool files to function properly if that is
what you mean.

Ronald
 
Old 11-11-2009, 07:29 AM
Ray Rashif
 
Default status of libtool slaying

2009/11/11 Ronald van Haren <pressh@gmail.com>

> On Wed, Nov 11, 2009 at 5:34 AM, Ray Rashif <schivmeister@gmail.com>
> wrote:
> > I remember the consensus used to be !libtool by default and now it's
> libtool
> > in makepkg.conf, so what happened?
> >
>
> some packages need the libtool files to function properly if that is
> what you mean.
>
> Ronald
>

I mean, that was always the case:
http://wiki.archlinux.org/index.php/Libtool_slaying

So the default for some time was to get rid of them, but in the event a
package did need its libtool files, then we used options=('libtool'), right?
But of course, there aren't many that install libtool files unnecessarily
now, so that's good. Just curious, in case I missed anything.
 
Old 11-11-2009, 07:35 AM
Ray Rashif
 
Default status of libtool slaying

2009/11/11 Ray Rashif <schivmeister@gmail.com>

> 2009/11/11 Ronald van Haren <pressh@gmail.com>
>
> On Wed, Nov 11, 2009 at 5:34 AM, Ray Rashif <schivmeister@gmail.com>
>> wrote:
>> > I remember the consensus used to be !libtool by default and now it's
>> libtool
>> > in makepkg.conf, so what happened?
>> >
>>
>> some packages need the libtool files to function properly if that is
>> what you mean.
>>
>> Ronald
>>
>
> I mean, that was always the case:
> http://wiki.archlinux.org/index.php/Libtool_slaying
>
> So the default for some time was to get rid of them, but in the event a
> package did need its libtool files, then we used options=('libtool'), right?
> But of course, there aren't many that install libtool files unnecessarily
> now, so that's good. Just curious, in case I missed anything.
>

Oops, I think I answered my own question. It's because "there aren't many
that install libtool files unnecessarily now". Thanks and sorry for the
blob!
 
Old 11-11-2009, 07:37 AM
Ronald van Haren
 
Default status of libtool slaying

On Wed, Nov 11, 2009 at 9:35 AM, Ray Rashif <schivmeister@gmail.com> wrote:
> 2009/11/11 Ray Rashif <schivmeister@gmail.com>
>
>> 2009/11/11 Ronald van Haren <pressh@gmail.com>
>>
>> On Wed, Nov 11, 2009 at 5:34 AM, Ray Rashif <schivmeister@gmail.com>
>>> wrote:
>>> > I remember the consensus used to be !libtool by default and now it's
>>> libtool
>>> > in makepkg.conf, so what happened?
>>> >
>>>
>>> some packages need the libtool files to function properly if that is
>>> what you mean.
>>>
>>> Ronald
>>>
>>
>> I mean, that was always the case:
>> http://wiki.archlinux.org/index.php/Libtool_slaying
>>
>> So the default for some time was to get rid of them, but in the event a
>> package did need its libtool files, then we used options=('libtool'), right?
>> But of course, there aren't many that install libtool files unnecessarily
>> now, so that's good. Just curious, in case I missed anything.
>>
>
> Oops, I think I answered my own question. It's because "there aren't many
> that install libtool files unnecessarily now". Thanks and sorry for the
> blob!
>

haha, good you figured it out! :lol:

Ronald
 
Old 11-11-2009, 08:25 AM
Jan de Groot
 
Default status of libtool slaying

On Wed, 2009-11-11 at 12:34 +0800, Ray Rashif wrote:
> I remember the consensus used to be !libtool by default and now it's libtool
> in makepkg.conf, so what happened?
>
> In any case, on my system:
>
> ~$ for i in `ls /usr/lib/*.la`; do pacman -Qo $i | awk '{print $5}'; done |
> sort -u
>
> fam
> gnutls
> kdemod-meanwhile
> libarchive
> libgphoto2
> libsasl
> moonlight
> mpg123
> neon

libtool always used to be the default and will stay this way. Some
packages require .la files, and it's a hard job detecting them when they
get removed by default. Showing a warning with namcap is much easier
than finding out the other way around.

>From this list posted above, I know at least mpg123, libsasl and
libgphoto2 require libtool files to load their plugins.
I think fam and gnutls kept the .la files for no clear reason. Fedora
was the first to start deleting all these .la files, they kept the files
in these packages. Nowadays Fedora removes the .la files from gnutls and
gamin too, so we might do that in the near future also. Note that
removing these files also means rebuilding all packages with .la files
that include it.
For libarchive we kept the .la files because static linking would fail
without them. We don't do static linking with libarchive anymore, so if
we ever decide to --disable-static, we should also remove the .la files
in it.
Fedora still keeps .la files in neon and even patches them to include
less crap, so I guess they have a reason to keep the files.
Moonlight doesn't contain .la files, and about kdemod-meanwhile: I don't
use kdemod, so I can't comment on it.
 
Old 11-11-2009, 10:04 AM
Xavier
 
Default status of libtool slaying

On Wed, Nov 11, 2009 at 10:25 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
> For libarchive we kept the .la files because static linking would fail
> without them. We don't do static linking with libarchive anymore, so if
> we ever decide to --disable-static, we should also remove the .la files
> in it.

There is still pacman-static in AUR, we might want to keep support for it :
http://aur.archlinux.org/packages/pacman-static/pacman-static/PKGBUILD

But after a long time of inactivity, I finally just got pkgconfig
added to libarchive :
http://code.google.com/p/libarchive/source/detail?r=1614#

Though I did not try it to edit pacman-static package to use pkgconfig
instead of libtool.
 
Old 11-11-2009, 03:57 PM
Ray Rashif
 
Default status of libtool slaying

2009/11/11 Jan de Groot <jan@jgc.homeip.net>

> libtool always used to be the default and will stay this way. Some
> packages require .la files, and it's a hard job detecting them when they
> get removed by default. Showing a warning with namcap is much easier
> than finding out the other way around.
>
> >From this list posted above, I know at least mpg123, libsasl and
> libgphoto2 require libtool files to load their plugins.
> I think fam and gnutls kept the .la files for no clear reason. Fedora
> was the first to start deleting all these .la files, they kept the files
> in these packages. Nowadays Fedora removes the .la files from gnutls and
> gamin too, so we might do that in the near future also. Note that
> removing these files also means rebuilding all packages with .la files
> that include it.
> For libarchive we kept the .la files because static linking would fail
> without them. We don't do static linking with libarchive anymore, so if
> we ever decide to --disable-static, we should also remove the .la files
> in it.
> Fedora still keeps .la files in neon and even patches them to include
> less crap, so I guess they have a reason to keep the files.
> Moonlight doesn't contain .la files, and about kdemod-meanwhile: I don't
> use kdemod, so I can't comment on it.
>

Awesome; exactly what I wanted to know, thanks guys!
 

Thread Tools




All times are GMT. The time now is 02:45 PM.

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