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] libtool/autotools [Was: nosym branches]

[akhiezer]

> From: DJ Lucas 
> Date: Fri, 16 Dec 2016 23:55:35 -0600
> Subject: Re: [blfs-dev] nosym branches
>
.
.
> > (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.
>
> 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'/ 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

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