[lfs-dev] Ridding LFS/BLFS of libtool archives

DJ Lucas blfs-dev at lucasit.com
Sat Dec 2 14:50:49 PST 2017

Moved to LFS-Dev.

On 12/02/2017 10:31 AM, Bruce Dubbs wrote:
> DJ Lucas wrote:
>> As a few of you know, following the move to meson for glib and a
>> couple of
>> upgrade issues for people using Porg and some homegrown PMs, I've been
>> working on ridding us of the libtool archives in a local copy as they are
>> largely unnecessary, save for a handful of programs that still use
>> libtool's lt_dlopen function. I believe at least a couple of you had
>> already been doing this for some time anyway. I'd like to get a quick
>> review of the status so far (before commit). I know it's not exactly
>> rocket science, but it is a fairly significant change that will need some
>> time to settle out.
>> The svnstash extension on the diffs below is for a silly script I use to
>> mimic git stash. If interested it's here, but the output is same as
>> svn diff:
>> http://www.linuxfromscratch.org/~dj/libtool-removal/etc_profile_d_svn-aliases.sh
>> A current diff for LFS is available here:
>> http://www.linuxfromscratch.org/~dj/libtool-removal/lfs-lafile-removal.svnstash
>> Any comments, suggestions, additional info, better explanations needed on
>> the added page in chapter 3?
>> As to the script... Unfortunately, the latest incarnation has yet to be
>> fully tested due to changes made after I had cleared all of my existing
>> systems of libtool archives. Could use some help testing here.
>> http://www.linuxfromscratch.org/~dj/libtool-removal/remove-lafile.sh
>> And, a significant portion of BLFS is ready to go in as well, (up to a
>> full Gnome build) here:
>> http://www.linuxfromscratch.org/~dj/libtool-removal/blfs-libtool-removal.svnstash
>> I still need to link to the added LFS page in the &rmlibtool; entity and
>> add a note about upgrading packages (but it would be broken until LFS
>> gets
>> the update).
>> Comments, concerns, suggestions, flames, etc. are welcome.
> For LFS, I do not like the invasiveness of the changes.  The book builds
> fine the way it is and the la files do not impact anything there.  I
> have told you privately that I prefer just remove all the .la files
> optionally at the end of Chapter 6 in the cleaning up section.
> find /usr/lib /usr/libexec -name \*.la -print -delete

Yes, I recall you saying that a couple of times, but I was under the 
impression that I had convinced you otherwise (for the reason you 
mentioned below). I must have misunderstood. As I've also mentioned (in 
IRC), this kind of misses the mark IMO. The method I chose puts it front 
and center for every single package and completely negates the need for 
a script for people just starting with LFS or doing a new build. It's a 
new concept that we are introducing to the readers and I'm not sure of 
its value. Being very specific was on two fronts. First is in effort to 
negate the need for the script in its entirety. The second is in effort 
to meet the documentation goal (packages that do not have corresponding 
instructions in BLFS can still be updated using LFS instructions), but 
its educational value is probably minimal. The instructions could also 
simply be appended to the install sections, we don't need a new 
<screen/> block if that's the concern.

> I know that the .la file may be reintroduced if a user rebuilds a
> package using the Chapter 6 instructions, but that is not the purpose of
> LFS.

IMO, this is exactly the purpose of LFS. There is a reason that distros 
have been doing this for some time, the same reason we are being forced 
to do so now. The specifics, however, are hidden from the user, which is 
where LFS shines. I might be guilty of hand holding here, but I 
certainly don't see it that way. As mentioned above, my goal was for the 
script to be completely unneeded if building from scratch, and shortly 
thereafter for others. And, yes, I'm aware that does require more work 
for the editors.

I'll concede that a solid script is more inline with how a distro 
handles this issue in that this is usually a function of the package 
manager (before they are ever installed in system locations, and 
automated out of existence unless the packager takes steps to prevent 
their removal), and that might well be the best way forward. A script is 
clearly far less invasive to the book instructions. My concern is that 
it becomes an integral part of BLFS rather than a temporary tool to 
assist existing users, if they choose to update packages and the build 
tool changes.

There is also a loss of fidelity, but I'm reasonably sure that everyone 
will agree on it not being super useful if a script is deemed acceptable 
as a permanent utility. I don't necessarily have a problem with this 
either, this is no different than what distros do with their respective 
PMs, but I need to stress the word *permanent* here as I found it 
slightly ironic being that was a term I had used to describe the 
original problem with libtool archives! :-)

> For BLFS, I prefer a script to periodically remove all .la files when
> the user desires.  That would include scrubbing any .pc files that
> mention the .la files like serf-1.pc and excluding those that are needed
> by  lt_dlopen based packages.

That part is mostly done, but it needs some tweaks to the backups I think.

> As far as backups go, that could be done with a simple cp, if desired,
> each time the la files are removed.  Restoration would be a manual task,
> but I do not see that as a problem.

I now agree. The numbered backup scheme was way overkill. But, I'd like 
to take it a step further and copy only if it's not already in the 
backup location.

In short, I'm good with either method, as long as it gets taken care of. 
My preference is obviously the way I've proposed (with arguments above) 
over using the script, but let's see if anyone else has something to add.


More information about the lfs-dev mailing list