On 12/16/2016 02:56 PM, akhiezer wrote:
From: DJ Lucas <[email protected]>
Date: Sun, 11 Dec 2016 17:10:28 -0600
Subject: Re: [blfs-dev] nosym branches
On 12/11/2016 03:58 PM, akhiezer wrote:
Link to patches?
Are you 'scripting'/parametrising all of the stuff according to 'bitness'
(32-bit or 64-bit) &/or whether user wants to do such a thing: or are
you just hard-wiring without regard for either parameter.
Done as per current books, taking into account 'bitness' ('bit width'
??). Feel free to diff the real branch if you'd like, but diffs are here
from my former working copy (updated):
http://www.linuxfromscratch.org/~dj/LFS-nosym-20161211.diff
http://www.linuxfromscratch.org/~dj/BLFS-nosym-20161211.diff
These are now compliant, as per your earlier concern shortly after
release,
Thanks for the links.
Haven't ran a build thru from those, 'fraid: but have read through the
diffs; and looks ok - tho' did have the following coupla queries.
(A) Noticed that creation of /usr{,/local}/lib64 is patched-out
('LFS-nosym-20161211.diff' : 'Index: chapter06/creatingdirs.xml') ;
but seemingly there is no equivalent replacement/'patch-in'. Might it
be prudent to still create them, as part of the new 'x86_64) mkdir -v
/lib64 ;;' ? (Tho' I guess that's partly what the requested real-build
testing would be for.)
That is by design as there is no need, nor requirement for them to be
there. The dynamic loader is the only library that is not position
independent. If using only from scratch, /lib64 directory can even be
rendered unnecessary (e.g.: my first draft), but as correctly cautioned
against earlier, this breaks LSB. What is going in to the book in just a
few minutes is what Debian and derivatives do (minus the /usr merge).
There might be a corner case for using binary packages that use rpath or
a libexec subdirectory, but these should be handled on an as-needed
basis. I haven't come across any, but I don't use many binary only packages.
(B) Just to check on some of the 'history' of how b/lfs has treated
lib64/&c.
Aiui, it seems that there has happened the following approx sequence:
====
(1) Some packages were by default installing into /lib64, and some into
/lib ; & sim for /usr/lib* &c.
These were all dirs.
(2) To avoid such splits, one could use ./configure args
'--libdir=...'/'--with-libdir=...', or similar 'make ...' args, etc.
But that can mean being drawn into (a degree of) per-package
whac-a-mole.
(3) Instead, a symlnk /lib -> /lib64 was used; & sim for /usr/lib ->
/usr/lib64, &c.
Yes, this was much more problematic when the symlink originally was put
into the book. Things have changed considerably in the past several
years. The autotools just do the right thing now days.
(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.
(6) Now, a mixture of '(1)' and '(2)', above, is being returned to: all
separate dirs again; and still (a degree of) per-package whac-a-mole
use of './configure'/make args '--libdir=...'/'--with-libdir=...'/&c,
particularly for cmake-based builds.
====
Is that about right - a reasonably accurate summary.
With above notations, seems accurate enough. Short of the handmade
Makefile for libcap, all of the affected packages use cmake. It seems to
me that this is a very minor deficiency with cmake, or more likely its
users (because many cmake packages do find the correct {,/usr}/lib
directories) as compared with autotools. I might take a look at it at
some point, but at least they provide a standard override.
--DJ
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
