On December 17, 2016 4:03:45 AM CST, [email protected] wrote: >> 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.
Sure, no file, no warning. :-) The "problem" is that they are there at all. However, I feel that I've done a bit of injustice in describing this and have intermixed two separate issues. Aside from the warnings, this generally isn't a problem for a build from scratch environment (unless you've been upgrading the same system across major changes of dependent libs). The warnings should effectively be resolved in our book, but it doesn't end at the warnings. See https://blog.flameeyes.eu/tags/lafiles/ A lot of reading, I know, but not dry reading. The bottom line is that they are no longer necessary and if you are packaging your builds, you should be removing them. I'll post the script I use in a bit. > > >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. Replacing ltmain.sh in every package is a perfectly valid option, but with little gain. I happen to think that just removing the files via post-install script or packaging is easier, maybe something that could be added to the JHALFS environment, but that's clearly an opinion...granted, one that seems to be shared by distributors, but they work in DESTDIR/install_root. Doing manually is error prone. > > >BUT, more work/avail-time on this here is needed, to get a >more-definite >picture on that. > page Hopefully the link above can at least help separate the two. --DJ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
