> From: DJ Lucas <[email protected]>
> Date: Fri, 16 Dec 2016 23:55:35 -0600
> Subject: Re: [blfs-dev] nosym branches
>
.
.
> > (4) But then, libtool/ltmain.sh/&c would throw warnings: cos they compare
> > two path variables' values, and just complain at that stage that
> > they're different; whereas if they (libtool/&c) went a little bit
> > further and resolved each path to their respective 'real' paths,
> > then it would be seen that they (the 'real' paths) were identical.
>
> This happens to be addressed in a round about way, but was not the
> driving force behind this change. Although functional, the symlink has
> always been a workaround. It has served us well, but as above, it is not
> really necessary any longer - nine package changes for all of LFS and
> BLFS. In fairness, many of the would be changes were already covered
> because of /opt installs for QT, KF5, Plasma, and LXQT.
>
> As to the libtool archives, there is more that can be done. Strictly
> speaking, they should be removed, but it's not something easily
> addressed in the books. I'd like to add a small blurb about this in the
> LFS introductory text someplace, but it doesn't really seem to fit
> anywhere. To be done properly, the .la files must be removed after every
> package is installed in Chapter 6 and for all of BLFS, and only at
> -maxdepth 1 for /lib and /usr/lib (and /usr/lib32 if applicable). I have
> a script that I had used, which I just tacked on to the end of each of
> the scripts in the chapter06 directory after generating the target
> JHALFS tree. The only one I had left last time I went through that
> exercise (libarchive.la) did not seem to be necessary this past time
> (IOW: I had no .la files in /usr/lib or /lib).
>
> >
> > (5) To try to 'solve' such behaviour, the warnings were suppressed;
> > but it meant being drawn into (again, a degree of) per-package
> > whac-a-mole.
>
> Yes, and again, while the new changes address this indirectly, it really
> is only a nice consequence of removing the symlink. It doesn't actually
> fix that particular problem, only hides it again with less work on the
> part of the user (or editors). Best for now is just to explain it and
> let the user decide whether to remove them or leave them. For the most
> part, they don't cause issues, especially without package management.
Is there some way, centrally/efficiently, to address the
libtool/ltmain.sh warnings.
E.g. slackware patches-out the pair of moved/removed lines of code,
in libtool's own os-installed ltmain.sh; and doesn't patch it out
of any other packages at compile-time; and does mostly does use
explicit '--libdir'/&c pkg cfg args; and _seems_ to not see any of the
moved/removed warnings when compiling such pkgs - even when /{,usr/}lib*
use some symlnks instead of slackware's usual all-dirs.
BUT, more work/avail-time on this here is needed, to get a more-definite
picture on that.
>
.
.
>
akh
--
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
