Mailing List Archive

Frank Peters wrote:
> Hello,
>
> The latest GTK+-2.24.3 failed to build on my system because of the
> following error:
>
> /bin/grep: /usr/lib64/libX11.la: No such file or directory
> /bin/sed: can't read /usr/lib64/libX11.la: No such file or directory
> libtool: link: `/usr/lib64/libX11.la' is not a valid libtool archive
>
> The libX11.la that is missing should be in the x11-libs/libX11 package.
> But why is libX11.la missing?
>
> I can emerge libX11 using USE="static-libs" or USE="-static-libs"
> but libX11.la is not produced in either case.
>
> The emerge log when building libX11 always shows the following:
>
> Removing unnecessary ... x11-libs/libX11-1.4.2/image/usr/lib64/libX11-xcb.la
> Removing unnecessary ... x11-libs/libX11-1.4.2/image/usr/lib64/libX11.la
>
> So the .la files are being produced but are being removed afterwards.
>
> Does anyone else have a missing /usr/lib64/libX11.la file?
>
> Frank Peters
>
>
>

I think I read on -dev that .la files were being removed. It seems to
have been causing trouble when packages were being updating that were
linked against each other. So, they made things so that they would work
without them and removed them.

That is oversimplified since it was a while back but I think that is
normal nowadays. Someone correct me if I am wrong on this.

Dale

:-) :-)

I've found a workaround for this issue:

emerge lafilefixer

lafilefixer --justfixit


[]'s
Fernando Boaglio

On Sun, Mar 27, 2011 at 10:16:18PM -0500, Dale wrote:
> Frank Peters wrote:
> > Hello,
> >
> > The latest GTK+-2.24.3 failed to build on my system because of the
> > following error:
> >
> > /bin/grep: /usr/lib64/libX11.la: No such file or directory
> > /bin/sed: can't read /usr/lib64/libX11.la: No such file or directory
> > libtool: link: `/usr/lib64/libX11.la' is not a valid libtool archive
> >
> > The libX11.la that is missing should be in the x11-libs/libX11 package.
> > But why is libX11.la missing?
> >
> > I can emerge libX11 using USE="static-libs" or USE="-static-libs"
> > but libX11.la is not produced in either case.
> >
> > The emerge log when building libX11 always shows the following:
> >
> > Removing unnecessary ... x11-libs/libX11-1.4.2/image/usr/lib64/libX11-xcb.la
> > Removing unnecessary ... x11-libs/libX11-1.4.2/image/usr/lib64/libX11.la
> >
> > So the .la files are being produced but are being removed afterwards.
> >
> > Does anyone else have a missing /usr/lib64/libX11.la file?
> >
> > Frank Peters
> >
> >
> >
>
> I think I read on -dev that .la files were being removed. It seems to
> have been causing trouble when packages were being updating that were
> linked against each other. So, they made things so that they would work
> without them and removed them.

Yeah, something like this.

The problem is that other .la files in /usr/lib* will directly
reference libX11.la. Thus, when libtool is used by GTK+ to link
against some library it depends on _other_ than libX11, that other
library will say ``I need /usr/lib64/libX11.la''. libtool tries to
load this file and give you the lovely error message above.

What you essentially need to do is find all /usr/lib*/lib*.la file
which contain the string ``libX11.la'' and remove ``libX11.la'' from
those files and/or just delete those .la files which have
``libX11.la'' in them. In my experience,
$ rm /usr/lib??/lib*.la
fixes such problems just fine.

*However*, people will probably recommend you install lafilefixer and
run
$ lafilefixer --justfixit

However, I've never done this myself so I'm just regurgitating what
I've heard from others... ;-). (I use the unofficial portage-multilib
branch of portage which almost completely disables .la file
installation and thus I _never_ hit this sort of ``can't find
libX11.la'' problem anymore.)

> That is oversimplified since it was a while back but I think that is
> normal nowadays. Someone correct me if I am wrong on this.
>
> Dale
>
> :-) :-)
>

--
binki

Look out for missing apostrophes!

On Monday 28 March 2011 00:21:52 Fernando Boaglio wrote:
> I've found a workaround for this issue:
>
> emerge lafilefixer
>
> lafilefixer --justfixit
>
>
> []'s
> Fernando Boaglio

that is not a workaround but the fix.

On Mon, 28 Mar 2011 00:21:52 -0300
Fernando Boaglio <boaglio@gmail.com> wrote:

>
> emerge lafilefixer
>
> lafilefixer --justfixit
>

Excellent! That solves the problem! Gtk+-2.24.3 now emerges without
problem.

Thanks to all who responded and thanks especially for the explanations
regarding the reason for the removal of the .la files from Gentoo.

Frank Peters

Volker Armin Hemmann posted on Mon, 28 Mar 2011 05:53:18 +0200 as
excerpted:

> On Monday 28 March 2011 00:21:52 Fernando Boaglio wrote:
>> I've found a workaround for this issue:
>>
>> emerge lafilefixer
>>
>> lafilefixer --justfixit
>>
>>
>> []'s Fernando Boaglio
>
> that is not a workaround but the fix.

It's a workaround, or at least I'd call it so, tho workaround/fix is
quibbling over technicalities, the simple fact is that it works,
regardless.

The "fix", in progress gentoo-wide, is to remove pretty much all the *.la
files entirely. But unless all packages are remerged at the same time,
that must be done in some particular order or still-installed *.la files
will refer to others already removed, thus triggering threads such as this.

FWIW, I've been using a PKG_INSTALL_MASK="*.la" setting here in my
make.conf for some time, now. That keeps portage from installing the
files entirely. With a single exception for one such file installed by
the libtool package itself, tested for by certain other package config
steps, it has been without issue.

In /etc/portage/env/sys-devel/libtool, I have this exception, so that
single package installs its *.la files, but that's it.

PKG_INSTALL_MASK=

When I first set the mask, I did an emerge --empty-tree @world, thus
removing all *.la files. The only problem I ran into was the missing *la
from libtool itself, which remerging it with the above exception worked
around, and I've been *.la file problem free since then. =:^)

Of course, individual users may have other exception packages as well, but
the above single exception works with the packages I have merged,
including most of kde4.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Tue, 29 Mar 2011 00:08:58 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

>
> FWIW, I've been using a PKG_INSTALL_MASK="*.la" setting here in my
> make.conf for some time, now. That keeps portage from installing the
> files entirely.
>

That's a good suggestion, but there is one minor problem remaining.

Although I rely on portage to do all the "heavy lifting" for me, there
is a small number of packages that I, for various reasons, still want
to install myself -- and I'm sure there are lots of others that do this
as well. These self-installed packages will often insert .la files into
the tree, and, in fact, I believe that this kind of condition had caused
my original ".la file not found" problem.

So the .la issue is definitely something for everyone to keep in mind,
and especially for those who may self-install an occasional extra package.

Frank Peters

Frank Peters posted on Mon, 28 Mar 2011 21:24:04 -0400 as excerpted:

> On Tue, 29 Mar 2011 00:08:58 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>
>> FWIW, I've been using a PKG_INSTALL_MASK="*.la" setting here in my
>> make.conf for some time, now. That keeps portage from installing the
>> files entirely.
>>
>>
> That's a good suggestion, but there is one minor problem remaining.
>
> Although I rely on portage to do all the "heavy lifting" for me, there
> is a small number of packages that I, for various reasons, still want to
> install myself -- and I'm sure there are lots of others that do this as
> well. These self-installed packages will often insert .la files into
> the tree, and, in fact, I believe that this kind of condition had caused
> my original ".la file not found" problem.
>
> So the .la issue is definitely something for everyone to keep in mind,
> and especially for those who may self-install an occasional extra
> package.

Question: Why don't you create (or modify the gentoo/overlay tree
version, if you can find one) an ebuild which does the installation using
portage? That way it still tracks it, and provided you keep reasonable
dependencies in the ebuild, it'll track them too.

FWIW, there's a couple things I install privately. One is a live net-nntp/
pan, from the khaley repo, testing branch, for which I created an ebuild,
which of course would eliminate the *.la files if any (it's a leaf
executable package, no such files, but if there were...). The other is
the kernel, for which I use my own non-ebuild scripts and package.provided
a 2.6.9999 kernel for portage dependency purposes. Of course the kernel
doesn't have *.la files to worry about... =:^)

Otherwise, I'd no-doubt script the build and installation using my own
scripts, for much the same reason I have with the kernel -- it's a
repeated action that lends itself to automation -- and appending a find-
and-delete on *.la files step to such a script would be reasonably
trivial, once I had automated the rest of the process.

Or just script lafilefixer after the install, but I'd probably go the
delete route, myself, just 'cause I'm tired of *.la file headaches and the
less I have to see or deal with the things, the happier I am!

But you're right, that's something to think about, for those libraries
(the only type of package that really has *.la files) you build yourself.

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman

On Tue, 29 Mar 2011 07:20:09 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

>
> Question: Why don't you create (or modify the gentoo/overlay tree
> version, if you can find one) an ebuild which does the installation using
> portage? That way it still tracks it, and provided you keep reasonable
> dependencies in the ebuild, it'll track them too.
>

Now that's a very good idea. I will have to start doing this. I've been
using my own build scripts from a long time back, but this is definitely
a better way to go.

Frank Peters