On 04.10.2012 03:10, Ken Moffat wrote: > This time, I've looked at *all* my notes. Some are now so old that > I cannot determine whether a system was x86_64 or i686, and some of > those x86_64 systems were from clfs because LFS didn't support > x86_64 in those days. My attempts to remove the .la files started > after December 2008 and ceased by September 2009. The following > points (referencing BLFS - I don't *think* any of the LFS .la libs > were needed, but I'm not 100% sure) summarise what I found. Perhaps > things are different with the current verison of libtool - I have no > interest in retesting. I know that Armin has reported no problems, > and that Gilles seems happy, but I'm not willing to take the risk > again : > > 1. Perhaps even on i686, both mpeg123 and ImageMagick needed .la > files at runtime to be able to work correctly - I see that mpg123 > couldn't play anything (noted in July 2010 on ppc64 and x86_64), > and I still remember that ImageMagick programs were unable to open > the delegates for various image files. >
For ImageMagick the problem was fixed. At least I did not see it last time when I tried to use ImageMagick without .la files. As for mpg123, problem is still there today, but you are given a choice at configure. You can choose wether to use .la or .so|.dll|.dynlib or whatever to load the output plugins in /usr/lib/mpg123. It seems to work great. Another package that is making use of that is SASL itself. I've included modifications in current patch to remove need of .la files. > 2. Several gnome2 libs on x86_64 needed .la files to build. > I don't remember anything of the current legacy gnome packages complaining in my case. > 3. Various gstreamer-0.10 build problems - some were on ppc64, but > it looks as if the bad plugins on x86_64 were also affected. > Neither of that seems to be present today. > 4. When I upgraded to firefox-3.0.8 on *one* of my systems (probably > x86_64, but at least one other such system was fine) I had problems > with gnash needing libxml2.la and then audiofile.la - it's always > best to rebuild plugins if upgrading firefox, something I had > forgotten until it bit me on an LFS-6.6 system last month. > > 5. In April 2009 I discontinued a couple of systems after hitting > problems trying to upgrade poppler - variously requiring some or all > of libX11.la, libreetype.la, libexpat.la - at that point I gave up : > note that the initial build had deleted all of those .la files as > each package was installed, it was only the later upgrade which > failed. > That should not happen, at least when NO .la file is present. Every .la file should be removed directly AFTER package is installed. Failing to do so might result in failure like that. Another problem can be leftover .la file which references to removed .la files which can cause that error. > Summary - if deleting .la files works for you (particularly on > i686), be happy. But don't expect me to endorse that approach, or > to offer help if you are unable to rebuild some of the packages (to > fix vulnerabilities) in the future. And always remember to test > that your BLFS packages work (e.g. mpg123, ImageMagick, but > basically *everything") - particularly when you change to newer > versions - otherwise *you* will be the one creating the Farce in my > .sig. > Good one :D ... I can assure you, if something works on x86_32, I see no reason why it should not be working on x86_64 when doing same stuff. I've started x86_64 build once and I removed .la files even there. I never got an issue. Of course I never got past LFS there, but LFS itself worked great. Just remember, removing .la files in /usr/lib hierarchy is not always enough. There are some left in /lib, too. Don't forget about them! > ĸen > -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
