[lfs-support] /usr/lib/libstdc++.la getting trashed

Ken Moffat zarniwhoop at ntlworld.com
Mon Sep 3 10:23:40 PDT 2012

On Mon, Sep 03, 2012 at 11:41:55AM -0500, Bruce Dubbs wrote:
> Ken Moffat wrote:
> >   I know that I've got problems that are specific to my scripts (e.g.
> > automake tests fail in chroot), so I need to ask : has anyone else
> > ever seen this sort of error, or am I out on my own ?
> No I haven't.  In my latest build I have:
> $ cd /mnt/lfs/
> $ ls -l usr/lib/libstd*
> -rw-r--r-- 1 root root 2851280 Sep  2 01:40 usr/lib/libstdc++.a
> -rwxr-xr-x 1 root root     959 Sep  1 23:26 usr/lib/libstdc++.la
> lrwxrwxrwx 1 root root      19 Sep  1 23:26 usr/lib/libstdc++.so -> 
> libstdc++.so.6.0.17
> lrwxrwxrwx 1 root root      19 Sep  1 23:26 usr/lib/libstdc++.so.6 -> 
> libstdc++.so.6.0.17
> -rwxr-xr-x 1 root root 1260202 Sep  2 01:40 usr/lib/libstdc++.so.6.0.17
> Once those files are there, I don't know of anything that would alter or 
> remove them.

 Yeah, this is on the host.  When I've been hit by it in the past,
it has been some days after it disappeared - I've eventually started
to believe a seriously broken package, or a build failure at an
obscure place in a c++ package was doing it.

 But, now that I think about it, I'm almost certain that one of the
scripts I run on the way _into_ chroot (different from the book, so
directories and symlinks should be prefixed ${LFS} when I create them)
is suffering from a thinko.  That would probably explain why I haven't
noticed until much later.  
> The only automake failure I have is due to not having python installed.

 My automake failures were just as an example to note that my
scripts are known to sometimes be buggy.  But, if I build and test
automake *by hand* in a completed system, with python installed, that
test still fails - unlike the 80+ tests that are now ok.

> It might be an interesting experiment if you have a zero length .la file 
> to just delete it and see if the error still occurs.

 Normally, I notice it when I'm upgrading or looking at new packages
in BLFS.  Most recently, gcr failed to compile, and the time when
the .la had been trashed matches when I was playing about with
building 7.2 from itself.

 Some packages build ok if I remove the empty .la file.  Others
don't.  At the moment the only one I can find noted for certain is
ImageMagick - that isn't surprising, that package *needs* its own
.la files at *runtime* to be able to use the 'delegates'.

> Personally I've never seen the purpose of libtool or .la files.
>    -- Bruce
 Well, they seem to be redundant on linux, and I spent some time
back in my clfs days checking what the distros were doing, and then
decided to remove them.  On i686 I never saw a problem (except,
perhaps, in ImageMagick - or perhaps its need for .la files is more
recent).  On ppc, ppc64, and non-multilib x86_64 everything seemed
to build fine (I had a much smaller set of packages in those days),
but I ran into problems during upgrades - not the same missing .la
files on each architecture! - and eventually gave up.

das eine Mal als Tragödie, das andere Mal als Farce

More information about the lfs-support mailing list