Re: [blfs-dev] nosym branches

[Bruce Dubbs]

DJ Lucas wrote:


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* 
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, 


In my nosym build I ran into a problem with graphviz.  A test is adding 
LIBPOSTFIX="64" and it is hard coded into configure.ac and thus configure.


My hack for that is:

  sed -i '/LIBPOSTFIX="64"/s/64//' configure.ac

but I have not tested it yet.  Of course it can be incorporated into the 
patch.


I wouldn't be surprised of other packages do the same type of thing, but 
we'll need to build everything to find out.  So far I've built 162 BLFS 
packages and this is the first problem I've seen.


  -- Bruce

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[Bruce Dubbs]

DJ Lucas wrote:



On December 17, 2016 2:26:29 PM CST, Bruce Dubbs  wrote:

DJ Lucas wrote:


I would use:

sed "/LIBDIR_DEFAULT/s/64//" -i.orig /Modules/GNUInstallDirs.cmake

which just changes lib64 to lib on two lines (lines 213 and 215).


Chris's original suggestion works fine, you could also just avoid the
logic by putting a NOT before EQUALS in the test (this will never be
true), but I think yours is more clear as to what the final goal is.

A

whole slew of ways to do this. Ultimately, I think this should be

done for

both cmake and extra-cmake-modules as suggested. I'm going to use

this

latest build for testing this, but this looks really good on the

surface.

On my way to KDE again shortly.


You can make the changes if you want, but be aware that there are new
versions of kf5, kf5-apps, and plasma out.  kf5 includes
extra-cmake-modules.  I was going to wait until January for those.  Do
you
want me to do those now and take care of cmake also?


I was only referring to a test build with existing versions to make certain 
that it doesn't have any unforeseen consequences. I can compare with my 
existing build.


OK, I'm sure you will let us know if any issues come up.

  -- Bruce


--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[DJ Lucas]

On December 17, 2016 2:26:29 PM CST, Bruce Dubbs  wrote:
>DJ Lucas wrote:
>
>>> I would use:
>>>
>>> sed "/LIBDIR_DEFAULT/s/64//" -i.orig /Modules/GNUInstallDirs.cmake
>>>
>>> which just changes lib64 to lib on two lines (lines 213 and 215).
>>
>> Chris's original suggestion works fine, you could also just avoid the
>> logic by putting a NOT before EQUALS in the test (this will never be
>> true), but I think yours is more clear as to what the final goal is.
>A
>> whole slew of ways to do this. Ultimately, I think this should be
>done for
>> both cmake and extra-cmake-modules as suggested. I'm going to use
>this
>> latest build for testing this, but this looks really good on the
>surface.
>> On my way to KDE again shortly.
>
>You can make the changes if you want, but be aware that there are new 
>versions of kf5, kf5-apps, and plasma out.  kf5 includes 
>extra-cmake-modules.  I was going to wait until January for those.  Do
>you 
>want me to do those now and take care of cmake also?

I was only referring to a test build with existing versions to make certain 
that it doesn't have any unforeseen consequences. I can compare with my 
existing build.

--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

Re: [blfs-dev] nosym branches

[Bruce Dubbs]

DJ Lucas wrote:


I would use:

sed "/LIBDIR_DEFAULT/s/64//" -i.orig /Modules/GNUInstallDirs.cmake

which just changes lib64 to lib on two lines (lines 213 and 215).


Chris's original suggestion works fine, you could also just avoid the
logic by putting a NOT before EQUALS in the test (this will never be
true), but I think yours is more clear as to what the final goal is. A
whole slew of ways to do this. Ultimately, I think this should be done for
both cmake and extra-cmake-modules as suggested. I'm going to use this
latest build for testing this, but this looks really good on the surface.
On my way to KDE again shortly.


You can make the changes if you want, but be aware that there are new 
versions of kf5, kf5-apps, and plasma out.  kf5 includes 
extra-cmake-modules.  I was going to wait until January for those.  Do you 
want me to do those now and take care of cmake also?


  -- Bruce


--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[DJ Lucas]

On 12/17/2016 11:08 AM, Bruce Dubbs wrote:

DJ Lucas wrote:



On 12/17/2016 12:41 AM, Chris Staub wrote:

On 12/17/2016 12:55 AM, DJ Lucas wrote:




(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=...'/,
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


I believe some or possibly all of the affected packages that use Cmake
are using its "GNUInstallDirs" module, which automatically installs to
"lib64" if it determines that you have a 64-bit system. Therefore, you
may be able to eliminate modification of most or all of these packages
by editing the GNUInstallDirs module. Specifically, it has an if
statement that checks "CMAKE_SIZEOF_VOID_P" and assumes 64 bits if it
equals "8". I assume there's a more elegant solution, but I currently
use this hack to edit the size it looks for so it doesn't match:

sed -i '/CMAKE_SIZEOF_VOID_P.*EQUAL/s/8/88/'
Modules/GNUInstallDirs.cmake


Thanks Chris. That's incredibly helpful! Initially, I had though
'/CMAKE_SIZEOF_VOID_P.*EQUAL/s/EQUAL/NOT EQUAL/' and apply lib32, but the
test would never be true (the lib64/lib32 is useless). How about this
incredibly beautiful solution?

if "$(uname -m)" == "x86_64"; then
sed '/\n.*/!N;/.*\n.*CMAKE_SIZEOF_VOID_P.*EQUAL/{$d;N;N;N;N;N;d};P;D' \
 -i.bak GNUInstallDirs.cmake
fi

It's even uglier on the console! In short, delete 1 line before and five
lines after the pattern and the line containing the match. :-) Yep,
patch!
Anyway, just kill the else clause in its entirety. The reverse would
never
be true. I tested quick and it seems to work as expected.


Wow, that is ugly.


:-) In my defense, I wanted to get rid of the else clause in its 
entirety (which does work for at least libical - only thing I had handy 
at the time).



I would use:

sed "/LIBDIR_DEFAULT/s/64//" -i.orig /Modules/GNUInstallDirs.cmake

which just changes lib64 to lib on two lines (lines 213 and 215).


Chris's original suggestion works fine, you could also just avoid the 
logic by putting a NOT before EQUALS in the test (this will never be 
true), but I think yours is more clear as to what the final goal is. A 
whole slew of ways to do this. Ultimately, I think this should be done 
for both cmake and extra-cmake-modules as suggested. I'm going to use 
this latest build for testing this, but this looks really good on the 
surface. On my way to KDE again shortly.


--DJ

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[Bruce Dubbs]

DJ Lucas wrote:



On 12/17/2016 12:41 AM, Chris Staub wrote:

On 12/17/2016 12:55 AM, DJ Lucas wrote:




(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=...'/,
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


I believe some or possibly all of the affected packages that use Cmake
are using its "GNUInstallDirs" module, which automatically installs to
"lib64" if it determines that you have a 64-bit system. Therefore, you
may be able to eliminate modification of most or all of these packages
by editing the GNUInstallDirs module. Specifically, it has an if
statement that checks "CMAKE_SIZEOF_VOID_P" and assumes 64 bits if it
equals "8". I assume there's a more elegant solution, but I currently
use this hack to edit the size it looks for so it doesn't match:

sed -i '/CMAKE_SIZEOF_VOID_P.*EQUAL/s/8/88/' Modules/GNUInstallDirs.cmake


Thanks Chris. That's incredibly helpful! Initially, I had though
'/CMAKE_SIZEOF_VOID_P.*EQUAL/s/EQUAL/NOT EQUAL/' and apply lib32, but the
test would never be true (the lib64/lib32 is useless). How about this
incredibly beautiful solution?

if "$(uname -m)" == "x86_64"; then
sed '/\n.*/!N;/.*\n.*CMAKE_SIZEOF_VOID_P.*EQUAL/{$d;N;N;N;N;N;d};P;D' \
 -i.bak GNUInstallDirs.cmake
fi

It's even uglier on the console! In short, delete 1 line before and five
lines after the pattern and the line containing the match. :-) Yep, patch!
Anyway, just kill the else clause in its entirety. The reverse would never
be true. I tested quick and it seems to work as expected.


Wow, that is ugly.  I would use:

sed "/LIBDIR_DEFAULT/s/64//" -i.orig /Modules/GNUInstallDirs.cmake

which just changes lib64 to lib on two lines (lines 213 and 215).

  -- Bruce

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[akhiezer]

> From: DJ Lucas 
> Date: Fri, 16 Dec 2016 21:48:20 -0600
> Subject: Re: [blfs-dev] multiarch [Was: nosym branches]
>
.
.
> I don't intend to carry them forward. I might throw something in the 
> wiki some day, but I though it important to show at least one working 
> example being that it was brought up.
>


Would it be a good fit to have the chapter (or similar) near to the
'virtualisation' chapter in blfs.



akh




--
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[Chris Staub]

On 12/17/2016 01:41 AM, Chris Staub wrote:

On 12/17/2016 12:55 AM, DJ Lucas wrote:




(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=...'/,
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


I believe some or possibly all of the affected packages that use Cmake
are using its "GNUInstallDirs" module, which automatically installs to
"lib64" if it determines that you have a 64-bit system. Therefore, you
may be able to eliminate modification of most or all of these packages
by editing the GNUInstallDirs module. Specifically, it has an if
statement that checks "CMAKE_SIZEOF_VOID_P" and assumes 64 bits if it
equals "8". I assume there's a more elegant solution, but I currently
use this hack to edit the size it looks for so it doesn't match:

sed -i '/CMAKE_SIZEOF_VOID_P.*EQUAL/s/8/88/' Modules/GNUInstallDirs.cmake


A similar change can be made to kde-modules/KDEInstallDirs.cmake for the 
extra-cmake-modules package. This should take care of KDE packages that 
include that module, such as oxygen-fonts.

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[DJ Lucas]

On 12/17/2016 12:41 AM, Chris Staub wrote:

On 12/17/2016 12:55 AM, DJ Lucas wrote:




(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=...'/,
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


I believe some or possibly all of the affected packages that use Cmake
are using its "GNUInstallDirs" module, which automatically installs to
"lib64" if it determines that you have a 64-bit system. Therefore, you
may be able to eliminate modification of most or all of these packages
by editing the GNUInstallDirs module. Specifically, it has an if
statement that checks "CMAKE_SIZEOF_VOID_P" and assumes 64 bits if it
equals "8". I assume there's a more elegant solution, but I currently
use this hack to edit the size it looks for so it doesn't match:

sed -i '/CMAKE_SIZEOF_VOID_P.*EQUAL/s/8/88/' Modules/GNUInstallDirs.cmake


Thanks Chris. That's incredibly helpful! Initially, I had though 
'/CMAKE_SIZEOF_VOID_P.*EQUAL/s/EQUAL/NOT EQUAL/' and apply lib32, but 
the test would never be true (the lib64/lib32 is useless). How about 
this incredibly beautiful solution?


if "$(uname -m)" == "x86_64"; then
sed '/\n.*/!N;/.*\n.*CMAKE_SIZEOF_VOID_P.*EQUAL/{$d;N;N;N;N;N;d};P;D' \
-i.bak GNUInstallDirs.cmake
fi

It's even uglier on the console! In short, delete 1 line before and five 
lines after the pattern and the line containing the match. :-) Yep, 
patch! Anyway, just kill the else clause in its entirety. The reverse 
would never be true. I tested quick and it seems to work as expected.


--DJ

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[Chris Staub]

On 12/17/2016 12:55 AM, DJ Lucas wrote:




(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=...'/,
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


I believe some or possibly all of the affected packages that use Cmake 
are using its "GNUInstallDirs" module, which automatically installs to 
"lib64" if it determines that you have a 64-bit system. Therefore, you 
may be able to eliminate modification of most or all of these packages 
by editing the GNUInstallDirs module. Specifically, it has an if 
statement that checks "CMAKE_SIZEOF_VOID_P" and assumes 64 bits if it 
equals "8". I assume there's a more elegant solution, but I currently 
use this hack to edit the size it looks for so it doesn't match:


sed -i '/CMAKE_SIZEOF_VOID_P.*EQUAL/s/8/88/' Modules/GNUInstallDirs.cmake
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[DJ Lucas]

On 12/16/2016 03:14 PM, akhiezer wrote:

From: DJ Lucas <d...@linuxfromscratch.org>
Date: Sun, 11 Dec 2016 17:10:28 -0600
Subject: Re: [blfs-dev] nosym branches


.
.

release, 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/




In case these are going to be carried-fwd, as opposed to once-offs:


I don't intend to carry them forward. I might throw something in the 
wiki some day, but I though it important to show at least one working 
example being that it was brought up.




* the 'Details of this package ...' links seem to be a bit mis-wired
  on the following pages in each book's ch.6:


Ahh, yes, the result of sloppy seds. Since it was just a mock-up, 
obviously not much care was give beyond the instructions. Thank you for 
the review though.


--DJ

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[akhiezer]

> From: DJ Lucas <d...@linuxfromscratch.org>
> Date: Sun, 11 Dec 2016 17:10:28 -0600
> Subject: Re: [blfs-dev] nosym branches
>
.
.
> release, 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/
>


In case these are going to be carried-fwd, as opposed to once-offs:
--
* both seem to be sysd.

* the 'Details of this package ...' links seem to be a bit mis-wired
  on the following pages in each book's ch.6:

   * Binutils-2.27 Multilib (temp)
   * GCC-6.2.0 Multilib (temp)
   * Glibc-2.24 32-bit (temp)
   * Binutils-2.27 Multilib
   * GCC-6.2.0 Multilib
   * Glibc-2.24 Multilib
--



akh





--
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[akhiezer]

> From: DJ Lucas <d...@linuxfromscratch.org>
> 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/

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* 
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, 

(4) But then, libtool/ltmain.sh/ would throw warnings: cos they compare
two path variables' values, and just complain at that stage that
they're different; whereas if they (libtool/) 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=...'/,
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

Re: [blfs-dev] nosym branches

[DJ Lucas]

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, 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/

--DJ

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Re: [blfs-dev] nosym branches

[akhiezer]

> From: DJ Lucas <d...@linuxfromscratch.org>
> Date: Sat, 10 Dec 2016 23:37:29 -0600
> Subject: [blfs-dev] nosym branches
>
> Howdy all. You might have noticed the nosym branches in SVN. This 
> removes the /usr/lib64 symlink and replaces the /lib64 symlink with a 
> directory containing only the symlinks to the dynamic loader for x86_64. 
> The changes are actually pretty minimal, excluding the change to 
> t-linux64 in the gcc builds and all of the removed changes to ltmain.sh 
> (..lib/whatever.la has been moved), there are changes to eight packages 
> in BLFS and one in LFS (where libdir must be specified). AFAICT, those 
> nine changes should have no effect on builds where GCC is not modified. 
> Although it's already been tested pretty thoroughly, I'd appreciate just 
> a tad of wider testing before the changes land in trunk. If you've 
> already built from the patches that have been floating around in my home 
> directory over the past few months, then you are already up to date with 
> the branches.
>


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.



rgds,
akh





--
-- 
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

[blfs-dev] nosym branches

[DJ Lucas]

Howdy all. You might have noticed the nosym branches in SVN. This 
removes the /usr/lib64 symlink and replaces the /lib64 symlink with a 
directory containing only the symlinks to the dynamic loader for x86_64. 
The changes are actually pretty minimal, excluding the change to 
t-linux64 in the gcc builds and all of the removed changes to ltmain.sh 
(..lib/whatever.la has been moved), there are changes to eight packages 
in BLFS and one in LFS (where libdir must be specified). AFAICT, those 
nine changes should have no effect on builds where GCC is not modified. 
Although it's already been tested pretty thoroughly, I'd appreciate just 
a tad of wider testing before the changes land in trunk. If you've 
already built from the patches that have been floating around in my home 
directory over the past few months, then you are already up to date with 
the branches.


TIA

--DJ

--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page