Re: [lfs-dev] Multilib patch

2020-03-24 Thread Thomas Trepl via lfs-dev 
Am Dienstag, den 24.03.2020, 12:44 -0500 schrieb Timothy Russo via
lfs-dev:
> Whatever happened to the multilib patch?  I was following the thread back in 
> August 2018:
> On 08/25/2018 12:13 AM, DJ Lucas wrote:
> 
> > One more thing, need to add lib32 paths to remove-la-files.sh. I, thus 
> > far, have not messed with lib32x. I used a separate path for  files in 
> > /usr/lib32. Same for /usr/lib32/pkgconfig and /usr/local/lib32/pkgconfig.
> > 
> 
> On second thought, there is no purpose for the pc files in 
> /usr/lib32/pkgconfig, should just remove the directory if it exists. 
> Regardless of the libdir value in the pc file, the libraries themselves 
> will always be in the library search path because of our change to 
> /etc/ld.so.conf.
> 
> --DJ
> 
> and then it seemed to die. 
> I've found this: http://www.linuxfromscratch.org/~dj/lfs-systemd-multilib/
> from Nov 2018.
> However, I'd love to help/test/edit an updated multilib patch to work against 
> the current 9.1 version of LFS/BLFS.
> I was able to get my printer to work with multilib using these outdated 
> references, but I was only able to get steam to function with a flatpak.
> If DJ or Thomas would like to revisit the multilib patch or 
> lfs-systemd-multilib version of the book, I'd love to help.

Hi Tim,

ML is still maintained - well, basically its a periodical merge of the
trunk to the branch and subsequently fixing clashes ;-)

You can find it at 
http://www.linuxfromscratch.org/~thomas/multilib/index.html

and the sources are in a branch named 'multilib' in SVN. Feel free to
post patches/ideas/remarks!

--
Thomas


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

[lfs-dev] Multilib patch

2020-03-24 Thread Timothy Russo via lfs-dev 
Whatever happened to the multilib patch?  I was following the thread back
in August 2018:

On 08/25/2018 12:13 AM, DJ Lucas wrote:

>* One more thing, need to add lib32 paths to remove-la-files.sh. I, thus
*>* far, have not messed with lib32x. I used a separate path for  files in
*>* /usr/lib32. Same for /usr/lib32/pkgconfig and /usr/local/lib32/pkgconfig.
*>
On second thought, there is no purpose for the pc files in
/usr/lib32/pkgconfig, should just remove the directory if it exists.
Regardless of the libdir value in the pc file, the libraries themselves
will always be in the library search path because of our change to
/etc/ld.so.conf.

--DJ


and then it seemed to die.

I've found this: http://www.linuxfromscratch.org/~dj/lfs-systemd-multilib/

from Nov 2018.

However, I'd love to help/test/edit an updated multilib patch to work
against the current 9.1 version of LFS/BLFS.

I was able to get my printer to work with multilib using these
outdated references, but I was only able to get steam to function with
a flatpak.

If DJ or Thomas would like to revisit the multilib patch or
lfs-systemd-multilib version of the book, I'd love to help.

Thanks,

Tim Russo
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib patch: ncurses 64-bit build wants to use /usr/lib32/pkgconfig

2019-03-23 Thread Bruce Dubbs via lfs-dev 

On 3/23/19 11:36 AM, Bruce Dubbs wrote:

On 3/23/19 3:48 AM, Kevin Buckley via lfs-dev wrote:
Once again,not sure of this is LFS-dev related, so wanted to ask, for 
future

reference,

   are "Multilib patch:" discussions mre suited to another LFS list 
than lfs-dev:

   maybe they are a good fit for CLFS ?


These discussions are fine here.


And while I'm thinking about it, there is no reason why is can't be 
hosted in svn at LFS/branches/multilib or similar.


  -- Bruce

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

Re: [lfs-dev] Multilib patch: ncurses 64-bit build wants to use /usr/lib32/pkgconfig

2019-03-23 Thread Bruce Dubbs via lfs-dev 

On 3/23/19 3:48 AM, Kevin Buckley via lfs-dev wrote:

Once again,not sure of this is LFS-dev related, so wanted to ask, for future
reference,

   are "Multilib patch:" discussions mre suited to another LFS list than 
lfs-dev:
   maybe they are a good fit for CLFS ?


These discussions are fine here.

  -- Bruce

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

Re: [lfs-dev] Multilib patch: ncurses 64-bit build wants to use /usr/lib32/pkgconfig

2019-03-23 Thread Thomas Trepl via lfs-dev 
Am Samstag, den 23.03.2019, 17:39 +0800 schrieb Xi Ruoyao via lfs-dev:
> On Sat, 2019-03-23 at 16:48 +0800, Kevin Buckley via lfs-dev wrote:
*snip*
> > Anyroad, just came to do Chapter 6 ncurses after applying Thomas's patch
> > (note also I am doing a PkgUser build) and saw
> > 
> > ** Configuration summary for NCURSES 6.1 20180127:
> > 
> >extended funcs: yes
> >xterm terminfo: xterm-new
> > 
> > bin directory: /usr/bin
> > lib directory: /usr/lib
> > include directory: /usr/include
> > man directory: /usr/share/man
> >terminfo directory: /usr/share/terminfo
> >  pkg-config directory: /usr/lib32/pkgconfig
> > 
> > and was surprised by the 32-bit Pkg-conf dir.
> 
> *snip*
> 
> > and so I thimk that the ncurses configure search "falls through" to 
> > /usr/lib32
> > where it finds a directory named 'pkgconfig'
> > 
> > The suggestion in the Ncurses build is that one can explicitly specify the
> > pkg-config directory by using a flag to ./configure.
> 
> Yes. --with-pkg-config-libdir=/usr/lib64/pkgconfig would work.
> 
> > Maybe that's something Thomas needs to add to his patch ?

Thanks Kevin and Xi,  good spot!
Also the symlinks created later in that chapter for ncurses, form, panel and 
menu are invalid
as ncursesw.pc does not exist in /usr/lib.

I think I have to add --with-pkg-config-libdir=/usr/lib/pkgconfig (not 
.../lib64/...) since we do
not have a /usr/lib64 at all, /usr/lib is the 'default' for 64bit.
For the 32bit builds, this configure argument is set allready.

Alternativly, we could do a sed to remove lib32 in configure for the *64 case:
sed -e "/cf_path\/lib64/{n;d}" -i configure
but i think the configure argument is less intrusive and works well.

ML-patch is modified.

--
Thomas


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

Re: [lfs-dev] Multilib patch: ncurses 64-bit build wants to use /usr/lib32/pkgconfig

2019-03-23 Thread Xi Ruoyao via lfs-dev 
On Sat, 2019-03-23 at 16:48 +0800, Kevin Buckley via lfs-dev wrote:
> Once again,not sure of this is LFS-dev related, so wanted to ask, for future
> reference,
> 
>   are "Multilib patch:" discussions mre suited to another LFS list than lfs-
> dev:
>   maybe they are a good fit for CLFS ?

CLFS has been splited from LFS.  I think it's proper to discuss Multilib issues
in lfs-dev.

> Anyroad, just came to do Chapter 6 ncurses after applying Thomas's patch
> (note also I am doing a PkgUser build) and saw
> 
> ** Configuration summary for NCURSES 6.1 20180127:
> 
>extended funcs: yes
>xterm terminfo: xterm-new
> 
> bin directory: /usr/bin
> lib directory: /usr/lib
> include directory: /usr/include
> man directory: /usr/share/man
>terminfo directory: /usr/share/terminfo
>  pkg-config directory: /usr/lib32/pkgconfig
> 
> and was surprised by the 32-bit Pkg-conf dir.

*snip*

> and so I thimk that the ncurses configure search "falls through" to /usr/lib32
> where it finds a directory named 'pkgconfig'
> 
> The suggestion in the Ncurses build is that one can explicitly specify the
> pkg-config directory by using a flag to ./configure.

Yes. --with-pkg-config-libdir=/usr/lib64/pkgconfig would work.

> Maybe that's something Thomas needs to add to his patch ?
-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

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

[lfs-dev] Multilib patch: ncurses 64-bit build wants to use /usr/lib32/pkgconfig

2019-03-23 Thread Kevin Buckley via lfs-dev 
Once again,not sure of this is LFS-dev related, so wanted to ask, for future
reference,

  are "Multilib patch:" discussions mre suited to another LFS list than lfs-dev:
  maybe they are a good fit for CLFS ?

Anyroad, just came to do Chapter 6 ncurses after applying Thomas's patch
(note also I am doing a PkgUser build) and saw

** Configuration summary for NCURSES 6.1 20180127:

   extended funcs: yes
   xterm terminfo: xterm-new

bin directory: /usr/bin
lib directory: /usr/lib
include directory: /usr/include
man directory: /usr/share/man
   terminfo directory: /usr/share/terminfo
 pkg-config directory: /usr/lib32/pkgconfig

and was surprised by the 32-bit Pkg-conf dir.

Looking as the configure script suggests that, for a 64-bit `arch`

   # If you don't like using the default architecture, you have to
specify the
# intended library directory and corresponding compiler/linker options.
#
# This case allows for Debian's 2014-flavor of multiarch, along with the
# most common variations before that point.  Some other
variants spell the
# directory differently, e.g., "pkg-config", and put it in
unusual places.
# pkg-config has always been poorly standardized, which is ironic...
case x`(arch) 2>/dev/null` in
(*64)
cf_search_path="\
$cf_path/lib/*64-linux-gnu \
$cf_path/share \
$cf_path/lib64 \
$cf_path/lib32 \
$cf_path/lib"
;;

that configure will look at those paths to find the location in which to
install the Ncurses pkg-config files..

Looking at what my system has below /usr at this point in the build

pkg ncurses:ncurses-6.1> ls -o /usr/
total 40
drwxrwxr-t  2 root 4096 Mar 23 07:50 bin
drwxrwxr-t 34 root 4096 Mar 23 07:47 include
drwxrwxr-t 10 root 4096 Mar 23 07:50 lib
drwxrwxr-t  6 root 4096 Mar 23 07:48 lib32
drwxrwxr-t  4 root 4096 Mar 23 07:42 libexec
drwxrwxr-t  5 root 4096 Mar 23 07:48 libx32
drwxr-xr-x  8 root 4096 Mar 17 02:42 local
drwxrwxr-t  2 root 4096 Mar 17 12:07 sbin
drwxrwxr-t 15 root 4096 Mar 23 07:50 share
drwxr-xr-x 80 root 4096 Mar 17 04:20 src

then we see that there is no explicit

/usr/lib64

FWIW, at this point in the build I have somethig in all three of the 'arch'
pkgconfig directories, vis:

pkg ncurses:ncurses-6.1> ls /usr/lib/pkgconfig
isl.pc  mpfr.pc  readline.pc  zlib.pc
pkg ncurses:ncurses-6.1> ls /usr/lib32/pkgconfig
readline.pc  zlib.pc
pkg ncurses:ncurses-6.1> ls /usr/libx32/pkgconfig
readline.pc  zlib.pc


and so I thimk that the ncurses configure search "falls through" to /usr/lib32
where it finds a directory named 'pkgconfig'

The suggestion in the Ncurses build is that one can explicitly specify the
pkg-config directory by using a flag to ./configure.

Maybe that's something Thomas needs to add to his patch ?

Open to any other suggestions though
Kevin
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib patch

2019-02-21 Thread Thomas Trepl via lfs-dev 
Am Mittwoch, den 20.02.2019, 18:03 +0800 schrieb Kevin Buckley via
lfs-dev:
> Just wanted to tidy up the "loose end" here by saying that I did get an LFS
> that was able to build Xen 4.10 going by using the Mutlilib patch against
> LFS 8.3, and all this using a PkgUser approach.
> 
> I have been tracking the changes I made in a local SVN, but am thinking
> that I will wait for the 8.4 release before trying to feedback anything into 
> the
> community.
> 
> Thanks again for the MultiLib patch and feedback in this thread.
> Kevin

Cool stuff and thanks for the feedback - this one and the one may
come!

--
Thomas

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

Re: [lfs-dev] Multilib patch

2019-02-21 Thread Thomas Trepl via lfs-dev 
Am Mittwoch, den 20.02.2019, 18:03 +0800 schrieb Kevin Buckley via
lfs-dev:
> Just wanted to tidy up the "loose end" here by saying that I did get an LFS
> that was able to build Xen 4.10 going by using the Mutlilib patch against
> LFS 8.3, and all this using a PkgUser approach.
> 
> I have been tracking the changes I made in a local SVN, but am thinking
> that I will wait for the 8.4 release before trying to feedback anything into 
> the
> community.
> 
> Thanks again for the MultiLib patch and feedback in this thread.
> Kevin

Cool stuff and thanks for the feedback!

--
Thomas

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

Re: [lfs-dev] Multilib patch

2019-02-20 Thread Kevin Buckley via lfs-dev 
Just wanted to tidy up the "loose end" here by saying that I did get an LFS
that was able to build Xen 4.10 going by using the Mutlilib patch against
LFS 8.3, and all this using a PkgUser approach.

I have been tracking the changes I made in a local SVN, but am thinking
that I will wait for the 8.4 release before trying to feedback anything into the
community.

Thanks again for the MultiLib patch and feedback in this thread.
Kevin
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib patch: Chapter 6 ISL/GCC instructions

2019-01-12 Thread Thomas Trepl via lfs-dev 
Am Sonntag, den 13.01.2019, 12:48 +0800 schrieb Kevin Buckley via lfs-
dev:
> More of a heads up than somethng likley to affect most LFS builders,
> but just to point out that one of the last commands in the GCC section
> does the following
> 
> =
> Finally, move a misplaced file:
> 
> mkdir -pv /usr/share/gdb/auto-load/usr/lib
> mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib
> ==
> 
> 
> however by the time you have reached that point in the
> Multilib buid, there are actually two files matching
> 
> /usr/lib/*gdb.py
> 
> as the standalone ISL install has created
> 
> /usr/lib/libisl.so.19.1.0-gdb.py
> 
> to go along with GGC's
> 
> /usr/lib/libstdc++.so.6.0.25-gdb.py
> 
> 
> To my mind then, the directory creation should be really
> being done as part of the ISL section, with the misplaced
> file from that package being moved there then.
> 
> 
> FYI:
> 
> I only noticed this as I'm following a PkgUser build process,
> and saw that the GCC PkgUser wasn't able to move the
> file that had been created by the ISL PkgUser
> 
> Hoping that's useful to someone,
> Kevin

I modified the patch to move those files at ISL and GCC separatly.

--
Thomas

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

[lfs-dev] Multilib patch: Chapter 6 ISL/GCC instructions

2019-01-12 Thread Kevin Buckley via lfs-dev 
More of a heads up than somethng likley to affect most LFS builders,
but just to point out that one of the last commands in the GCC section
does the following

=
Finally, move a misplaced file:

mkdir -pv /usr/share/gdb/auto-load/usr/lib
mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib
==


however by the time you have reached that point in the
Multilib buid, there are actually two files matching

/usr/lib/*gdb.py

as the standalone ISL install has created

/usr/lib/libisl.so.19.1.0-gdb.py

to go along with GGC's

/usr/lib/libstdc++.so.6.0.25-gdb.py


To my mind then, the directory creation should be really
being done as part of the ISL section, with the misplaced
file from that package being moved there then.


FYI:

I only noticed this as I'm following a PkgUser build process,
and saw that the GCC PkgUser wasn't able to move the
file that had been created by the ISL PkgUser

Hoping that's useful to someone,
Kevin
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Multilib patch: Chapter 6 GMP instructions

2019-01-11 Thread Kevin Buckley via lfs-dev 
Quick one on this part of the patch.

The usual GMP instructions have two notes

==
If you are building for 32-bit x86, but you have a CPU which is
capable of running 64-bit code and you have specified CFLAGS in the
environment, the configure script will attempt to configure for
64-bits and fail. Avoid this by invoking the configure command below
with

ABI=32 ./configure ...
==

and

==
The default settings of GMP produce libraries optimized for the host
processor. If libraries suitable for processors less capable than the
host's CPU are desired, generic libraries can be created by running
the following:

cp -v configfsf.guess config.guess
cp -v configfsf.sub   config.sub


however, in the 32-bit and x32-bit sections, we see that the configure command
has the ABI= addition, as one might expect, but also that the copying of the
config,guess and config.sub  are "in-line",


Generic libraries can be created by running the following:

cp -v configfsf.guess config.guess
cp -v configfsf.sub   config.sub


suggesting that they are needed for both 32-bit builds.

Is that they case ?

Or should those two stanzas just be a "Note", if one is not building 32-bit
for use on the "build" processor ?

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

Re: [lfs-dev] Multilib patch

2019-01-06 Thread Kevin Buckley via lfs-dev 
Have since had some joy, falling back to what I did before, in that I

1) Buidt the basic Chapter 5 toolchain in /tools using the default LFS book

Basically then, just

Binutils-2.31.1 - Pass 1
GCC-8.2.0 - Pass 1
Linux-4.18.5 API Headers
Glibc-2.28
Libstdc++ from GCC-8.2.0
Binutils-2.31.1 - Pass 2
GCC-8.2.0 - Pass 2

FWIW, I also needed to build a Make 4.2.1 as the Ubuntu 14.04 one was too
old for one of the packages above.

2) Used the minimal Chapter 5 toolchain from /tools to build the
Chapter 5 multilib
toolchain, making sure to prepend all of the configure commands with
defintions, for CC CXX AR and so on, that pointed to the prefixed names
just in case something might be sneaking in off of the host.

This appears to have worked, so I am even more convinced that my
issues wew host-related.

Cheers for the feedback though.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib patch

2019-01-06 Thread Thomas Trepl via lfs-dev 
Am Sonntag, den 06.01.2019, 14:16 +0800 schrieb Kevin Buckley via lfs-
dev:
> A web search for my GCC-internal zlib config error
> 
> configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES
> 
> turned up, amongst others, these two, the first of which results from
> an LFS build !
> 
> https://stackoverflow.com/questions/46487529/crosscompiling-gcc-link-tests-are-not-allowed-after-gcc-no-executables-when-che
> 
> https://github.com/easybuilders/easybuild-easyconfigs/issues/3964
> 
> 
> The second of those suggests that it may be the lack of a "multilib capable"
> toolchain ON THE HOST that is the issue for me?
No, i've just tested building it from an LFS-8.2 without ML. That is
what chapter 5 is for - make us (more or less) independent from host.

> With that in mind, I'm coming back to my original remarks about rebuidling
> in that:
> 
> the way I last "upgraded" an x86_64 LFS to have multilib capibilty was by
> following one of DJ's old books, wherein things were effectively done in
> these stages:
> 
> x86_64 host -> x86_64 LFS-tools
> x86_64 LFS-tools -> x86_64 LFS
> x86_64 LFS -> Multilib LFS-tools components
> Multilib LFS-tools -> Multilib LFS components
> 
> Indeed, after the Binutills pass1 now, the only file in /tools/bin are
> 
> 
> x86_64-lfs-linux-gnu-addr2line  x86_64-lfs-linux-gnu-nm
> x86_64-lfs-linux-gnu-ar x86_64-lfs-linux-gnu-objcopy
> x86_64-lfs-linux-gnu-as x86_64-lfs-linux-gnu-objdump
> x86_64-lfs-linux-gnu-c++filtx86_64-lfs-linux-gnu-ranlib
> x86_64-lfs-linux-gnu-elfeditx86_64-lfs-linux-gnu-readelf
> x86_64-lfs-linux-gnu-gprof  x86_64-lfs-linux-gnu-size
> x86_64-lfs-linux-gnu-ld x86_64-lfs-linux-gnu-strings
> x86_64-lfs-linux-gnu-ld.bfd x86_64-lfs-linux-gnu-strip
> 
> suggesting that any non-x86_64 stuff has to come from the host ?
There is not much to see in ch5-binutils-pass1.

> 
> Then again, you've stated that your sucessful build came from an
> non-multilib host.
Yes, see above.

> FYI, my host (Ubuntu 1404 - yes. old, yes) has
> 
> Binutils: (GNU Binutils for Ubuntu) 2.24
> gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
> (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19
> 
> so is a little diferent to what the Multilib book suggests things
> have been tested against, bis:
> 
> Binutils-2.25 (Versions greater than 2.31.1 are not recommended as
> they have not been tested)
> GCC-4.9 including the C++ compiler, g++ (Versions greater than 8.2.0
> are not recommended as they have not been tested)
> Glibc-2.11 (Versions greater than 2.28 are not recommended as they
> have not been tested)
H, usually we do not dig around in issues with hosts doesn't match
the requirements. Anyway, the "oldest" thing i have around is a
CentOS7. Tried to build there, but failed with quite simmilar messages
at ch5-gcc-pass1.

> I think I may find the best way forwards to be one in which I build an
> non-Multilib LFS 8-3
> and then use that to boostrap the Multilib one, as that would give me
> a "host" with
> 
> Binutils-2.31.1
> GCC-8.2.0
> Glibc-2.28

Thats what I'd suggest - then we have a well defined environment. Make
sure that the running kernel is 32-bit-enabled

[*] 64-bit kernel
...
Executable file formats / Emulations  --->
[*] IA32 Emulation
[*] x32 ABI for 64-bit mode

> 
> Just out of interest then, what are the Binutils, GCC, Glibc versions on
> the "non-multilib" host that your Multilib buils suceeds ?
The only non-ML (but kernel is 32bit-enabled) i have around is a LFS-
8.1+ machine which is actually from 2018/01/01. gcc is 7.2.0, glibc is
2.26, binutils-2.29.1.  There the built ran smoothly.

--
Thomas


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

Re: [lfs-dev] Multilib patch

2019-01-05 Thread Kevin Buckley via lfs-dev 
A web search for my GCC-internal zlib config error

configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES

turned up, amongst others, these two, the first of which results from
an LFS build !

https://stackoverflow.com/questions/46487529/crosscompiling-gcc-link-tests-are-not-allowed-after-gcc-no-executables-when-che

https://github.com/easybuilders/easybuild-easyconfigs/issues/3964


The second of those suggests that it may be the lack of a "multilib capable"
toolchain ON THE HOST that is the issue for me?

With that in mind, I'm coming back to my original remarks about rebuidling
in that:

the way I last "upgraded" an x86_64 LFS to have multilib capibilty was by
following one of DJ's old books, wherein things were effectively done in
these stages:

x86_64 host -> x86_64 LFS-tools
x86_64 LFS-tools -> x86_64 LFS
x86_64 LFS -> Multilib LFS-tools components
Multilib LFS-tools -> Multilib LFS components

Indeed, after the Binutills pass1 now, the only file in /tools/bin are


x86_64-lfs-linux-gnu-addr2line  x86_64-lfs-linux-gnu-nm
x86_64-lfs-linux-gnu-ar x86_64-lfs-linux-gnu-objcopy
x86_64-lfs-linux-gnu-as x86_64-lfs-linux-gnu-objdump
x86_64-lfs-linux-gnu-c++filtx86_64-lfs-linux-gnu-ranlib
x86_64-lfs-linux-gnu-elfeditx86_64-lfs-linux-gnu-readelf
x86_64-lfs-linux-gnu-gprof  x86_64-lfs-linux-gnu-size
x86_64-lfs-linux-gnu-ld x86_64-lfs-linux-gnu-strings
x86_64-lfs-linux-gnu-ld.bfd x86_64-lfs-linux-gnu-strip

suggesting that any non-x86_64 stuff has to come from the host ?

Then again, you've stated that your sucessful build came from an
non-multilib host.

FYI, my host (Ubuntu 1404 - yes. old, yes) has

Binutils: (GNU Binutils for Ubuntu) 2.24
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.4) 4.8.4
(Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19

so is a little diferent to what the Multilib book suggests things
have been tested against, bis:

Binutils-2.25 (Versions greater than 2.31.1 are not recommended as
they have not been tested)
GCC-4.9 including the C++ compiler, g++ (Versions greater than 8.2.0
are not recommended as they have not been tested)
Glibc-2.11 (Versions greater than 2.28 are not recommended as they
have not been tested)

I think I may find the best way forwards to be one in which I build an
non-Multilib LFS 8-3
and then use that to boostrap the Multilib one, as that would give me
a "host" with

Binutils-2.31.1
GCC-8.2.0
Glibc-2.28

Just out of interest then, what are the Binutils, GCC, Glibc versions on
the "non-multilib" host that your Multilib buils suceeds ?
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib patch

2019-01-05 Thread Thomas Trepl via lfs-dev 
Hi Kevin,

Am Samstag, den 05.01.2019, 18:56 +0800 schrieb Kevin Buckley via lfs-
dev:
> ...
> 
> Failed at the second hurdle.
> 
> The first GCC pass gets as far, in the `make`, as building the included zlib
> and, whilst configuring that, ends with

> Adding multilib support to Makefile in ../../zlib
> multidirs=32 x32
> with_multisubdir=
> Running configure in multilib subdirs 32 x32
> pwd: /home/lfs/gcc-8.2.0/build/zlib
> Running configure in multilib subdir 32
> pwd: /home/lfs/gcc-8.2.0/build
> mkdir 32
> configure: creating cache ./config.cache
> checking build system type... x86_64-pc-linux-gnu
> checking host system type... x86_64-pc-linux-gnu
> checking target system type... x86_64-lfs-linux-gnu
> checking for a BSD-compatible install... /usr/bin/install -c
> checking whether build environment is sane... yes
> checking for x86_64-pc-linux-gnu-strip... no
> checking for strip... strip
> checking for a thread-safe mkdir -p... /bin/mkdir -p
> checking for gawk... gawk
> checking whether make sets $(MAKE)... yes
> checking whether to enable maintainer-specific portions of Makefiles... no
> checking for x86_64-pc-linux-gnu-gcc... gcc  -m32
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... yes
> checking whether gcc  -m32 accepts -g... yes
> checking for gcc  -m32 option to accept ISO C89... unsupported
> checking for style of include used by make... GNU
> checking dependency style of gcc  -m32... gcc3
> checking how to print strings... printf
> checking for a sed that does not truncate output... /bin/sed
> checking for grep that handles long lines and -e... /bin/grep
> checking for egrep... /bin/grep -E
> checking for fgrep... /bin/grep -F
> checking for ld used by gcc  -m32... ld -m elf_x86_64
> checking if the linker (ld -m elf_x86_64) is GNU ld... yes
> checking for BSD- or MS-compatible name lister (nm)... nm
> checking the name lister (nm) interface... BSD nm
> checking whether ln -s works... yes
> checking the maximum length of command line arguments... 3458764513820540925
> checking whether the shell understands some XSI constructs... yes
> checking whether the shell understands "+="... yes
> checking for ld -m elf_x86_64 option to reload object files... -r
> checking for x86_64-pc-linux-gnu-objdump... objdump
> checking how to recognize dependent libraries... pass_all
> checking for x86_64-pc-linux-gnu-ar... ar
> checking for x86_64-pc-linux-gnu-strip... strip
> checking for x86_64-pc-linux-gnu-ranlib... ranlib
> checking command to parse nm output from gcc  -m32 object... failed
> checking how to run the C preprocessor... /lib/cpp
> checking for ANSI C header files... no
> checking for sys/types.h... no
> checking for sys/stat.h... no
> checking for stdlib.h... no
> checking for string.h... no
> checking for memory.h... no
> checking for strings.h... no
> checking for inttypes.h... no
> checking for stdint.h... no
> checking for unistd.h... no
> checking for dlfcn.h... no
> checking for objdir... .libs
> checking if gcc  -m32 supports -fno-rtti -fno-exceptions... no
> checking for gcc  -m32 option to produce PIC... -fPIC -DPIC
> checking if gcc  -m32 PIC flag -fPIC -DPIC works... yes
> checking if gcc  -m32 static flag -static works... no
> checking if gcc  -m32 supports -c -o file.o... yes
> checking if gcc  -m32 supports -c -o file.o... (cached) yes
> checking whether the gcc  -m32 linker (ld -m elf_x86_64 -m elf_i386)
> supports shared libraries... yes
> checking dynamic linker characteristics... configure: error: Link
> tests are not allowed after GCC_NO_EXECUTABLES.
> make[1]: *** [configure-zlib] Error 1
> make[1]: Leaving directory `/media/sda5/home-lfs/gcc-8.2.0/build'
> make: *** [all] Error 2
> 
> 
> Has my applying the Multilib patch not done all it should - it applied cleanly
> as I noted above.

If it applied cleanly, then it should have touched everything needed.

Strange enough - i cannot reproduce this issue, just did a build on a
non-multilib host and it goes fine (so far, now at gcc-pass2 in chap-
5).

Can you have a look into the config.log file - maybe there is
something more informative? 

--
Thomas



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

Re: [lfs-dev] Multilib patch

2019-01-05 Thread Kevin Buckley via lfs-dev 
On Thu, 3 Jan 2019 at 16:21, DJ Lucas via lfs-dev
 wrote:
>
> On January 2, 2019 6:55:52 AM CST, Kevin Buckley via lfs-dev wrote:
>
> > ...
> >Looks like I will have to go back to a full redeployment though, as I
> >see that
> >the Chapter 5 utilities now have some 32-bit stuff in, whereas my
> >modified 8.3
> >Chapter 5 didn't.
> >
>
> Yeah, doing the build inline is certainly better from a maintenance POV. It 
> adds a couple of extra builds, but the reduced maintenance burden (which 
> should ultimately result in an increase in accuracy being the instructions 
> are on the same page), far outweighs the minimal cumulative SBU increase. 
> Thomas's patch likely doesn't require much if any manual intervention.
>

Failed at the second hurdle.

The first GCC pass gets as far, in the `make`, as building the included zlib
and, whilst configuring that, ends with

Adding multilib support to Makefile in ../../zlib
multidirs=32 x32
with_multisubdir=
Running configure in multilib subdirs 32 x32
pwd: /home/lfs/gcc-8.2.0/build/zlib
Running configure in multilib subdir 32
pwd: /home/lfs/gcc-8.2.0/build
mkdir 32
configure: creating cache ./config.cache
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking target system type... x86_64-lfs-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for x86_64-pc-linux-gnu-strip... no
checking for strip... strip
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... no
checking for x86_64-pc-linux-gnu-gcc... gcc  -m32
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc  -m32 accepts -g... yes
checking for gcc  -m32 option to accept ISO C89... unsupported
checking for style of include used by make... GNU
checking dependency style of gcc  -m32... gcc3
checking how to print strings... printf
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by gcc  -m32... ld -m elf_x86_64
checking if the linker (ld -m elf_x86_64) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... nm
checking the name lister (nm) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 3458764513820540925
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for ld -m elf_x86_64 option to reload object files... -r
checking for x86_64-pc-linux-gnu-objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for x86_64-pc-linux-gnu-ar... ar
checking for x86_64-pc-linux-gnu-strip... strip
checking for x86_64-pc-linux-gnu-ranlib... ranlib
checking command to parse nm output from gcc  -m32 object... failed
checking how to run the C preprocessor... /lib/cpp
checking for ANSI C header files... no
checking for sys/types.h... no
checking for sys/stat.h... no
checking for stdlib.h... no
checking for string.h... no
checking for memory.h... no
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... no
checking for unistd.h... no
checking for dlfcn.h... no
checking for objdir... .libs
checking if gcc  -m32 supports -fno-rtti -fno-exceptions... no
checking for gcc  -m32 option to produce PIC... -fPIC -DPIC
checking if gcc  -m32 PIC flag -fPIC -DPIC works... yes
checking if gcc  -m32 static flag -static works... no
checking if gcc  -m32 supports -c -o file.o... yes
checking if gcc  -m32 supports -c -o file.o... (cached) yes
checking whether the gcc  -m32 linker (ld -m elf_x86_64 -m elf_i386)
supports shared libraries... yes
checking dynamic linker characteristics... configure: error: Link
tests are not allowed after GCC_NO_EXECUTABLES.
make[1]: *** [configure-zlib] Error 1
make[1]: Leaving directory `/media/sda5/home-lfs/gcc-8.2.0/build'
make: *** [all] Error 2


Has my applying the Multilib patch not done all it should - it applied cleanly
as I noted above.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib patch

2019-01-03 Thread DJ Lucas via lfs-dev 
On January 2, 2019 6:55:52 AM CST, Kevin Buckley via lfs-dev wrote:

>
>The one other thing I noticed is that there must be some automatic
>re-formatting of the XML going on (?) after changes are made, in that
>a couple of the patch chunks only failed to apply to the vanilla 8.3
>XML
>because the context lines didn't match after a line had been wrapped
>slightly
>differently.

Nothing automated in that. Likely my doing, but 81 ! <= 80. :-)

>
>In order to generate some dumps of the  sections
>for my own purposes (see previous postings) I ran the following against
>XML sources that had been patched with Thomas's patch and saw
>
>$ make  ARCH=multilib all-but-pdf
>Creating and cleaning ../../tmp
>Processing bootscripts...
>Adjusting for revision sysv...
>chapter03/patches.xml:130: parser error : Entity
>'systemd-glibc-patch-size' not defined
>systemd glibc patch -
>:   ^
>chapter03/patches.xml:132: parser error : Entity 'systemd-glibc-patch'
>not defined
>Download: url=""/>  ^
>chapter03/patches.xml:133: parser error : Entity
>'systemd-glibc-patch-md5' not defined
> MD5 sum: 
> ^
>Validating the book...
>Validation complete.
>Generating profiled XML for XHTML...
>Generating chunked XHTML files at
>...
>
>but the patched book was generated as expected, however I was wondering
>why the "systemd" patches were being referred to given the
>
>"Adjusting for revision sysv..."
>
>line.
>
>Is that just an atrefact of doing a "fuller" make that just a
>rendering of the HTML
>or something actually missing in the "development" XML sources ?
>

The wget scripts grab files for both books. I suppose doing the first pass 
might break things slightly. I'll have to take a peek at it.

>
>Looks like I will have to go back to a full redeployment though, as I
>see that
>the Chapter 5 utilities now have some 32-bit stuff in, whereas my
>modified 8.3
>Chapter 5 didn't.
>

Yeah, doing the build inline is certainly better from a maintenance POV. It 
adds a couple of extra builds, but the reduced maintenance burden (which should 
ultimately result in an increase in accuracy being the instructions are on the 
same page), far outweighs the minimal cumulative SBU increase. Thomas's patch 
likely doesn't require much if any manual intervention.

>I also note that Thomas's patch adds in ISL to the GCC Chapter 5 build:
>is
>that needed for the Chapter 6 32-bit builds (which also have ISL) or
>just a
>"nice to have" addition ?
>

Also my doing. It was just an artifact of an earlier build, but decided to 
leave it in there, that way, even though rarely used, all of the GCC deps are 
covered in the early phase. You should probably be able to omit if inclined, 
though not tested. The same is true for chapter 6. ISL is not required, nor are 
the complex loop optimizations that use it all that common in the wild. That 
said, it's a very small dep who's build time and disk space are negligible, and 
it might be used elsewhere if building software that is heavy in physics or 
geometry.

--DJ


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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

Re: [lfs-dev] Multilib patch

2019-01-02 Thread Bruce Dubbs via lfs-dev 

On 01/02/2019 03:28 PM, Ken Moffat via lfs-dev wrote:

On Wed, Jan 02, 2019 at 08:55:52PM +0800, Kevin Buckley via lfs-dev wrote:


With that in mind I wanted to say that I am often surprised by the number
of XML comments there are still in those "release tag" SVN sources.



Comments are written by editors for future editors.  When a book is
released, the only changes should be when Bruce notes that
something could be better worded, or if he notices something in the
rendered book that he thinks could be better.


The one other thing I noticed is that there must be some automatic
re-formatting of the XML going on (?) after changes are made, in that
a couple of the patch chunks only failed to apply to the vanilla 8.3 XML
because the context lines didn't match after a line had been wrapped slightly
differently.



I rarely touch LFS itself these days, but whenever I'm editing BLFS
I will often make changes in the XML simply because I noticed
something, either when editing, or when looking at the rendered
book.

Very little is automatic.


Well actually there are a lot of things that are not obvious but are 
automatic.  But as Ken says, changing xml is not.  That's all done by 
hand.  For the development version of BLFS changes are made virtually 
daily.  Since LFS is less than 10% of BLFS, the changes there are less 
frequent, but there are 3-4 still changes a month.


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

Re: [lfs-dev] Multilib patch

2019-01-02 Thread Ken Moffat via lfs-dev 
On Wed, Jan 02, 2019 at 08:55:52PM +0800, Kevin Buckley via lfs-dev wrote:
> 
> With that in mind I wanted to say that I am often surprised by the number
> of XML comments there are still in those "release tag" SVN sources.
> 

Comments are written by editors for future editors.  When a book is
released, the only changes should be when Bruce notes that
something could be better worded, or if he notices something in the
rendered book that he thinks could be better.

> The one other thing I noticed is that there must be some automatic
> re-formatting of the XML going on (?) after changes are made, in that
> a couple of the patch chunks only failed to apply to the vanilla 8.3 XML
> because the context lines didn't match after a line had been wrapped slightly
> differently.
> 

I rarely touch LFS itself these days, but whenever I'm editing BLFS
I will often make changes in the XML simply because I noticed
something, either when editing, or when looking at the rendered
book.

Very little is automatic.

ĸen
-- 
The Laird o’Phelps spent Hogmanay declaring he was sober,
Counted his feet to prove the fact and found he had one foot over.
  -- Louis MacNeice, Bagpipe Music
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib patch

2019-01-02 Thread Kevin Buckley via lfs-dev 
On Tue, 14 Aug 2018 at 18:54, Thomas Trepl  wrote:
>
> Hi,
>
> for those who are interested in doing {,B}LFS with multilib support,
> here is a patch on the LFS book adding some instructions to build the
> LFS core system with multilib support.
>
> Apply the patch to the LFS sources and run "make ARCH=multilib". If
> leaving out the ARCH= parameter or set it to ARCH=default will produce
> the book without any ML stuff in it.
>
> Running thru the book created with ARCH=multilib will provide you a
> system with m64, mx32 and m32 ABI.
>
> The patch is based on the latest development LFS book (20180808), not
> yet tested on the 8.3-rc1.

Just to chip in another thr'pen'th, I thought I'd point out that, after DJ
had pointed me to Thomas's patch (I need the 32-bit for an attempt to
install Xen) I found that it nearly applied cleanly to the "vanilla" 8.3 SVN
sources as well and that all I needed to do to see it apply cleanly was to
remove some comments in the XML which I assume got removed once
things moved into the development series?

With that in mind I wanted to say that I am often surprised by the number
of XML comments there are still in those "release tag" SVN sources.

The one other thing I noticed is that there must be some automatic
re-formatting of the XML going on (?) after changes are made, in that
a couple of the patch chunks only failed to apply to the vanilla 8.3 XML
because the context lines didn't match after a line had been wrapped slightly
differently.

In order to generate some dumps of the  sections
for my own purposes (see previous postings) I ran the following against
XML sources that had been patched with Thomas's patch and saw

$ make  ARCH=multilib all-but-pdf
Creating and cleaning ../../tmp
Processing bootscripts...
Adjusting for revision sysv...
chapter03/patches.xml:130: parser error : Entity
'systemd-glibc-patch-size' not defined
  systemd glibc patch - :Download: MD5 sum: 
 ^
Validating the book...
Validation complete.
Generating profiled XML for XHTML...
Generating chunked XHTML files at
...

but the patched book was generated as expected, however I was wondering
why the "systemd" patches were being referred to given the

"Adjusting for revision sysv..."

line.

Is that just an atrefact of doing a "fuller" make that just a
rendering of the HTML
or something actually missing in the "development" XML sources ?


Looks like I will have to go back to a full redeployment though, as I see that
the Chapter 5 utilities now have some 32-bit stuff in, whereas my modified 8.3
Chapter 5 didn't.

I also note that Thomas's patch adds in ISL to the GCC Chapter 5 build: is
that needed for the Chapter 6 32-bit builds (which also have ISL) or just a
"nice to have" addition ?

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

Re: [lfs-dev] Multilib patch

2019-01-01 Thread DJ Lucas via lfs-dev 



On 01/01/2019 10:50 AM, spiky0011 via lfs-dev wrote:


DJ Lucas.

I have tried building your multilib sysV version I get a error in 
building libcap-2.25 x32bit.


So far no problems upto here, I have restarted from ch6 a 2nd time 
incase I made a mistake.


Error

libcap-2.25# make CC="gcc -mx32"
make -C libcap all
make[1]: Entering directory '/sources/libcap-2.25/libcap'
=> making cap_names.list.h from 
/sources/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h
perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[ 
\t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print 
"{\"$tok\",$val},\n"; } }' 
/sources/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h | 
fgrep -v 0x > cap_names.list.h
gcc -mx32 -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC 
-I/sources/libcap-2.25/libcap/../libcap/include/uapi 
-I/sources/libcap-2.25/libcap/../libcap/include _makenames.c -o _makenames

./_makenames > cap_names.h
/bin/sh: ./_makenames: cannot execute binary file: Exec format error
make[1]: *** [Makefile:41: cap_names.h] Error 126
make[1]: Leaving directory '/sources/libcap-2.25/libcap'
make: *** [Makefile:12: all] Error 2


I have no idea how to check what is wrong. If this error could stem back 
to ch5 then ok.


Both of the other parts built fine from libcap



Maybe double check the kernel config for x32 support (CONFIG_X86_X32). 
That said, and unrelated, you should be building from Thomas's patch at 
https://io.ax.lt/ as it is kept up to date (automated). Only need my 
patch for jhalfs (if you are using jhalfs).


--DJ

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

Re: [lfs-dev] Multilib patch

2019-01-01 Thread spiky0011 via lfs-dev 


On 30/09/2018 02:57, DJ Lucas wrote:



On 08/14/2018 05:54 AM, Thomas Trepl wrote:

Hi,

for those who are interested in doing {,B}LFS with multilib support,
here is a patch on the LFS book adding some instructions to build the
LFS core system with multilib support.





Updates to this based on Thomas's work at https://io.ax.lt/. This is 
still very much experimental but coming together nicely. I've been 
working on jhalfs support. I also have a current patch for trunk (also 
for Thomas's branch to allow building with jhalfs) and rendered copies 
for both sysv and systemd in my homedir if anybody would like to take 
a look:


http://www.linuxfromscratch.org/~dj/Multilib/

Thomas, when you are available, please note the changes WRT separating 
the lib32 and libx32 with separate s. This is required for 
jhalfs to parse the files correctly. As to the other changes, in 
additon to -m32/-mx32, I've tried to ensure that we use appropriate 
-march flags where --host is invalid. None of this is tested 
thoroughly as of yet, but my ultimate real world goal, in addition to 
being able to run x86 binaries needed for various tasks, is to be able 
to build x86 java without a full x86 LFS build handy. As of now, 
jhalfs builds to completion on Systemd. I don't believe that I've made 
any changes that would affect SysV, but I haven't tested sysv-multilib 
just yet.


HTH

--DJ


DJ Lucas.

I have tried building your multilib sysV version I get a error in 
building libcap-2.25 x32bit.


So far no problems upto here, I have restarted from ch6 a 2nd time 
incase I made a mistake.


Error

libcap-2.25# make CC="gcc -mx32"
make -C libcap all
make[1]: Entering directory '/sources/libcap-2.25/libcap'
=> making cap_names.list.h from 
/sources/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h
perl -e 'while ($l=<>) { if ($l =~ /^\#define[ \t](CAP[_A-Z]+)[ 
\t]+([0-9]+)\s+$/) { $tok=$1; $val=$2; $tok =~ tr/A-Z/a-z/; print 
"{\"$tok\",$val},\n"; } }' 
/sources/libcap-2.25/libcap/../libcap/include/uapi/linux/capability.h | 
fgrep -v 0x > cap_names.list.h
gcc -mx32 -O2 -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -fPIC 
-I/sources/libcap-2.25/libcap/../libcap/include/uapi 
-I/sources/libcap-2.25/libcap/../libcap/include _makenames.c -o _makenames

./_makenames > cap_names.h
/bin/sh: ./_makenames: cannot execute binary file: Exec format error
make[1]: *** [Makefile:41: cap_names.h] Error 126
make[1]: Leaving directory '/sources/libcap-2.25/libcap'
make: *** [Makefile:12: all] Error 2


I have no idea how to check what is wrong. If this error could stem back 
to ch5 then ok.


Both of the other parts built fine from libcap

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

Re: [lfs-dev] Multilib patch

2018-09-29 Thread DJ Lucas 



On 08/14/2018 05:54 AM, Thomas Trepl wrote:

Hi,

for those who are interested in doing {,B}LFS with multilib support,
here is a patch on the LFS book adding some instructions to build the
LFS core system with multilib support.





Updates to this based on Thomas's work at https://io.ax.lt/. This is 
still very much experimental but coming together nicely. I've been 
working on jhalfs support. I also have a current patch for trunk (also 
for Thomas's branch to allow building with jhalfs) and rendered copies 
for both sysv and systemd in my homedir if anybody would like to take a 
look:


http://www.linuxfromscratch.org/~dj/Multilib/

Thomas, when you are available, please note the changes WRT separating 
the lib32 and libx32 with separate s. This is required for jhalfs 
to parse the files correctly. As to the other changes, in additon to 
-m32/-mx32, I've tried to ensure that we use appropriate -march flags 
where --host is invalid. None of this is tested thoroughly as of yet, 
but my ultimate real world goal, in addition to being able to run x86 
binaries needed for various tasks, is to be able to build x86 java 
without a full x86 LFS build handy. As of now, jhalfs builds to 
completion on Systemd. I don't believe that I've made any changes that 
would affect SysV, but I haven't tested sysv-multilib just yet.


HTH

--DJ

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

Re: [lfs-dev] Multilib patch

2018-08-24 Thread DJ Lucas 

On 08/25/2018 12:13 AM, DJ Lucas wrote:

One more thing, need to add lib32 paths to remove-la-files.sh. I, thus 
far, have not messed with lib32x. I used a separate path for  files in 
/usr/lib32. Same for /usr/lib32/pkgconfig and /usr/local/lib32/pkgconfig.




On second thought, there is no purpose for the pc files in 
/usr/lib32/pkgconfig, should just remove the directory if it exists. 
Regardless of the libdir value in the pc file, the libraries themselves 
will always be in the library search path because of our change to 
/etc/ld.so.conf.


--DJ

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

Re: [lfs-dev] Multilib patch

2018-08-24 Thread DJ Lucas 



On 08/14/2018 05:54 AM, Thomas Trepl wrote:

Hi,

for those who are interested in doing {,B}LFS with multilib support,
here is a patch on the LFS book adding some instructions to build the
LFS core system with multilib support.

Apply the patch to the LFS sources and run "make ARCH=multilib". If
leaving out the ARCH= parameter or set it to ARCH=default will produce
the book without any ML stuff in it.

Running thru the book created with ARCH=multilib will provide you a
system with m64, mx32 and m32 ABI.

The patch is based on the latest development LFS book (20180808), not
yet tested on the 8.3-rc1.

I had to split up building glibc in chapter 6 into two sections, the
"usual" build of 64-bit glibc and than the 32-bit glibc with having the
adjustment section in between. Otherwise i ran into the "glibc builds
endlessly"-issue.
Root directory gets a bit polluted by two additional dirs(symlinks)
named /lib32 and /libx32. I think there could be a way to avoid this
when diving deeper into the gcc-specs-stuff and such.

The patch also adds ISL as a new package. I'm not sure whether there is
a real dependency on that, I just included it as DJ did that in his ML-
book, too.

Whats missing:
* The kernel chapter should be enhanced with instructions to enable the
required emulation support.
* My building system has multilib support allready builtin. Need to
redo testing from a single-64bit-ABI-system to ensure that there are no
silent cross-references.

And finally:
I'm pretty sure that there are some bugs/flaws/whatever in the patch
(and the instructions it provides), consider the patch as an alpha
version. Please be invited to report bugs, provide tweaks, comments and
enhancements!
Yes, ML goes a bit beyond the basic educational approach of LFS but
there is still software out there (in my case a printer driver from
DELL) which is only provided as 32bit-binary and this renders a pure-
64bit LFS useless to some extend.

And big thanks to DJ, Nathan and William F. for their recent work on
multilib support!



So I finally got around to this as I had to do 32bit xorg libs to create 
the i686 Java install. I realized, I had forgot to do expat 32bit libs 
for fontconfig. Additionally, while I haven't confirmed, you probably 
want sysvinit and sysklogd 32bit libs in the sysv book. Overall, 
however, it looks really good! Excellent work!


--DJ

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

Re: [lfs-dev] Multilib patch

2018-08-14 Thread Anthony Jagers 
>
> 
> >Why did you use CLFS? I thought
> the patch was intended for LFS.


I didn't find out about your patch until after I completed it. I've grown
accustom
to the following the book anyway.
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

Re: [lfs-dev] Multilib patch

2018-08-14 Thread Alain Toussaint 
Le mardi 14 août 2018 à 13:29 -0400, Anthony Jagers a écrit :
> I just ran through the CLFS book with updated tarballs from SVN.
> I posted my notes here:
> 
> https://www.linuxquestions.org/questions/linux-from-scratch-13/clfs-s
> till-works-4175636269/

Why did you use CLFS? I thought the patch was intended for LFS.

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

Re: [lfs-dev] Multilib patch

2018-08-14 Thread Anthony Jagers 
I just ran through the CLFS book with updated tarballs from SVN.
I posted my notes here:

https://www.linuxquestions.org/questions/linux-from-scratch-13/clfs-still-works-4175636269/
-- 
http://lists.linuxfromscratch.org/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page

[lfs-dev] Multilib patch

2018-08-14 Thread Thomas Trepl 
Hi,

for those who are interested in doing {,B}LFS with multilib support,
here is a patch on the LFS book adding some instructions to build the
LFS core system with multilib support.

Apply the patch to the LFS sources and run "make ARCH=multilib". If
leaving out the ARCH= parameter or set it to ARCH=default will produce
the book without any ML stuff in it.

Running thru the book created with ARCH=multilib will provide you a
system with m64, mx32 and m32 ABI.

The patch is based on the latest development LFS book (20180808), not
yet tested on the 8.3-rc1.

I had to split up building glibc in chapter 6 into two sections, the
"usual" build of 64-bit glibc and than the 32-bit glibc with having the
adjustment section in between. Otherwise i ran into the "glibc builds
endlessly"-issue.
Root directory gets a bit polluted by two additional dirs(symlinks)
named /lib32 and /libx32. I think there could be a way to avoid this
when diving deeper into the gcc-specs-stuff and such.

The patch also adds ISL as a new package. I'm not sure whether there is
a real dependency on that, I just included it as DJ did that in his ML-
book, too.

Whats missing:
* The kernel chapter should be enhanced with instructions to enable the
required emulation support.
* My building system has multilib support allready builtin. Need to
redo testing from a single-64bit-ABI-system to ensure that there are no
silent cross-references. 

And finally:
I'm pretty sure that there are some bugs/flaws/whatever in the patch
(and the instructions it provides), consider the patch as an alpha
version. Please be invited to report bugs, provide tweaks, comments and
enhancements!
Yes, ML goes a bit beyond the basic educational approach of LFS but
there is still software out there (in my case a printer driver from
DELL) which is only provided as 32bit-binary and this renders a pure-
64bit LFS useless to some extend.

And big thanks to DJ, Nathan and William F. for their recent work on
multilib support!

--
Thomas
diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter01/askforhelp.xml BOOK-multilib/chapter01/askforhelp.xml
--- BOOK-orig/chapter01/askforhelp.xml	2018-08-10 07:50:45.0 +0200
+++ BOOK-multilib/chapter01/askforhelp.xml	2018-08-12 21:15:20.298266973 +0200
@@ -39,7 +39,8 @@
 
   
 The version of the book being used (in this case 
-  
+  
+  -multilib
   )
   
   
diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter01/changelog.xml BOOK-multilib/chapter01/changelog.xml
--- BOOK-orig/chapter01/changelog.xml	2018-08-10 07:50:45.0 +0200
+++ BOOK-multilib/chapter01/changelog.xml	2018-08-12 21:13:51.669498909 +0200
@@ -11,7 +11,8 @@
   Changelog
 
   This is version 
-
+
+-multilib
 
   of the Linux From Scratch book, dated
   . If this book is more than six months old, a newer and better
diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter03/packages.xml BOOK-multilib/chapter03/packages.xml
--- BOOK-orig/chapter03/packages.xml	2018-08-10 07:50:45.0 +0200
+++ BOOK-multilib/chapter03/packages.xml	2018-08-10 09:43:39.531077226 +0200
@@ -356,6 +356,15 @@
 
 
 
+  ISL () - :
+  
+Home page: 
+Download: 
+MD5 sum: 
+  
+
+
+
   Kbd () - :
   
 Home page: 
diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter04/settingenviron.xml BOOK-multilib/chapter04/settingenviron.xml
--- BOOK-orig/chapter04/settingenviron.xml	2018-08-10 07:50:46.0 +0200
+++ BOOK-multilib/chapter04/settingenviron.xml	2018-08-12 13:38:55.044890706 +0200
@@ -37,7 +37,7 @@
   .bashrc file instead. Create the
   .bashrc file now:
 
-cat  ~/.bashrc  "EOF"
+cat  ~/.bashrc  "EOF"
 set +h
 umask 022
 LFS=/mnt/lfs
@@ -46,6 +46,17 @@
 PATH=/tools/bin:/bin:/usr/bin
 export LFS LC_ALL LFS_TGT PATH
 EOF
+cat  ~/.bashrc  "EOF"
+set +h
+umask 022
+LFS=/mnt/lfs
+LC_ALL=POSIX
+LFS_TGT=x86_64-lfs-linux-gnu
+LFS_TGT32=i686-lfs-linux-gnu
+LFS_TGTX32=x86_64-lfs-linux-gnux32
+PATH=/tools/bin:/bin:/usr/bin
+export LFS LC_ALL LFS_TGT LFS_TGT32 LFS_TGTX32 PATH
+EOF
 
   The set +h command turns off
   bash's hash function. Hashing is ordinarily a useful
diff -Naur -x .svn -x 'lfs-bootscripts-*.tar.bz2' -x appendices BOOK-orig/chapter05/binutils-pass1.xml BOOK-multilib/chapter05/binutils-pass1.xml
--- BOOK-orig/chapter05/binutils-pass1.xml	2018-08-10 07:50:46.0 +0200
+++ BOOK-multilib/chapter05/binutils-pass1.xml	2018-08-12 17:07:56.147972097 +0200
@@ -72,12 +72,20 @@
 
 Now prepare Binutils for compilation:
 
-../configure --prefix=/tools\
+../configure --prefix=/tools \
  --with-sysroot=$LFS\
  --with-lib-path=/tools/lib \
  --target=$LFS_TGT  \
  --disable-nls  \
  --disable-werror
+