> 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.)
(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.
(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.
(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.
(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.
> and just for fun (I know it wasn't asked for by you, but
> example anyway):
>
> http://www.linuxfromscratch.org/~dj/lfs-systemd-multiarch/
> http://www.linuxfromscratch.org/~dj/lfs-multiarch/
>
(Have yet to have a look at these.)
rgds,
akh
--
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
