Re: Cross LFS and UTF-8
Jim Gifford wrote: Recently LFS has added support for UTF-8. We at CLFS are also looking to include support for UTF-8, but not the same way that LFS has it done. If you noticed a few package changes were added to incorporate these changes, Berkeley DB and Man-DB. The developers of CLFS don't feel all of these package changes are necessary and are looking for alternative ways to implement UTF-8. So any feedback the CLFS community has on this topic will be welcomed. There is one more option: revert the UTF-8 changes in LFS trunk and (although that's a lot of work) the LiveCD. 1) huge patches (with bad bug history, but UTF-8 support is required by LSB) 2) ncursesw (wastes memory in non-UTF-8 case, requires watching upstream for fixes in UTF-8 case) 3) man-db (db is a space-time hog, alternative solutions are welcome) 4) bootscripts I came to the conclusion that they are a useless toy right now. Some history is below. When I started raising BLFS UTF-8 related issues, the agreement was that I should not do that until UTF-8 is officially in LFS. But that didn't help because BLFS is understaffed: nano is still not upgraded to 1.3.9, the note on MP3 players is still not in the book, and it is still impossible to create a Windows-readable CD with non-ASCII filenames in UTF-8 locale. With such low speed (determined by purely objective factors, so please don't take my statement as an attack), it is quite likely that when the LFS release actually happens, BLFS will be nowhere near ready. That is actually worse that having no UTF-8 support and clearly stating that. OTOH, if anybody wants this and will help, I will be happy to fork both books simultaneously and drop non-verified packages from my copy of BLFS. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS and UTF-8
Alexander E. Patrakov wrote: OTOH, if anybody wants this and will help, I will be happy to fork both books simultaneously and drop non-verified packages from my copy of BLFS. I think the best approach for is to continue with the UTF-8 effort and let us get the wiki up and running to handle the differences for BLFS. This can be an ongoing process where anyone can add notes and they can be incorporated into the book as time allows. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Suggestion for Cross-LFS doc.
Would it make sense to you guys to change section 5.4. Build Variables a bit. I would suggest: 1) Swap Configuration #1 and #2 around because the table belongs at #1. 2) Change the text a tiny bit from Creating different architecture tools to If the build target is on a different architecture, etc. 3) Add something about the implication of this because it determines if you are going to boot or chroot. I think that you can only chroot if the target system's /bin/bash and /bin/env can be executed by the host system. Otherwise a you need to follow the steps in 7. If You Are Going to Boot From what I have figured out is that chroot is easier because the host system it still available and therefore X-windows, Firefox, etc are there to carry on reading the book. Hope that this make sense. Regards, Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
On Thu, 27 Oct 2005, Thomas Pegg wrote: On Thu, 2005-10-27 at 21:35 +0100, Ken Moffat wrote: OK, using Ryan's patch from last week plus the installstyle echo, with only a 64-bit perl, everything is in /usr/lib64/perl5 and XML-Parser installs into /usr/lib64/perl5/site_perl. Looks good, apart from the libc=/lib/ issue in 'perl -V'. I think I may have a found a solution for that, I used a patch (attached below) that's a variation on the current libc patch, the main differences being that I dropped the last hunk of the patch it's only needed for the tools version of perl. It does set libc properly (partial output of perl -V below. I also used the -Dlibpth Jim posted earlier so perl doesn't set it to just /usr/local/lib. Thanks. I was going to say it didn't work for me (tried something similar last night, but ./perl -V still showed /lib), but your output persuaded me to retry : 'make install' does something to perl - before make install, ./perl -V shows libc=/lib, after make install both ./perl -V and perl -V now show libc=/lib64. Finding that out is less painful than trying to work out what libpth is used for in Configure, so I'm very grateful. A little more testing to do (rewind to before perl, make a clean install, test a little), then I'll put my editing hat on. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
On Thu, 27 Oct 2005, Alexander E. Patrakov wrote: Jim Gifford wrote: Translated for Cross-LFS would be. -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 \ -Dprivlib=/usr/lib/perl5/5.8.7 \ -Dsitelib=/usr/lib/perl5/site_perl/5.8.7 \ -Dvendorlib=/usr/lib/perl5/vendor_perl/5.8.7 \ -Darchlib=/usr/lib/perl5/5.8.7/x86_64-linux What bothers me is that there's no vendor_perl directory in the stock LFS installation. I agree with the rest for multilib. Apart from that, this has two deficiencies in my view: (i) our 64-bit perl installs in /usr/lib instead of /usr/lib64, as do all subsequent modules (tested with XML-Parser, which finds libexpat from /usr/lib64, but installs its own (64-bit) Expat.so under /usr/lib/perl5. (ii) the defines for privlib, sitelib, vendorlib, archlib do not affect what, or where, perl itself installs and therefore I regard them as unnecessary additions. I agree that a 64-bit perl seems to be adequate on multilib (I'm sure somebody will find an exotic 32-bit chroot example that needs a 32-bit perl, but for normal use I'm happy unless anybody responds to my earlier post on -chat). Will reply, hopefully in a couple of hours, with a comparison of what gets installed using Ryan's Configure patch with a 64-bit-only perl. Note that perl -V continues to show libc as /lib/libc-2.3.90.so in all of these variations, which looks messy but perhaps won't cause too many problems down the line [ I'd still prefer to fix that, but my current spells are too weak ]. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
(Adding Jim back to the CC) On Thu, 27 Oct 2005, Ken Moffat wrote: Apart from that, this has two deficiencies in my view: (i) our 64-bit perl installs in /usr/lib instead of /usr/lib64, as do all subsequent modules (tested with XML-Parser, which finds libexpat from /usr/lib64, but installs its own (64-bit) Expat.so under /usr/lib/perl5. (ii) the defines for privlib, sitelib, vendorlib, archlib do not affect what, or where, perl itself installs and therefore I regard them as unnecessary additions. I agree that a 64-bit perl seems to be adequate on multilib (I'm sure somebody will find an exotic 32-bit chroot example that needs a 32-bit perl, but for normal use I'm happy unless anybody responds to my earlier post on -chat). OK, using Ryan's patch from last week plus the installstyle echo, with only a 64-bit perl, everything is in /usr/lib64/perl5 and XML-Parser installs into /usr/lib64/perl5/site_perl. Looks good, apart from the libc=/lib/ issue in 'perl -V'. In all cases, the perl and XML-Parser testsuites completed ok. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051024-x86_64 missing section
Duncan Webb wrote: I think that there is a missing section in 11.9. The Bash Shell Startup Files, there doesn't seem to be anywhere that the PATH is set. That is correct In chapter 7. If You Are Going to Boot section 7.14. Setting Up the Environment the PATH is written but never gets overridden. Explain what you mean. When you boot into the cross-lfs, this will setup you PATH to what is needed to complete to book. At least I can't find where it gets reset *and* I think that this applies also the LFS 6.1 Does not apply to LFS 6.1 BTW There is a slight conflict with groups, sshd uses group 50 but 50 has been assigned to operator in chapter 8.8. Creating the passwd, group, and log Files. BLFS is not supportomg cross-lfs, we have followed our own path on this for the time being. Regards, Duncan -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051024-x86_64 missing section
Jim Gifford wrote: Duncan Webb wrote: I think that there is a missing section in 11.9. The Bash Shell Startup Files, there doesn't seem to be anywhere that the PATH is set. That is correct In chapter 7. If You Are Going to Boot section 7.14. Setting Up the Environment the PATH is written but never gets overridden. Explain what you mean. When you boot into the cross-lfs, this will setup you PATH to what is needed to complete to book. That's correct the path is set to complete all the packages in the book; then a reboot to bring up the new LFS system but the path still has the /tools/bin:/tools/sbin in it. Of course, BLFS will later correct this but I would have thought that LFS would have a correct path when it has been completed. Which route is take chroot or boot the resulting files should be the same. Duncan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Perl - Cross-LFS Multilib
Matt, Ken, Joe, and Fellow LFS-Dev's
I have been researching this issue, I've been using fedora as a basis,
they only build one version of perl. Here's what I've been looking at.
http://cvs.fedora.redhat.com/viewcvs/devel/perl/
They use this patch
http://cvs.fedora.redhat.com/viewcvs/devel/perl/perl-5.8.0-libdir64.patch?rev=1.1view=log
Add these lines to the Configure line
-Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 \
-Dprivlib=/usr/lib/perl5/%{version} \
-Dsitelib=/usr/lib/perl5/site_perl/%{version} \
-Dvendorlib=/usr/lib/perl5/vendor_perl/%{version} \
-Darchlib=%{_libdir}/perl5/%{perlver}/%{_arch}-%{_os}%{thread_arch} \
-Dsitearch=%{_libdir}/perl5/site_perl/%{perlver}/%{_arch}-%{_os}%{thread_arch}
\
-Dvendorarch=%{_libdir}/perl5/vendor_perl/%{perlver}/%{_arch}-%{_os}%{thread_arch}
\
Translated for Cross-LFS would be.
-Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 \
-Dprivlib=/usr/lib/perl5/5.8.7 \
-Dsitelib=/usr/lib/perl5/site_perl/5.8.7 \
-Dvendorlib=/usr/lib/perl5/vendor_perl/5.8.7 \
-Darchlib=/usr/lib/perl5/5.8.7/x86_64-linux \
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Perl - Cross-LFS Multilib
Jim Gifford wrote: Translated for Cross-LFS would be. -Dlibpth=/usr/local/lib64 /lib64 /usr/lib64 \ -Dprivlib=/usr/lib/perl5/5.8.7 \ -Dsitelib=/usr/lib/perl5/site_perl/5.8.7 \ -Dvendorlib=/usr/lib/perl5/vendor_perl/5.8.7 \ -Darchlib=/usr/lib/perl5/5.8.7/x86_64-linux What bothers me is that there's no vendor_perl directory in the stock LFS installation. I agree with the rest for multilib. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
On Tue, 25 Oct 2005, Duncan Webb wrote:
Ken Moffat wrote:
On Mon, 24 Oct 2005, Duncan Webb wrote:
9.4. Expect-5.43.0
I think the configure line should be:
CC=gcc ${BUILD64} ./configure --prefix=/tools --with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
No, in the previous section where you build tcl you should have used a sed
on Makefile.in to force lib64, and also passed --libdir=/tools/lib64.
But please read the rest of my reply!
There is no sed nor --libdir=/tools/lib64 in the pure64 book in chapter 9.
Constructing a Temporary Tools in the pure book.
OK, in that case, I was misled by the x86_64 subject. Apologies. Ah,
I see, you are objecting to the missing ${BUILD64}. My take on this is
that we've built a 64-bit-only compiler in pure64 (/tools/bin/gcc).
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
Ken Moffat wrote:
On Tue, 25 Oct 2005, Duncan Webb wrote:
Ken Moffat wrote:
On Mon, 24 Oct 2005, Duncan Webb wrote:
9.4. Expect-5.43.0
I think the configure line should be:
CC=gcc ${BUILD64} ./configure --prefix=/tools
--with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
No, in the previous section where you build tcl you should have
used a sed on Makefile.in to force lib64, and also passed
--libdir=/tools/lib64.
But please read the rest of my reply!
There is no sed nor --libdir=/tools/lib64 in the pure64 book in
chapter 9. Constructing a Temporary Tools in the pure book.
OK, in that case, I was misled by the x86_64 subject. Apologies.
Ah, I see, you are objecting to the missing ${BUILD64}. My take on
this is that we've built a 64-bit-only compiler in pure64
(/tools/bin/gcc).
Well all I can say is that without it the build fails. Most of the
packages in Chapter 9 also required it.
Duncan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Attemping multilib Cross LFS from Mac OS X
Hey Guys,
Throwing this out there in case anyone has any ideas. I'm following the
current Cross LFS instructions (generally) to attempt to build multilib
on a PowerPC G5 running Mac OS X. (I added a patch for ppc multilib just
now to the patches repo for that.) I can get up to the glibc-headers
section before hitting an error.
First of all, I altered slightly the glibc headers instructions to use
with ppc multilib. After 'cd ../glibc-build', you need to add:
echo libc_cv_ppc_machine=yes config.cache
And then add '--cache-file=config.cache to the configure line.
Configure runs successfully, but then during make I get the following:
===
make[1]: Entering directory `/mnt/lfs/sources/glibc-20050926'
{ echo '#include posix/bits/posix1_lim.h';\
echo '#define _LIBC 1'; \
echo '#include misc/sys/uio.h'; } | \
gcc -E -dM -MD -MP -MF /mnt/lfs/sources/glibc-build/bits/stdio_lim.dT
-MT '/mnt/lfs/sources/glibc-build/bits/stdio_lim.h
/mnt/lfs/sources/glibc-build/bits/st
-Iinclude -I. -I/mnt/lfs/sources/glibc-build -Ilibio
-I/mnt/lfs/sources/glibc-build -Isysdeps/powerpc/powerpc64/elf
-Isysdeps/powerpc/elf -Isysdeps/u
In file included from posix/sys/types.h:31,
from include/sys/types.h:1,
from misc/sys/uio.h:24,
from stdin:3:
sysdeps/generic/bits/types.h:31:20: No include path in which to find
stddef.h
In file included from include/sys/types.h:1,
from misc/sys/uio.h:24,
from stdin:3:
posix/sys/types.h:147:20: No include path in which to find stddef.h
make[1]: *** [/mnt/lfs/sources/glibc-build/bits/stdio_lim.st] Error 1
make[1]: Leaving directory `/mnt/lfs/sources/glibc-20050926'
make: *** [install-headers] Error 2
=
It *seems* like the --with-headers flag isn't working the way it should.
Anyone have any ideas?
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Attemping multilib Cross LFS from Mac OS X
Jeremy Huntwork wrote:
Jeremy Huntwork wrote:
Configure runs successfully, but then during make I get the following:
Sorry, it looks like some of the output was cut off, here's the full
error:
make[1]: Entering directory `/mnt/lfs/sources/glibc-20050926'
{ echo '#include posix/bits/posix1_lim.h';\
echo '#define _LIBC 1'; \
echo '#include misc/sys/uio.h'; } | \
gcc -E -dM -MD -MP -MF /mnt/lfs/sources/glibc-build/bits/stdio_lim.dT
-MT '/mnt/lfs/sources/glibc-build/bits/stdio_lim.h
/mnt/lfs/sources/glibc-build/bits/stdio_lim.d' \
-Iinclude -I. -I/mnt/lfs/sources/glibc-build -Ilibio
-I/mnt/lfs/sources/glibc-build -Isysdeps/powerpc/powerpc64/elf
-Isysdeps/powerpc/elf -Isysdeps/unix/sysv/linux/powerpc/powerpc64
-Isysdeps/unix/sysv/linux/wordsize-64
-Isysdeps/unix/sysv/linux/powerpc -Isysdeps/unix/sysv/linux
-Isysdeps/gnu -Isysdeps/unix/common -Isysdeps/unix/mman
-Isysdeps/unix/inet -Isysdeps/unix/sysv -Isysdeps/unix/powerpc
-Isysdeps/unix -Isysdeps/posix -Isysdeps/powerpc/powerpc64/fpu
-Isysdeps/powerpc/powerpc64 -Isysdeps/wordsize-64
-Isysdeps/powerpc/fpu -Isysdeps/powerpc -Isysdeps/ieee754/flt-32
-Isysdeps/ieee754/dbl-64 -Isysdeps/ieee754 -Isysdeps/generic/elf
-Isysdeps/generic -nostdinc -isystem include -isystem /tools/include
-xc - -o /mnt/lfs/sources/glibc-build/bits/stdio_lim.hT
In file included from posix/sys/types.h:31,
from include/sys/types.h:1,
from misc/sys/uio.h:24,
from stdin:3:
sysdeps/generic/bits/types.h:31:20: No include path in which to find
stddef.h
In file included from include/sys/types.h:1,
from misc/sys/uio.h:24,
from stdin:3:
posix/sys/types.h:147:20: No include path in which to find stddef.h
make[1]: *** [/mnt/lfs/sources/glibc-build/bits/stdio_lim.st] Error 1
make[1]: Leaving directory `/mnt/lfs/sources/glibc-20050926'
make: *** [install-headers] Error 2
--
JH
Jeremy, trying doing a glibc-headers build first, this should install
any missing headers. Follow the one on the x86_64 page. Also don't
forget to create the stub files for linux-libc-headers.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Attemping multilib Cross LFS from Mac OS X
Jim Gifford wrote: Jeremy, trying doing a glibc-headers build first, this should install any missing headers. Follow the one on the x86_64 page. Also don't forget to create the stub files for linux-libc-headers. Sorry, I should have been more clear. This *is* the glibc-headers build. This error happens when I run 'make install-headers'. And if you notice from my commit to the patches repo and my note in the initial message, I have created the linux-libc-headers stub files. G5:/mnt/lfs/sources/glibc-build lfs$ ls -l /tools/include/ total 32 drwxr-xr-x 113 lfs admin 3842 24 Oct 14:27 asm drwxr-xr-x 90 lfs admin 3060 24 Oct 14:27 asm-ppc drwxr-xr-x 88 lfs admin 2992 24 Oct 14:27 asm-ppc64 -rw-r--r--1 lfs admin 12949 24 Oct 14:34 libiberty.h drwxr-xr-x 524 lfs admin 17816 24 Oct 14:28 linux -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Attemping multilib Cross LFS from Mac OS X
Jeremy Huntwork wrote: Jeremy Huntwork wrote: That seems to have done it :) I didn't feel brave enough to start messing with symlinks in my include dir. Thanks. I'll continue from here and let you know of my progress. Btw, Jim, if you want to set up in the book for a multilib powerpc section, I can start adding in some tweaks here and there. -- JH Go for it bud!! -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
On Mon, 24 Oct 2005, Duncan Webb wrote:
Hi all,
Just build the boot stages of Version 7.0-cross-lfs-20051023-x86_64 from a
LFS 6.1 (32-bit) system. I've noticed a few small errors that I would like to
report.
5.4. Build Variables
Following the commands will set LFS_TARGET to i686-pc-linux-gnu, which works
until building glibc. Changing LFS_TARGET to x86_64-pc-linux-gnu allowed me
to complete the build.
The book (5.3) says:
| Now you will need to set the target triplet for the target
| architecure. You can do this by running the same command as above,
| just running it on the target machine. If you can't run the command on
| the target machine, you can use the table at the bottom of this page.
What's the problem ?
7.10. Creating the passwd, group, and log Files
The cat commands are missing ${LFS} so it tries to write to the root.
7.16. LFS-Bootscripts-3.2.2
Should include a block to set-up ${LFS}/etc/sysconfig/clock because the boot
reports an error when running the clock script.
Thanks, I've addressed these in r7078 although no doubt my wording
about the clock script can be improved.
One minor points
A few of the instructions in chapter 6 say something like:
echo am_cv_func_working_getline=yes config.cache
CC=${CC} ${BUILD64} ./configure ...
wouldn't it be better to say:
echo am_cv_func_working_getline=yes config.cache
because if the configure has already been run then the cache file should be
truncated.
I've assumed that _some_ architectures already write to config.cache in
these cases, but I haven't looked too deeply (the aim is to keep the
text common between the different architectures, so e.g. the
multilib/foo-64.xml will include chunks from common/foo.xml). Maybe
there is a better way to set it out ? - obviously just 'config.cache'
would do it in all cases where it is needed, but it would look clunky.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
Ken Moffat wrote:
On Mon, 24 Oct 2005, Duncan Webb wrote:
Hi all,
Just build the boot stages of Version 7.0-cross-lfs-20051023-x86_64
from a LFS 6.1 (32-bit) system. I've noticed a few small errors that
I would like to report.
5.4. Build Variables
Following the commands will set LFS_TARGET to i686-pc-linux-gnu,
which works until building glibc. Changing LFS_TARGET to
x86_64-pc-linux-gnu allowed me to complete the build.
The book (5.3) says:
| Now you will need to set the target triplet for the target
| architecure. You can do this by running the same command as above,
| just running it on the target machine. If you can't run the command
on | the target machine, you can use the table at the bottom of this
page.
What's the problem ?
Sorry, didn't make that too clear, but typing in the commands exactly as
described set my LFS_TARGET to i686-pc-linux-gnu which was incorrect.
The cause was because I was building the stuff on an Athlon64 build only
using 32bit code. I did work it out but it took some time and a lot of
googling.
What would have helped is an example of what they should be set to. I
didn't realise that the table represented the value of LFS_TARGET.
One minor points
A few of the instructions in chapter 6 say something like:
echo am_cv_func_working_getline=yes config.cache
CC=${CC} ${BUILD64} ./configure ...
wouldn't it be better to say:
echo am_cv_func_working_getline=yes config.cache
because if the configure has already been run then the cache file
should be truncated.
I've assumed that _some_ architectures already write to config.cache
in these cases, but I haven't looked too deeply (the aim is to keep
the text common between the different architectures, so e.g. the
multilib/foo-64.xml will include chunks from common/foo.xml). Maybe
there is a better way to set it out ? - obviously just 'config.cache'
would do it in all cases where it is needed, but it would look clunky.
Wouldn't think that it would make any difference which architecture you
use there shouldn't be a config.cache until either one in initialised as
described or configure has been run once.
Ken
9.4. Expect-5.43.0
I think the configure line should be:
CC=gcc ${BUILD64} ./configure --prefix=/tools --with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
10.3. Glibc-20050926
Got an error during make check, did make install and then make check
again, the check had no error after the install, odd behaviour.
Hope this helps
10.5. Binutils-2.16.1
I'm getting there errors which running check, any idea what I should do?
Running /sources/binutils-2.16.1/ld/testsuite/ld-bootstrap/bootstrap.exp ...
FAIL: bootstrap
FAIL: bootstrap with strip
FAIL: bootstrap with --traditional-format
FAIL: bootstrap with --no-keep-memory
FAIL: bootstrap with --relax
Running /sources/binutils-2.16.1/ld/testsuite/ld-cdtest/cdtest.exp ...
FAIL: cdtest
FAIL: cdtest with -Ur
TIA
Duncan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20051023-x86_64
On Mon, 24 Oct 2005, Duncan Webb wrote:
wouldn't it be better to say:
echo am_cv_func_working_getline=yes config.cache
because if the configure has already been run then the cache file should
be truncated.
I've assumed that _some_ architectures already write to config.cache in
these cases, but I haven't looked too deeply (the aim is to keep the text
common between the different architectures, so e.g. the multilib/foo-64.xml
will include chunks from common/foo.xml). Maybe there is a better way to
set it out ? - obviously just 'config.cache' would do it in all cases
where it is needed, but it would look clunky.
Wouldn't think that it would make any difference which architecture you use
there shouldn't be a config.cache until either one in initialised as
described or configure has been run once.
I'll rephrase - I think that an arch I don't have (probably sparc, or
mips, or just one of their variants) has *already* echoed something into
config.cache before adding the am_cv_func_working_getline. Therefore,
for that arch the is necessary. This only causes you a problem if
you rebuild, or retry after an error, without deleting the source/build
directories.
9.4. Expect-5.43.0
I think the configure line should be:
CC=gcc ${BUILD64} ./configure --prefix=/tools --with-tcl=/tools/lib \
--with-tclinclude=$TCLPATH --with-x=no
because the tools have not yet been built to default to 64bit.
No, in the previous section where you build tcl you should have used a
sed on Makefile.in to force lib64, and also passed --libdir=/tools/lib64.
But please read the rest of my reply!
10.3. Glibc-20050926
Got an error during make check, did make install and then make check again,
the check had no error after the install, odd behaviour.
Your *next* point, and the absence of 32-bit in this package name,
make me think you've switched to pure64 (x86_64-64) AFTER following the
multilib book in the initial chapters. Perhaps, you came back to it and
mixed the different architectures ?
FWIW, in 20050926 64-bit I see *an* error (in wcsmbs, from memory - my
logs are on another box). Haven't tried running check after installing
the 64-bit libc, but the error seems to have gone in last week's
snapshot. For 32-bit libc I'm getting a mass of errors in make check,
but nobody else has commented on them, so it could be an error in my
buildscripts.
Hope this helps
10.5. Binutils-2.16.1
I'm getting there errors which running check, any idea what I should do?
Running /sources/binutils-2.16.1/ld/testsuite/ld-bootstrap/bootstrap.exp ...
FAIL: bootstrap
FAIL: bootstrap with strip
FAIL: bootstrap with --traditional-format
FAIL: bootstrap with --no-keep-memory
FAIL: bootstrap with --relax
Running /sources/binutils-2.16.1/ld/testsuite/ld-cdtest/cdtest.exp ...
FAIL: cdtest
FAIL: cdtest with -Ur
In pure64 (at least for x86_64-64) this seems normal. I spent an
hour or two looking at the ld test suites last week after confirming
that multilib passes all of the binutils tests, but so far I haven't
even identified what is failing, or why.
Hopefully, I won't offend you when I say that you need to follow ONE
architecture (multilib, or pure64) at a time, and when I point out that
pure64 on amd64 works reasonably well _except_ for grub, and that
multilib x86_64 has some issues with perl (see Ryan's reply to me last
week on this list).
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Cross-LFS multilib - perl
On Thu, 20 Oct 2005, Ryan Oliver wrote: example patch for x86_64 lib64 attached (rename it to something appropriate) Thanks, I'll play with one of those later. Just thought I'd pipe up here... what use is there having both 32 and 64bit modules created if you are only going to be able to use either a 32 or 64bit perl? That was going to be later question, after I got my lib64 install to do the right thing. Indeed, if you attempt to build 32bit modules down the track with a 64bit perl they wont get used (if the above fix is implemented) or will not work (if they are installed to the same location as the 64bit ones). Also you will pickup the wrong install locations from the 64bit perl, pick up wrong library paths to use etc, run perl Makefile.PL on any additional module and you'll see what I mean... You need to keep both perl binaries. I have been using a binary wrapper to be able to host two versions of perl/python/whatever you want, by renaming the perl binary to perl-32 or perl-64 and creating a perl - wrapper_binary symlink. The wrapper checks an environment variable then runs the appropriate perl binary. (NOTE: wrapper has to be a binary, not a shell wrapper, or else perl scripts break when invoked). OK, thanks. I saw your wrapper script before, but didn't understand it. I've got wrapper.c now, will have to take a look at this. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS multilib - perl, glibc tests
On Wed, 19 Oct 2005, Ken Moffat wrote: For the temporary tools, I'm guessing we could just build a 32-bit perl (assuming any 64-bit testsuites will NOT produce perl modules). Progress update: Using the 20051017 glibc snapshot and ONLY a 32-bit perl in test-tools, the 64-bit glibc testsuite ALL passes on x86_64 (so, somebody has at last fixed something in wcsmbs), gcc-4.0.2 has one g++ failure, binutils all passes. Everything else passed except for lang-gawk in 64-bit gettext (test skipped in 32-bit!) and the 32-bit glibc tests which still fail all over the place for me. I'm totally baffled by the glibc-32 test failures, but so far I haven't worked out how to see any error messages other than the 'invalid character' messages for catgets/de and the 'cannot run on the de_DE.UTF-8' localemake messages. Not quite there in the final-system - discarded fedora's defines for /usr/lib/perl5 (vendor, etc), they seem to force it ALL to go into /usr/lib. With just the fedora patch and a define for -Dlibpth, I've got everything installed in /usr/lib64 and the output of perl -V is almost correct (it shows libc as /lib/libc-2.3.90.so which is decidedly 32-bit). Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS multilib - perl
On Wed, 2005-10-19 at 02:07 +0100, Ken Moffat wrote:
Hi,
it appears to me that the perl installations in a multilib build are
broken. First, in the temporary tools we end up with a /tools/bin/perl
which thinks it is a 32-bit program because it uses the Config.pm from
the 32-bit install in /tools/lib (spotted this when I tried doing
without the 32-bit perl as an experiment).
In the final system, perl knows it is 64-bit, but the libraries have
again been installed in /usr/lib/perl5 over the top of the 32-bit libs.
Missing fixes in the book
From the cross-lfs scripts
#adjust Configure and append to linux.sh if not installing to */lib
#
if [ ! ${libdirname} = lib ]; then
# We need to adjust Configure so that it understands
# installstyle=lib64/perl5 and sets up directory paths accordingly
# NOTE: may need to check how this affects vendor libs...
if [ ! -f Configure-ORIG ]; then cp Configure Configure-ORIG ;fi
sed /\*lib\/perl5\*).*/{
h
s/\([^a-zA-Z]\)lib/\1${libdirname}/g
x
G } Configure-ORIG Configure
# Now that installstyle can handle lib64, specify our
# our installstyle in linux.sh
echo installstyle=\${libdirname}/perl5\ hints/linux.sh
fi
This basically adds an installstyle for libFOO (be it
lib32/libn32/lib64) to the perl configuration and forces its use
example patch for x86_64 lib64 attached (rename it to something
appropriate)
Ensure installstyle=lib64/perl5 is appended to hints/linux.sh if the
patch is used.
These are happening because hints/linux.sh doesn't have anything to
match what we are trying to sed to lib64. Possibly, there was an
earlier patch that has fallen by the wayside.
See above
Not quite sure of the way to handle this: For the final system, I'm
trying a patch from fedora which puts all library stuff into
/usr/lib64/perl5/ where it can co-exist with the 32-bit libraries. So
far so good, but perl -V shows
ld='gcc -m64', ldflags =' -L/usr/local/lib'
libpth=/usr/local/lib /lib /usr/lib
Just thought I'd pipe up here... what use is there having both 32 and
64bit modules created if you are only going to be able to use either a
32 or 64bit perl?
Indeed, if you attempt to build 32bit modules down the track with a
64bit perl they wont get used (if the above fix is implemented) or will
not work (if they are installed to the same location as the 64bit ones).
Also you will pickup the wrong install locations from the 64bit perl,
pick up wrong library paths to use etc, run perl Makefile.PL on any
additional module and you'll see what I mean...
You need to keep both perl binaries.
I have been using a binary wrapper to be able to host two versions of
perl/python/whatever you want, by renaming the perl binary to perl-32 or
perl-64 and creating a perl - wrapper_binary symlink. The wrapper
checks an environment variable then runs the appropriate perl binary.
(NOTE: wrapper has to be a binary, not a shell wrapper, or else perl
scripts break when invoked).
Regards
[R]
--- Configure-ORIG 2005-10-20 11:49:47.571389008 +1000
+++ Configure 2005-10-20 11:49:49.480098840 +1000
@@ -5930,6 +5930,7 @@
: The default style setting is made in installstyle.U
case $installstyle in
*lib/perl5*) set dflt privlib lib/$package/$version ;;
+*lib64/perl5*) set dflt privlib lib64/$package/$version ;;
*) set dflt privlib lib/$version ;;
esac
eval $prefixit
@@ -6433,6 +6434,7 @@
case $sitelib in
'') case $installstyle in
*lib/perl5*) dflt=$siteprefix/lib/$package/site_$prog/$version ;;
+ *lib64/perl5*) dflt=$siteprefix/lib64/$package/site_$prog/$version ;;
*) dflt=$siteprefix/lib/site_$prog/$version ;;
esac
;;
@@ -6560,6 +6562,7 @@
prog=`echo $package | $sed 's/-*[0-9.]*$//'`
case $installstyle in
*lib/perl5*) dflt=$vendorprefix/lib/$package/vendor_$prog/$version ;;
+ *lib64/perl5*) dflt=$vendorprefix/lib64/$package/vendor_$prog/$version ;;
*) dflt=$vendorprefix/lib/vendor_$prog/$version ;;
esac
;;
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Cross-LFS multilib - perl
On Thu, 2005-10-20 at 11:55 +1000, Ryan Oliver wrote: SNIP updated patch attached, should be fine for MIPS n32 too ( ie lib32 ) [R] --- perl-5.8.7/Configure-ORIG 2005-10-20 11:49:47.571389008 +1000 +++ perl-5.8.7/Configure 2005-10-20 12:30:35.571236464 +1000 @@ -5930,6 +5930,8 @@ : The default style setting is made in installstyle.U case $installstyle in *lib/perl5*) set dflt privlib lib/$package/$version ;; +*lib32/perl5*) set dflt privlib lib32/$package/$version ;; +*lib64/perl5*) set dflt privlib lib64/$package/$version ;; *) set dflt privlib lib/$version ;; esac eval $prefixit @@ -6433,6 +6435,8 @@ case $sitelib in '') case $installstyle in *lib/perl5*) dflt=$siteprefix/lib/$package/site_$prog/$version ;; + *lib32/perl5*) dflt=$siteprefix/lib32/$package/site_$prog/$version ;; + *lib64/perl5*) dflt=$siteprefix/lib64/$package/site_$prog/$version ;; *) dflt=$siteprefix/lib/site_$prog/$version ;; esac ;; @@ -6560,6 +6564,8 @@ prog=`echo $package | $sed 's/-*[0-9.]*$//'` case $installstyle in *lib/perl5*) dflt=$vendorprefix/lib/$package/vendor_$prog/$version ;; + *lib32/perl5*) dflt=$vendorprefix/lib32/$package/vendor_$prog/$version ;; + *lib64/perl5*) dflt=$vendorprefix/lib64/$package/vendor_$prog/$version ;; *) dflt=$vendorprefix/lib/vendor_$prog/$version ;; esac ;; -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS multilib - perl
Ken, I will update cross-lfs with this information. Working with Ryan on it as we speak. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
cross-lfs build flags
Hello I found some problems while creating cross-lfs Sparc/UltraSparc. In chapter 9.2. Build Flags the build flags are configured as follows: export BUILD32=-mabi=32 export BUILD64=-mabi=64 using this flags I can't configure no package. The error says that the compiler cannot create executables. I've checked in gcc's man and found that there is no support for this flags for Sparc architecture. So i've started using -m23 and -m64 flags. As far as now the packages compile. Tell me please is it wright or wrong sollution. Jacek Herold -- INTERIA.PL | Kliknij po wiecej http://link.interia.pl/f18c1 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cross-lfs build flags
jaca wrote: Hello I found some problems while creating cross-lfs Sparc/UltraSparc. In chapter 9.2. Build Flags the build flags are configured as follows: export BUILD32=-mabi=32 export BUILD64=-mabi=64 using this flags I can't configure no package. The error says that the compiler cannot create executables. I've checked in gcc's man and found that there is no support for this flags for Sparc architecture. So i've started using -m23 and -m64 flags. As far as now the packages compile. I was just talking with another dev about this exact thing. :) I'm using the same flags as in chapter5 ie: BUILD32=-m32 -mcpu=ultrasparc -mtune=ultrasparc BUILD64=-m64 -mcpu=ultrasparc -mtune=ultrasparc So far everything is working well. It looks like the instructions in the book were meant for another architecture but got included in the sparc book by mistake. Investigating further... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross-LFS findutils problem.
I've been trying to understand why the findutils testsuites were failing in Cross-LFS. The first problem (the xargs suite) could be fixed by adding a /bin/echo symlink (we were using /tools/bin/echo when the test ran, and the xargs tests were rewritten for 4.2.25 - if no action is specified for xargs, /bin/echo is the default). However, completing the xargs tests without failure meant the locate tests then tried to run - to cut a long story short, these tests all work if coreutils has been installed in the final system. I ran builds with our then current order, and with coreutils moved (to where it is in LFS) and compared the results, expecting to find a binary was different. In fact, the binaries were all identical (except for the normal variation in a little of the libc++ stuff), but I discovered that the installed updatedb differed. Updatedb is a script. With the build order rearranged, it references /usr/bin/sort. With the old build order, it references /tools/bin/sort which obviously only works when /tools is available. Fixed in r6968, users of previous builds should edit /usr/bin/updatedb and edit the several sort=/tools/bin/sort lines. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
On Thu, 2005-09-15 at 21:20 +0100, Ken Moffat wrote: I'll clarify my earlier posting - I want to run on x86_64 (ideally with lib and lib32, but I haven't started looking at that yet) Bear with me a bit... just coming back online from an lfs hiatus due to extreme work pressures. I hope to be addressing the issue of allowing folks to decide where their multilib libraries go in the next couple of weeks... Be it lib / lib32 or what looks like the debian alternative, ie: /tgt-triple/lib for each arch... Just need some spare time :-/ Regards [R] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS
On Sun, 2 Oct 2005, M.Canales.es wrote: If you are rendering/validating all book each time that you made a little change in the sources, yes, the process is very long. But if the change you made only affect some archs, you can validate/render only that books (for example, mips ands mips64) adding ARCH=mips mips64 to the make command. OK, thanks for that tip. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS for MIPS64
I've been updating the book lately, I may of messed up the gcc part. Will check today and fix it. I'll let you know -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS for MIPS64
Peter Szwed wrote: Pete, Are you doing a multilib or a Pure 64 build. I'm finishing testing on a RaQ2 Pure 64 updating the book as I go. I am using the pure 64 instructions - thought that would be the most direct way to get a 64-bit executable. I found it add --with-abi=64 to your gcc builds. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS
On Sat, 1 Oct 2005, Jim Gifford wrote:
Manuel and LFS-dev,
I have been thinking about this for a few days. Cross-LFS has two
different options in it, boot and chroot. Boot is a complete reboot and
chroot is like the standard LFS book. Talking with various people, an idea
popped into my mind. Having two separate books, Cross-LFS with the
cross-tools and boot section and a version of the old Multi-Arch LFS book
which would have the cross-tools section remove and utilizing the chroot
section.
Actually, to get to x86_64 from x86 I take a slightly different path -
cross-compile from x86, cross-compile a non-modular kernel [ because the
x86 modutils are going to be used ], reboot to the new kernel (64-bit
kernel, i686 userspace) and then chroot.
The only downfall I see of this idea, is the book rendering issues. Is it
possible just to render the complete book as it is now, and then make new
index pages with the sections listed as above?
There is a slight difficulty with starting at binutils in Contructing a
Temporary System - we only build binutils and gcc once and we don't
build glibc at all ;) Realistically, the multi-arch book would need
sections added. Also, we're using ${LFS_TARGET}-gcc and friends - it
doesn't feel right to specify LFS_TARGET in a native build, and there
are config.cache things that are only needed in a cross-compile.
What type of modifications would we need to do accomplish this?
Would LFS benefit from this? (I say yes)
Please express your thoughts and even pose questions.
I'm all in favour of extending the platforms that people can reliably
use for LFS, but I don't see tangible gains - as I read your proposal,
there would be two books with a common source. Users might be attracted
by not having to cross-compile, but equally they might think that issues
in cross-lfs were unrelated to their multi-arch lfs.
I'm also a little worried that rendering the book will become unwieldy.
It already strains my patience ;)
Ken
--
das eine Mal als Tragödie, das andere Mal als Farce
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Cross-LFS questions
Two questions: (i) Is there still a public rendering of this book ? I went to the website to check if I'd borked something in my editing but couldn't find any mention of Cross-LFS. Perhaps it's part of the restructuring. (/me suppresses a thought that editors on non-projects have a tendency to become non-persons :) (ii) For anybody who has built a pure64 system without chrooting using the if you are going to boot route, should we _really_ be installing e2fsprogs into /tools/lib64 ? This sounds broken, but maybe I'm overlooking something. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross LFS Status
I haven't done one of these in a few weeks, been tied up at work. I would like to thank Matt Darcy, Joe Ciccone, Manuel Canales, and Ken Moffat for their fine addtitions to the book over the past few weeks. I really appreciate it. We are currently trying to stablize the Cross-LFS book. Here are the current status of issues. All Architectures now - NPTL GCC 4.0.2 added Using Glibc Snapshot - Needed for NPTL support and GCC 4.x.x fixes MIPS64 is Pure 64 capable and is working Alpha fully working x86 fully working MIPS fully working MIPS64 fully working Outstanding Issues PPC Yaboot Pure64 Builds Bootloaders, what to do, suggestions welcomed, Biggest concerns Silo and Grub lack of ability to be compiled as 64 Bit. -- Programmers welcome!! MIPS/MIPS64 Adding arcboot to the book for other MIPS based machines Book Update the earilier chapters of the book to reflect cross-compiling Add all missing configuration lines -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS Status
On Fri, 30 Sep 2005, Jim Gifford wrote: We are currently trying to stablize the Cross-LFS book. Any thoughts on a package freeze for existing packages, particularly glibc ? (That is, freeze versions unless it becomes clear that a different version will solve problems). I'm preparing to start some fresh builds (x86, x86_64-64, x86_64 on the same machine), hopefully tomorrow, but if we upgrade glibc each week my test results will be worthless by the time I have them ;) Outstanding Issues PPC Yaboot The only issue I've noticed is the errors in the list of files to install into /boot (/me admits to still not getting around to correcting this). Anything else ? Pure64 Builds Bootloaders, what to do, suggestions welcomed, Biggest concerns Silo and Grub lack of ability to be compiled as 64 Bit. -- Programmers welcome!! For x86_64-64 lilo compiles and works now, or at least it did last time I checked. Book Update the earilier chapters of the book to reflect cross-compiling Add all missing configuration lines Any thoughts on what to do about space/time measurements ? I'm not a big fan of SBUs, but (at least on non-cross) they have some element of repeatability if people don't get too finicky with how precisely they measure them. I think Manuel had a suggestion about what to use as an approximate SBU when building the final system if this was a true cross-build. Maybe we could have SBUs for the first part, and NBUs (native build units) for the temp tools and final system. I'm fairly sure that the space used in the first part of the build will depend on both the host and the target (e.g. ppc32 instructions are all 32 bits, and building glibc back in the days of LFS-5.0 took a lot more space on ppc than on x86). Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS Status
Ken Moffat wrote: On Fri, 30 Sep 2005, Jim Gifford wrote: Any thoughts on a package freeze for existing packages, particularly glibc ? (That is, freeze versions unless it becomes clear that a different version will solve problems). I'm preparing to start some fresh builds (x86, x86_64-64, x86_64 on the same machine), hopefully tomorrow, but if we upgrade glibc each week my test results will be worthless by the time I have them ;) As far as I'm concerned 20050926 is the last version we will use, it's stable on all platforms. Pure64 Builds Bootloaders, what to do, suggestions welcomed, Biggest concerns Silo and Grub lack of ability to be compiled as 64 Bit. -- Programmers welcome!! For x86_64-64 lilo compiles and works now, or at least it did last time I checked. That's a possibility but it means adding some packages back. Right now we have people looking at solving both issues by gettting Grub 2 working. Book Update the earilier chapters of the book to reflect cross-compiling Add all missing configuration lines Any thoughts on what to do about space/time measurements ? I'm not a big fan of SBUs, but (at least on non-cross) they have some element of repeatability if people don't get too finicky with how precisely they measure them. I think Manuel had a suggestion about what to use as an approximate SBU when building the final system if this was a true cross-build. Maybe we could have SBUs for the first part, and NBUs (native build units) for the temp tools and final system. I'm fairly sure that the space used in the first part of the build will depend on both the host and the target (e.g. ppc32 instructions are all 32 bits, and building glibc back in the days of LFS-5.0 took a lot more space on ppc than on x86). SBU's will not be valid in this book, since every platform will be different, I don't think we have the time to recalculate everytime a package changes. Honestly most people don't even look at them as evident from some of the discussions on lfs-support on irc. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Matthew Burgess wrote: sort that out. I can't think of any other infrastructure tasks that need to be carried out, though polite reminders are always useful :) - - Add a Bugzilla product entry for the new book. - - Make an official announcement? - - Update update-website.mk script to render the dynamic site content (e.g. SVN logs) for the new project (I can take care of this). - -- Anderson Lizardo [EMAIL PROTECTED] http://www.linuxfromscratch.org/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFDMg7bkzNmn+NRHHoRAgTDAJ0eTLplZzT8fUdrY5NlE2Np05zRCwCgj1xb zwr15zvA3M26IF4hmkTQmTg= =W9pG -END PGP SIGNATURE- ___ Novo Yahoo! Messenger com voz: ligações, Yahoo! Avatars, novos emoticons e muito mais. Instale agora! www.yahoo.com.br/messenger/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross-LFS: Diff for materials page
Hi guys, While building the ftp repo, I found a incorrectly built link, and also a couple patches out of alphabetical order. Here is a svn diff. Justin Index: materials/sparc64/patches.xml === --- materials/sparc64/patches.xml (revision 6874) +++ materials/sparc64/patches.xml (working copy) @@ -46,6 +46,14 @@ /listitem /varlistentry + varlistentry + termKBD kbdrate Patch - 1 KB:/term + listitem +paraulink +url=patches-root;kbd/kbd-sparc_kbdrate-patch;//para + /listitem +/varlistentry + varlistentry termLinux GCC 4.x Patch - 1 KB:/term listitem @@ -70,14 +78,6 @@ /listitem /varlistentry - varlistentry - termKBD kbdrate Patch - 1 KB:/term - listitem -paraulink -url=patches-root;grep/kbd-sparc_kbdrate-patch;//para - /listitem -/varlistentry - varlistentry termSilo Fixes Patch - 4 KB:/term listitem Index: materials/sparc/patches.xml === --- materials/sparc/patches.xml (revision 6874) +++ materials/sparc/patches.xml (working copy) @@ -26,7 +26,7 @@ termKBD kbdrate Patch - 1 KB:/term listitem paraulink -url=patches-root;grep/kbd-sparc_kbdrate-patch;//para +url=patches-root;kbd/kbd-sparc_kbdrate-patch;//para /listitem /varlistentry Index: materials/sparc64-64/patches.xml === --- materials/sparc64-64/patches.xml(revision 6874) +++ materials/sparc64-64/patches.xml(working copy) @@ -46,6 +46,14 @@ /listitem /varlistentry + varlistentry + termKBD kbdrate Patch - 1 KB:/term + listitem +paraulink +url=patches-root;kbd/kbd-sparc_kbdrate-patch;//para + /listitem +/varlistentry + varlistentry termLinux GCC 4.x Patch - 1 KB:/term listitem @@ -62,14 +70,6 @@ /listitem /varlistentry - varlistentry - termKBD kbdrate Patch - 1 KB:/term - listitem -paraulink -url=patches-root;grep/kbd-sparc_kbdrate-patch;//para - /listitem -/varlistentry - varlistentry termSilo Fixes Patch - 3.5 KB:/term listitem -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
M.Canales.es wrote: ... and to create the web pages for that new project ;-) Yep, this too. :) Once Jim gets the OK, I will tackle this part. -- Justin R. Knierim lfs at lfs dash matrix dot net -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
Jim Gifford wrote: After some discussion with Gerard, he has requested I prepare a proposal to the LFS community concerning the Cross-LFS book. Have we reached any sort of decision with this? Gerard, Matt, Jim? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
Haven't heard anything except for the community's feedback. I know Gerard has received the message and is reviewing it, per our conversation over the weekend. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
El Jueves, 15 de Septiembre de 2005 23:43, Jim Gifford escribió: If we do this, we could remove chroot from the Cross-LFS, since it's only there for same arch to same arch capability. Exactly ;-) -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
On Don, 2005-09-15 at 14:43 -0700, Jim Gifford wrote: M.Canales.es wrote: Yes, that is how I see it also. Both books could be almost indentical except in how the tolchains are created and the way used to build the final system (boot or chroot). If we do this, we could remove chroot from the Cross-LFS, since it's only there for same arch to same arch capability. What about cross-build on cpus that support multiple archs? (e.g. x86 - x86_64, x86 - IA64, ...) Jürg -- Jürg Billeter [EMAIL PROTECTED] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
RFC - Cross-LFS Future
After some discussion with Gerard, he has requested I prepare a proposal to the LFS community concerning the Cross-LFS book. Up to this point work on Cross-LFS has been done with the idea that, eventually, its features would be merged into the main LFS book. I would like at this time to propose that we create a separate project for Cross-LFS, like ALFS, HLFS and BLFS. There are many reasons for wanting to do so: * Keeping the books as separate projects allows users learning the LFS process to focus on what is needed and avoid confusion with techniques/patches. * Toolchain maintenance. Due to the amount of platforms Cross-LFS is geared towards, it is possible that in the future the toolchain will need to be changed to include/remove something that is not necessary in the LFS toolchain. By keeping these two books as separate projects we can remove the need for dependencies on other projects much like the LFS/BLFS bootscript compatibility issues. * The ability of two separate platforms as test platforms (a straight build and a cross build) will offer more opportunity to find bugs/problems with packages in more scenarios, thus helping version stability/usability on packages. The reverse can also be said about logging faults. Why waste the LFS community's time searching for a bug in the build process when it is a Cross-LFS bug only? Cross-LFS will tend to see more build issues due to its build nature; LFS can then investigate to see what affects them. Pros: 1Multi-architecture build - We can build on any platform. 2Keeping Cross-LFS related bugs and support questions off of the LFS List, since only a few of us currently can support it. 3 Book will always be under constant development due to the nature of it's build scenario and the multiple architectures it supports. We have a lot of community input. 4 Techniques used in this book could be used to enhance LFS and HLFS build process. 5 Cross-LFS could potentially see issues before LFS. We also seem to find all the weird glitches with programs due to the nature of the book. 6 Multilib support for architectures that can support it. Cons: 1 Multi-architecture build - The book is designed around building a complete toolchain. So when compiling x86 to x86 for example will still build a complete toolchain.. 2 Support. Cross-LFS maintainers will have to support more than one architecture. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
Jim Gifford wrote: I would like at this time to propose that we create a separate project for Cross-LFS, like ALFS, HLFS and BLFS. There are many reasons for wanting to do so: Agreed in priniciple, though I have a couple of nits to pick... Why waste the LFS community's time searching for a bug in the build process when it is a Cross-LFS bug only? Cross-LFS will tend to see more build issues due to its build nature; LFS can then investigate to see what affects them. I'd rather see this investigation instigated from the Cross-LFS side of things to be honest. You can't expect all of lfs-dev to subscribe to cross-lfs-dev (or whatever), and therefore I'll go out on a limb and say it would be fairer if cross-lfs devs post any potential issues with LFS' toolchain/build process to lfs-dev. We'll then of course endeavour to investigate the problem to see if it does indeed affect us, and if cross-lfs can reduce things down to a minimal testcase that demonstrates the problem, so much the better. Cons: The cons you give appear to be cons of the cross-lfs book itself, not of moving the book out from a branch to a project in its own right. i.e. I don't see any cons with the move at all :) Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
Matthew Burgess wrote: Jim Gifford wrote: I would like at this time to propose that we create a separate project for Cross-LFS, like ALFS, HLFS and BLFS. There are many reasons for wanting to do so: Agreed in priniciple Me too. It's nearly its own project now as it is. I'd rather see this investigation instigated from the Cross-LFS side of things to be honest. You can't expect all of lfs-dev to subscribe to cross-lfs-dev (or whatever), and therefore I'll go out on a limb and say it would be fairer if cross-lfs devs post any potential issues with LFS' toolchain/build process to lfs-dev. We'll then of course endeavour to investigate the problem to see if it does indeed affect us, and if cross-lfs can reduce things down to a minimal testcase that demonstrates the problem, so much the better. That seems to be the natural course to follow. I would like to see some of the goals/guiding principles of Cross-LFS layed out, too though. For example, how closely does it follow LFS and decisions made there, like package versions, etc? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
Jeremy Huntwork wrote: That seems to be the natural course to follow. I would like to see some of the goals/guiding principles of Cross-LFS layed out, too though. For example, how closely does it follow LFS and decisions made there, like package versions, etc? Depending on the outcome of this topic, I was going to design decision chart of how cross-lfs will base it's decisions. Which will have all the criteria of how we will do things. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
On Thu, 15 Sep 2005, Jim Gifford wrote: Jeremy Huntwork wrote: That seems to be the natural course to follow. I would like to see some of the goals/guiding principles of Cross-LFS layed out, too though. For example, how closely does it follow LFS and decisions made there, like package versions, etc? Depending on the outcome of this topic, I was going to design decision chart of how cross-lfs will base it's decisions. Which will have all the criteria of how we will do things. Heh, I've long wanted LFS to deal with more platforms, so although I dislike cross-building when it isn't strictly necessary, and living on the bleeding edge, I've got to go with this. Looking forward to the decision chart. Ken -- das eine Mal als Trag?die, das andere Mal als Farce-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
El Jueves, 15 de Septiembre de 2005 19:06, Jim Gifford escribió: After some discussion with Gerard, he has requested I prepare a proposal to the LFS community concerning the Cross-LFS book. Up to this point work on Cross-LFS has been done with the idea that, eventually, its features would be merged into the main LFS book. I would like at this time to propose that we create a separate project for Cross-LFS, like ALFS, HLFS and BLFS. There are many reasons for wanting to do so: If that will meant that Cross-LFS will be focused on pure cross-build techniques and scenarios, i.e. it assumes that host-triplet != target-triplet, thus no chroot way to build the final system, focusing the normal LFS book on host-triplet = target-triplet builds (not only for x86, but also for other archs, primarily x86_64) using the chroot way, then I support the proposal. But if we keep Cross-LFS as is now, and LFS centered only on x86, that could meant the dead of the LFS book in a no very far future, IMHO. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
On Thu, Sep 15, 2005 at 08:33:59PM +0200, M.Canales.es wrote: If that will meant that Cross-LFS will be focused on pure cross-build techniques and scenarios, i.e. it assumes that host-triplet != target-triplet, thus no chroot way to build the final system, focusing the normal LFS book on host-triplet = target-triplet builds (not only for x86, but also for other archs, primarily x86_64) using the chroot way, then I support the proposal. Hrmmm. Interesting point Manuel. If I buy an x64_64 and cross-lfs it, I will nave no need for cross-lfs anymore. I could use the current cross-lfs host to build a standard lfs from there on (at least in theory). Likewise, in the case of x86_64, faking the uname can just about get you from x86 to x86_64. As the support for the new arch continues to expand, eventually lfs would be able to conver it natively without much change. However, more exotic desires such as multilib would still require cross-lfs. But if we keep Cross-LFS as is now, and LFS centered only on x86, that could meant the dead of the LFS book in a no very far future, IMHO. Judging by how many people still use 486 and 586 machines, and adding to that the fact that x86 is still the dominant mainstream purchase, I'd say that LFS would have *several* years of vitality left. However, your point is valid (timeline excluded) and should be considered thoroughly. -- Archaic Want control, education, and security from your operating system? Hardened Linux From Scratch http://www.linuxfromscratch.org/hlfs -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
On Thu, 15 Sep 2005, M.Canales.es wrote: If that will meant that Cross-LFS will be focused on pure cross-build techniques and scenarios, i.e. it assumes that host-triplet != target-triplet, thus no chroot way to build the final system, focusing the normal LFS book on host-triplet = target-triplet builds (not only for x86, but also for other archs, primarily x86_64) using the chroot way, then I support the proposal. Hmm, I didn't see that in the proposal. From my POV, if Cross-LFS is restricted to host != target the number of likely users will be cut dramatically. More to the point, I've seen no sign of willingness to (re-)admit other architectures to the normal LFS book (it used to have a ppc version, but that was before my time). I'll clarify my earlier posting - I want to run on x86_64 (ideally with lib and lib32, but I haven't started looking at that yet) and ppc at the moment, my interest in i686 is not great (it builds, it runs, it's a boring architecture). Until Jim posted, the only game in town offering that was Cross-LFS. Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
El Jueves, 15 de Septiembre de 2005 22:56, Jim Gifford escribió: One of things I've been mulling over is maybe have cross-lfs just build the toolchains, but the rest of the stuff, currently the temp-system and final-system of Cross-LFS, could be the future LFS book that supports multiple architectures. Yes, that is how I see it also. Both books could be almost indentical except in how the tolchains are created and the way used to build the final system (boot or chroot). -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.com TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
Jim Gifford wrote: One of things I've been mulling over is maybe have cross-lfs just build the toolchains, but the rest of the stuff, currently the temp-system and final-system of Cross-LFS, could be the future LFS book that supports multiple architectures. I'll put my comments in now that I'm on a working machine. I'm putting my X behinds Jims proposal, pretty much for the exact reason he outlined in it, almost to the letter. I feel that as a seperate project the cross-build process will benifit the straight LFS project and vice a versa in finding bugs/incompatabilies/new features maybe ? I jus think it opens doors, and on serious issues puts double the brain power/resources/testing behind it. I think as long as information is shared in a two way street after a short learning period the two groups will see massive benifits. Also as a good few people will work/have interest in both projects it will really open more possabilities and ideas. There seems to be a concern that in time the cross-process will replace the straight build process. I can't see it myself unless there is a real lead towards this. If I'm building a 32bit x86 host for example, its easier for me to stick the live CD in and build it straight, if I have a sun box running, solaris 64 bit, its easier for me to build LFS 64 straight. Granted I'll probably cross-build a few things for the sake of it for interests sake, as cross-building has found some really unusual bugs, which the LFS community are aware of and I think will be usefull in the next LFS release or dev book, but as a whole straight architecture building shouldn't go away unless the LFS project decideds that cross-building is the way to go. I'm backing this all the way, I think it will be a real benifit for all, and help keep things clear. Matt -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.344 / Virus Database: 267.10.25/102 - Release Date: 14/09/2005 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
M.Canales.es wrote: Yes, that is how I see it also. Both books could be almost indentical except in how the tolchains are created and the way used to build the final system (boot or chroot). If we do this, we could remove chroot from the Cross-LFS, since it's only there for same arch to same arch capability. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: RFC - Cross-LFS Future
Jim Gifford wrote: I would like at this time to propose that we create a separate project for Cross-LFS, like ALFS, HLFS and BLFS. snip reasons That sounds like a good idea to me. +1 Justin -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On Sat, 20 Aug 2005, Ken Moffat wrote: On Fri, 19 Aug 2005, Jim Gifford wrote: Ken, Ryan, Doug, and others Do we need to make a change here for the pure64 build, or is further testing needed? Well, I've got through this part now, using 20050821, building pure64 from my own pure64. The ldd problem that bit Doug didn't affect me (and my RTLDLIST has /lib/ld-linux.so.2 and /lib/ld-linux-x86-64.so.2). Unfortunately, it looks as if glibc decided not to respect --libdir=/lib for me - all the libraries went into /lib64 which caused binutils' configure-libiberty to fail with the misleading if you want to cross compile message. Actually, that's not true - /usr/lib has libc.a, the crt stuff, gconv/ plus a load of .so files which turn out to be symlinks to /lib64. But all of the shared objects are in /lib64 and /lib is empty. So --libdir seems to affect the libraries that would ordinarily go into /usr/lib* but not the libraries that go into lib*. I'm puzzled, Doug appeared to have got past this because he queried the gcc instructions. I think he said he'd be away this week, so I'm not waiting for an answer. I think that one of my patches used to hack this, but I'll take a more detailed look at glibc to see if it's amenable to other means of putting this stuff in /lib. That will be after I've started over (this time I'll take a backup before installing libc). Ken -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On Tue, 23 Aug 2005, Ken Moffat wrote: Sack-cloth and ashes time. I missed the slibdir=/lib part. Since LFS is all about learning, anybody like to point me to a HOWTO on learning to read what the book says, rather than what I think it says ? Thanks for the clue, Jim. So, now I'll confirm Doug's problem :-( CC=gcc /usr/bin/perl scripts/test-installation.pl /building/glibc-build/ /usr/bin/ldd: line 167: /lib/ld-linux.so.2: No such file or directory ldd: /lib/ld-linux.so.2 exited with unknown exit code (127) ldd execution failed at scripts/test-installation.pl line 182. make[1]: *** [install] Error 1 make[1]: Leaving directory `/building/glibc-2.3.5' make: *** [install] Error 2 Apparently, the script thinks this is a multilib build. Strange that without the slibdir=/lib it must have been happy not to test the 32-bit stuff. Ken -- das eine Mal als Trag?die, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
Ken Moffat wrote: Since LFS is all about learning, anybody like to point me to a HOWTO on learning to read what the book says, rather than what I think it says ? Right after I finish this new compiler I'm working on -- RPM: Read Programmer's Mind. :) -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On Wed, 24 Aug 2005, Ken Moffat wrote:
On Tue, 23 Aug 2005, Jim Gifford wrote:
No problems Ken. But what do you think of my reasoning on the error about
the different symlink names for ld?
At the moment, that sounds plausible (I've just posted about the perl script
bailing out). I used to have a --disable-multilib in my scripts, I don't
know that it ever did any good, but I'll try that before trying to grok the
perl.
Ken
As I suspected, --disable-multilib is ignored. For the moment, I've
taken the easy way out and gone with the attached patch which I think
was originally from the debian amd64 list, via Tooley's site. Replaces
the slibdir= for x86_64-64 only.
What I don't understand is why this works - I imagine that the
nonexistent lib32/ld-linux.so.2 would be as equally problematic as the
non-existent lib/ld-linux.so.2 for test-installation.pl, but it seems to
cope (got through binutils this time, so I'll leave it overnight)
Comments on using this patch, anybody ?
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/configure
glibc-2.3.4/sysdeps/unix/sysv/linux/configure
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/configure 2004-07-06
06:13:42.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/configure 2005-02-08
15:31:40.0 +0100
@@ -226,7 +226,7 @@
/usr | /usr/)
# 64-bit libraries on bi-arch platforms go in /lib64 instead of /lib
case $machine in
- sparc/sparc64 | x86_64 | powerpc/powerpc64 | s390/s390-64 | \
+ sparc/sparc64 | powerpc/powerpc64 | s390/s390-64 | \
mips/mips64/n64/* )
libc_cv_slibdir=/lib64
if test $libdir = '${exec_prefix}/lib'; then
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/configure.in
glibc-2.3.4/sysdeps/unix/sysv/linux/configure.in
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/configure.in 2004-07-06
06:11:40.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/configure.in2005-02-08
15:31:40.0 +0100
@@ -161,7 +161,7 @@
/usr | /usr/)
# 64-bit libraries on bi-arch platforms go in /lib64 instead of /lib
case $machine in
- sparc/sparc64 | x86_64 | powerpc/powerpc64 | s390/s390-64 | \
+ sparc/sparc64 | powerpc/powerpc64 | s390/s390-64 | \
mips/mips64/n64/* )
libc_cv_slibdir=/lib64
if test $libdir = '${exec_prefix}/lib'; then
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/i386/ldconfig.h
glibc-2.3.4/sysdeps/unix/sysv/linux/i386/ldconfig.h
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/i386/ldconfig.h2001-07-06
06:56:16.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/i386/ldconfig.h 2005-02-08
15:32:07.0 +0100
@@ -19,7 +19,7 @@
#include sysdeps/generic/ldconfig.h
#define SYSDEP_KNOWN_INTERPRETER_NAMES \
- { /lib/ld-linux.so.1, FLAG_ELF_LIBC5 },
+ { /lib32/ld-linux.so.1, FLAG_ELF_LIBC5 },
#define SYSDEP_KNOWN_LIBRARY_NAMES \
{ libc.so.5, FLAG_ELF_LIBC5 }, \
{ libm.so.5, FLAG_ELF_LIBC5 },
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/x86_64/ldconfig.h
glibc-2.3.4/sysdeps/unix/sysv/linux/x86_64/ldconfig.h
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/x86_64/ldconfig.h 2002-04-22
13:51:40.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/x86_64/ldconfig.h 2005-02-08
15:31:40.0 +0100
@@ -19,8 +19,8 @@
#include sysdeps/generic/ldconfig.h
#define SYSDEP_KNOWN_INTERPRETER_NAMES \
- { /lib/ld-linux.so.2, FLAG_ELF_LIBC6 }, \
- { /lib64/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
+ { /lib32/ld-linux.so.2, FLAG_ELF_LIBC6 }, \
+ { /lib/ld-linux-x86-64.so.2, FLAG_ELF_LIBC6 },
#define SYSDEP_KNOWN_LIBRARY_NAMES \
{ libc.so.6, FLAG_ELF_LIBC6 }, \
{ libm.so.6, FLAG_ELF_LIBC6 },
diff -Naur -i glibc-2.3.4.orig/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
glibc-2.3.4/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
--- glibc-2.3.4.orig/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed
2002-04-08 13:14:01.0 +0200
+++ glibc-2.3.4/sysdeps/unix/sysv/linux/x86_64/ldd-rewrite.sed 2005-02-08
15:31:40.0 +0100
@@ -1,3 +1,3 @@
/LD_TRACE_LOADED_OBJECTS=1/a\
add_env=$add_env LD_LIBRARY_VERSION=\\$verify_out
-s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \264\4\5\6_
+s_^\(RTLDLIST=\)\(.*lib\)\(\|64\)\(/[^/]*\)\(-x86-64\)\(\.so\.[0-9.]*\)[
]*$_\1\2\4\6 \2\4\5\6_
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On 8/20/05, Ken Moffat [EMAIL PROTECTED] wrote: The test-installation.pl script hasn't changed between 2.3.4 and 2.3.5. I think Doug mentioned /lib32/ld-linux.so.2, maybe the missing _directory_ is what causes ldd to bail out ? No, mine wasn't adjusted from a multi-lib install. It called out a /lib/ld-linux.so.2 and a /lib64/ld-linux-x86-64.so.2, neither of which existed. -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: pure64 Version 7.0-cross-lfs-20050819-x86_64 chapter 10.6
During testing with some of the different architectures it doesn't get enabled by default that's why it's been added to the cross-lfs build. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Version 7.0-cross-lfs-20050818-x86_64
I don't know if this is really a bug or not. Several tools in the cross compiler and the temporary tools install things into libexec. So far it hasn't caused me any trouble as I think they are things that never get used, then the directories get deleted. But it got me curious, I don't see a libexec in the FHS, what is libexec and why does it exist? The packages are: chapter 5: cross tools gcc-static (5.8) puts some stuff in libexec in the cross-tools directory glibc (5.9) puts some stuff in libexec in the tools directory chapter 6: temporary tools gcc (6.4) puts some stuff in libexec in the tools directory gawk (6.6) puts awk in the /tools/libexec (also puts it in /tools/bin where it belongs) findutils (6.11) puts a few in /tools/libexec tar also (6.18) -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: libexec [was: Version 7.0-cross-lfs-20050818-x86_64]
I don't know if this is really a bug or not. Several tools in the cross compiler and the temporary tools install things into libexec. So far it hasn't caused me any trouble as I think they are things that never get used, then the directories get deleted. But it got me curious, I don't see a libexec in the FHS, what is libexec and why does it exist? I've had this stashed away in a notes file for ages, might be of interest. (cant recall which package's configure it was, apache perhaps ?) GNU system directory layout : from configure --help bindir user executables /bin sbindirsystem admin executables /sbin libexecdir program executables /libexec datadirread-only architecture-independent data /share sysconfdir read-only single-machine data/etc sharedstatedir modifiable architecture-independent data /com localstatedir modifiable single-machine data /var libdir object code libraries/lib includedir C header files /include libexecdir is (was ?), I seem to recall, supposed to be for binaries that only get called by other library functions, that is, not directly by the user. I have always assumed, without fully understanding why, in the two contexts of modifiable vs read-only, and shared vs local, which the FHS talks about, that this was merely done to seperate those particular binaries from a directory containing just libraries (/lib). I think /com seems to have fallen out of fashion, assuming it was ever in, too ! -- Regards, -- * Kevin M. Buckley e-mail: [EMAIL PROTECTED] * ** * Systems Administrator * * Computer Centre * * Lancaster University Voice: +44 (0) 1524 5 93718* * LANCASTER. LA1 4YWFax : +44 (0) 1524 5 25113* * England. * ** * My PC runs Linux/GNU, you still computing the Bill Gate$' way ? * -- -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20050818-x86_64
On 8/19/05, Jim Gifford [EMAIL PROTECTED] wrote: Doug, After LFS is built, you can safely delete the /tools directory, but I recommend keeping it as a contingency if something should ever go wrong. I never thought of that, pretty good idea though. -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20050818-x86_64
Doug Ronne wrote these words on 08/19/05 10:32 CST: On 8/19/05, Jim Gifford [EMAIL PROTECTED] wrote: After LFS is built, you can safely delete the /tools directory, but I recommend keeping it as a contingency if something should ever go wrong. I never thought of that, pretty good idea though. [EMAIL PROTECTED]: ~/build ls -l Build-System/Tools* -rw-r- 1 rml users 3707 Aug 6 21:05 Build-System/Tools.tar.bz2 -rw-r- 1 rml users 360262 Aug 6 21:05 Build-System/Tools.tar.filelist Works for me! -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 11:48:00 up 139 days, 11:21, 3 users, load average: 0.06, 0.07, 0.14 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On 8/19/05, Bryan Kadzban [EMAIL PROTECTED] wrote: Doug Ronne wrote: /usr/bin/ldd: line 167: /lib/ld-linux.so.2: No such file or directory So I don't understand who or what is asking for /lib/ld-linux.so.2. Looks like /usr/bin/ldd is asking for it to me. Maybe double check that? It's just a script. Try changing the RTLDLIST variable at the beginning. (I'd attempt to put both the 64-bit ld.so and the 32-bit ld.so in there, in that order. That may not work, though.) aha! I never really knew what ldd was for. I thought all that was done by ldconfig. I looked, and it had RTDLIST=/lib/ld-linux.so.2 /lib64/ld-linux-x86-64.so.2 I changed that and everything seems hunky-dory. thanks, -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross-LFS - svn diff to correct a repeated typo
As attachment a svn diff from BOOK to correct all misspellings of Additional. Justin Index: materials/sparc64/patches.xml === --- materials/sparc64/patches.xml (revision 6721) +++ materials/sparc64/patches.xml (working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-sparc64 ?dbhtml filename=patches-sparc64.html? - titleAditional Patches for Sparc64/title + titleAdditional Patches for Sparc64/title variablelist role=materials Index: materials/ppc/patches.xml === --- materials/ppc/patches.xml (revision 6721) +++ materials/ppc/patches.xml (working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-ppc ?dbhtml filename=patches-ppc.html? - titleAditional Patches for PowerPC/title + titleAdditional Patches for PowerPC/title variablelist role=materials Index: materials/ppc/packages.xml === --- materials/ppc/packages.xml (revision 6721) +++ materials/ppc/packages.xml (working copy) @@ -8,7 +8,7 @@ sect1 id=ch-materials-packages-ppc ?dbhtml filename=packages-ppc.html? - titleAditional Packages for PowerPC/title + titleAdditional Packages for PowerPC/title variablelist role=materials Index: materials/mips64/patches.xml === --- materials/mips64/patches.xml(revision 6721) +++ materials/mips64/patches.xml(working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-mips64 ?dbhtml filename=patches-mips64.html? - titleAditional Patches for MIPS 64 Bit/title + titleAdditional Patches for MIPS 64 Bit/title variablelist role=materials Index: materials/x86/patches.xml === --- materials/x86/patches.xml (revision 6721) +++ materials/x86/patches.xml (working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-x86 ?dbhtml filename=patches-x86.html? - titleAditional Patches for x86/title + titleAdditional Patches for x86/title variablelist role=materials Index: materials/x86_64-64/patches.xml === --- materials/x86_64-64/patches.xml (revision 6721) +++ materials/x86_64-64/patches.xml (working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-x86_64 ?dbhtml filename=patches-x86_64.html? - titleAditional Patches for x86_64/title + titleAdditional Patches for x86_64/title variablelist role=materials Index: materials/x86_64/patches.xml === --- materials/x86_64/patches.xml(revision 6721) +++ materials/x86_64/patches.xml(working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-x86_64 ?dbhtml filename=patches-x86_64.html? - titleAditional Patches for x86_64/title + titleAdditional Patches for x86_64/title variablelist role=materials Index: materials/mips/patches.xml === --- materials/mips/patches.xml (revision 6721) +++ materials/mips/patches.xml (working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-mips ?dbhtml filename=patches-mips.html? - titleAditional Patches for MIPS 32 Bits/title + titleAdditional Patches for MIPS 32 Bits/title variablelist role=materials Index: materials/sparc/patches.xml === --- materials/sparc/patches.xml (revision 6721) +++ materials/sparc/patches.xml (working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-sparc ?dbhtml filename=patches-sparc.html? - titleAditional Patches for Sparc/title + titleAdditional Patches for Sparc/title variablelist role=materials Index: materials/mips64-64/patches.xml === --- materials/mips64-64/patches.xml (revision 6721) +++ materials/mips64-64/patches.xml (working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-mips64 ?dbhtml filename=patches-mips64.html? - titleAditional Patches for MIPS 64 Bit/title + titleAdditional Patches for MIPS 64 Bit/title variablelist role=materials Index: materials/sparc64-64/patches.xml === --- materials/sparc64-64/patches.xml(revision 6721) +++ materials/sparc64-64/patches.xml(working copy) @@ -10,7 +10,7 @@ sect1 id=ch-materials-patches-sparc64 ?dbhtml filename=patches-sparc64.html? - titleAditional Patches for Sparc64/title + titleAdditional Patches for Sparc64/title variablelist role=materials -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
pure64 Version 7.0-cross-lfs-20050819-x86_64 chapter 10.6
In chapter 10.6 the line ../gcc-3.4.4/configure --prefix=/usr \ --libexecdir=/usr/lib --enable-shared --enable-threads=posix \ --enable-__cxa_atexit --enable-c99 --enable-long-long \ --enable-clocale=gnu --enable-languages=c,c++ --disable-libstdcxx-pch --disable-multilib should read ../gcc-3.4.4/configure --prefix=/usr \ --libexecdir=/usr/lib --enable-shared --enable-threads=posix \ --enable-__cxa_atexit --enable-c99 --enable-long-long \ --enable-clocale=gnu --enable-languages=c,c++ --disable-libstdcxx-pch \ --disable-multilib (note the \ after the second to the last line). What does the --enable-c99 do? -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: pure64 Version 7.0-cross-lfs-20050819-x86_64 chapter 10.6
Thanx Doug. Change Made. --enable-c99 -- enable the c99 standard (ISO/IEC 9899:1999) -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: 7.0-cross-lfs-20050818-x86_64 section 10.3 glibc installation
On 8/19/05, Jim Gifford [EMAIL PROTECTED] wrote: Ken, Ryan, Doug, and others Do we need to make a change here for the pure64 build, or is further testing needed? I will be on vacation for a week, otherwise I'd run through it again carefully. But I believe I followed the book exactly to that point, and I had an ldd that listed /lib/ld-linux.so.2 and /lib64/ld-linux-x86-64.so.2, which then caused the glibc install to fail. It would get to the part where it installed /usr/bin/ldd, then use the new one, then error out. -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Version 7.0-cross-lfs-20050814-x86_64 glibc-linuxthreads missing from instructions
The instructions in 10.4. Glibc-2.3.5 64-Bit in the cross-lfs multilib x86_64 book are missing the part where you unpack the glibc-linuxthreads.tar.bz2. -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20050814-x86_64 glibc-linuxthreads missing from instructions
Doug Ronne wrote: The instructions in 10.4. Glibc-2.3.5 64-Bit in the cross-lfs multilib x86_64 book are missing the part where you unpack the glibc-linuxthreads.tar.bz2. -Doug It's there Doug right above. make -C ../glibc-2.3.5/linuxthreads/man -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20050814-x86_64 glibc-linuxthreads missing from instructions
Oops, right you are. Though shouldn't it say ignore this if you do NOT want the threading man pages? -Doug On 8/15/05, Jim Gifford [EMAIL PROTECTED] wrote: Doug Ronne wrote: The instructions in 10.4. Glibc-2.3.5 64-Bit in the cross-lfs multilib x86_64 book are missing the part where you unpack the glibc-linuxthreads.tar.bz2. -Doug It's there Doug right above. make -C ../glibc-2.3.5/linuxthreads/man -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Version 7.0-cross-lfs-20050814-x86_64 glibc-linuxthreads missing from instructions
Doug Ronne wrote these words on 08/15/05 11:19 CST: Oops, right you are. Though shouldn't it say ignore this if you do NOT want the threading man pages? Please don't top-post, and perhaps consider trimming your quoted text. Anyway, there are many things in the LFS book which folks could ignore, however, it is felt that if folks want to deviate from the book, they should be knowledgeable enough to not have to be told when and where they may deviate. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 11:33:00 up 135 days, 11:06, 3 users, load average: 0.65, 2.02, 2.27 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS 5.9. Glibc-2.3.5 (32 bit build on a 32 bit host)
On 8/13/05, Jim Gifford [EMAIL PROTECTED] wrote: Actually I found two causes for that error during my testing. 1 - --enable-languages=c,c++ will cause that error, don't understand why though 2 - When LFS_HOST and LFS_TARGET32 are the same. (Verified thanx to Matt Darcy) Ahh, yes. I did get the error building from the livecd, the second time through I was building from a 64 bit ubuntu distro, that explains why no error the second time. I wanted to say thank you to a few people who have been testing the book out. I've had an amd64 for over a year, and have been occasionally trying to get LFS to work on it, but never successfully because I don't quite know enough. So I think the thanks should go to you (and anyone else) who is making it work for me! -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS 5.9. Glibc-2.3.5 (32 bit build on a 32 bit host)
Doug, Think I found the issue, check your gcc-static build and see if you passed --enable-languages=c,c++ it should only be c. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS 5.9. Glibc-2.3.5 (32 bit build on a 32 bit host)
On 8/13/05, Jim Gifford [EMAIL PROTECTED] wrote: Doug, Think I found the issue, check your gcc-static build and see if you passed --enable-languages=c,c++ it should only be c. Not unless it was in the book (I was cutting and pasting). However, this latest time through I didn't run into the problem. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS 5.9. Glibc-2.3.5 (32 bit build on a 32 bit host)
Actually I found two causes for that error during my testing.
1 - --enable-languages=c,c++ will cause that error, don't understand why
though
2 - When LFS_HOST and LFS_TARGET32 are the same. (Verified thanx to Matt
Darcy)
I will be adding a third option to the variables page to correct the
second reason. Anyone who builds using the livecd should use
LFS_HOST=$(MACHTYPE).
People building a multilib system, on the system they are going to use
need to use
export LFS_HOST=`echo ${MACHTYPE} | sed -e 's/unknown/cross/g' -e
's/-pc-/-cross-/g'`.
I'm looking into the reason why this works, I will be adding a method 3 to the
multilib builds,
to prevent this issue in the future.
I wanted to say thank you to a few people who have been testing the book
out.
x86 and x86_64 builds
Matt Darcy
Doug Ronne
John Pierce
MIPS builds
David Cummings
Bryan Althouse
I appreciate all the feedback and support you have been giving me on
this effort.
Advisors
Ken Moffat
Ryan Oliver
Jeremy Huntwork
Archaic
Jbit
Matthew Burgess
Gerard Beckmans
Matt Darcy
Randy McMurchy
Thanx for listening my ideas on helping me with decisions, discussions,
and compile issues!!!
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Re: Cross-LFS 5.9. Glibc-2.3.5 (32 bit build on a 32 bit host)
On 8/11/05, Jim Gifford [EMAIL PROTECTED] wrote: Please give me any details you can so I can help diagnose your issue. Here are some of the questions that I use to trouble shoot these issues. What does LFS_TARGET, LFS_TARGET32, and LFS_HOST show? What is your host architecture? What is your host distro? Was there any error message with the gcc-static build? (The usual cause of this issue) Was there any problems installing the glibc-headers? (A possible cause) LFS_TARGET : x86_64-pc-linux-gnu LFS_TARGET32: i686-pc-linux-gnu LFS_HOST: i686-pc-linux-gnu No errors in the gcc static build or glibc headers install. I directly cut and pasted these sections so I don't think I made any typos. I'd have the actual output of the glibc build, except I can't reproduce it without wipeing out the work I have done, since it is not reproducible once you get the first glibc to build correctly (at least I think it built correctly) -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS - Pure 64 - Bootloaders [RFC]
On 8/10/05, Jim Gifford [EMAIL PROTECTED] wrote: Archaic wrote: LILO is reported to work for 64 bit. You don't seem to be acknowledging that since all I can see is talk of silo, colo, and grub. Actually I don't want to add any packages. I have talked to some people that have actually built grub on a 64 bit architecture. But this still lives a whole in the other 64 bit architectures. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page I haven't been able to do LFS on my tower for a while, but I know that I had grub building in 64bit on it once. I have an x86_64, and iirc, grub 0.93 didn't like 64bit, but 0.94 did. That's about the newest grub that I have used as I haven't had a chance to use linux on my tower since then for the most part. (I wish I had, but things tend to happen that cause trouble there.) Anyways, don't know if that helps at all. Going back versions maybe isn't the best idea, but it might allow you to at least keep the same bootloader. Though I never did build a pure-64 system, but I didn't have to pass -m32 to the later versions, and the grub dir was x86_64-unknown, so I think it was building 64-bit images. Andy Neebel -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross-LFS 5.9. Glibc-2.3.5 (32 bit build on a 32 bit host)
Linux From Scratch - Version 7.0-cross-lfs-20050811-x86_64 When configuring Glibc-2.3.5 for the first time , I get an error saying that it couldn't compute the sizeof a long int. The file that it failed was looking for crt1.o wich apparently doesn't appear until after you build the thing (because once I got it past this spot I couldn't reproduce the error). My fix was a complete hack. I edited the configure script and on line 7102 I changed if test $cross_compiling = yes; then to if test yes = yes; then this got it past the problem, it apparently skipped building some tests. I'm sure there is a better solution however. -Doug -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross-LFS 5.9. Glibc-2.3.5 (32 bit build on a 32 bit host)
Please give me any details you can so I can help diagnose your issue. Here are some of the questions that I use to trouble shoot these issues. What does LFS_TARGET, LFS_TARGET32, and LFS_HOST show? What is your host architecture? What is your host distro? Was there any error message with the gcc-static build? (The usual cause of this issue) Was there any problems installing the glibc-headers? (A possible cause) -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross LFS Pure 64bit Book
I have a question about the pure 64bit x86_64 bit book. During the installation of grub you use the following instruction: CC=gcc -m32 -static ./configure --prefix=/usr However because this is a pure 64bit build their are no 32 bit libraries or the capability for gcc to build 32 bit correct? Or am I missing something? -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS Pure 64bit Book
John Miller wrote: I have a question about the pure 64bit x86_64 bit book. During the installation of grub you use the following instruction: CC=gcc -m32 -static ./configure --prefix=/usr However because this is a pure 64bit build their are no 32 bit libraries or the capability for gcc to build 32 bit correct? Or am I missing something? AFAIK, for pure64 builds, lilo should be used instead of grub. -- Alexander E. Patrakov -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS Pure 64bit Book
Jim Gifford wrote: Someone has information on how to make grub work 64 bit, I hope to get that very soon. Would you like to give grub-1.90 (grub-2.0 pre-release) a try for us all? :) Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS Pure 64bit Book
Sure, I'll give it a shot. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Cross LFS - Pure 64 - Bootloaders [RFC]
I've been working on our cross-lfs build methods quite a bit lately, but have ran into some dead ends when it comes to the bootloaders for all the architectures we support. None of them will build properly on a Pure 64 bit system. The only way I see to get around this is to build some 32 bit tools and utilize the gcc -m32 for the bootloader builds. I want the communities input before I make this type of change, or if they have some other suggestions. Changes that would need to be done to Cross-LFS would be the following. /lib would be 64 bit and /lib32 would be 32 bit. x86_64, MIPS Build 32 bit glibc Build a multilib gcc Sparc64 Build 32 bit e2fsprogs libraries Build 32 bit glibc Build a multilib gcc As you probably see from my post about Grub 1.90, the new version of Grub build on a 64 Bit system, but utilizing gcc -m32. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS - Pure 64 - Bootloaders [RFC]
John Miller wrote: I have only been a lurker on the list, but since I stirred up all the trouble over bootloaders with my thread I should probably say something. I used lilo for my pure 64 bit system and it built just fine. Since sometime towards the end of 2004 lilo no longer requires nasm, so it can be a straight swap for grub. On the other hand adding 32 bit headers, a 32 bit glibc and a multilib gcc seems a lot to add for only one package. Just my two cents. I was having this problem for a while, I've been working with the Silo maintainer for a few weeks now, but there is no way to build a 64 bit silo. Colo for the raq2 MIPS and Grub, also seem to have this problem. I guess a 32 Bit loader is the unwritten law for bootloaders. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS - Pure 64 - Bootloaders [RFC]
Archaic wrote: LILO is reported to work for 64 bit. You don't seem to be acknowledging that since all I can see is talk of silo, colo, and grub. Does LILO work for sparcs and/or MIPS machines? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: Cross LFS - Pure 64 - Bootloaders [RFC]
Jeremy Huntwork wrote: Does LILO work for sparcs and/or MIPS machines? No bug Grub 2 is scheduled to support Sparc, x86, and ppc, but only as 32 bit. Currently none of the MIPS bootloaders that I'm familar with will boot a ELF64 object, arcboot and colo. -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Status Report on Cross-LFS
I have decided to start a weekly status report on the Cross-LFS development. This report will happen on Fridays. Current Working Status All 32 bit builds and Multilib builds are working. Need volunteers to test and report any issues during the build All builds need wordsmithing, so anyone who's interested you can post a message here, but in the subject please specify cross-lfs. Current Developments I am working on, as requested by the community, a 64 bit only build. I have been utilizing Ken Moffat's pure64 hint, to accomplish this. Thanx Ken!!! I hope to have this commited within the next week or so. Future Plans Getting the current GCC 3 version ready for release Create a new branch for a GCC 4 version -- -- [EMAIL PROTECTED] [EMAIL PROTECTED] LFS User # 2577 Registered Linux User # 299986 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
cross-lfs ncurses-5.4-20050319-patch.sh.bz2
In cross-lfs-20050730 ncurses-5.4-20050319-patch.sh.bz2 patch meant as added, but seems not to be used. Dzintars. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r6572 - in branches/cross-lfs/BOOK:
Randy McMurchy wrote: [snip highly technical and best as I can figure, well-reasoned analysis] Thanks, Greg. I am interested in hearing from the pro-remove-headers folks in response to your message. Hopefully, there will be continued discussion. This type of discussion is, after all, what this list is all about. This thread provides some more evidence for keeping the Glibc headers step: http://gcc.gnu.org/ml/gcc/2005-07/msg01206.html I think it should be reasonably clear by now that building without the Glibc headers is not kosher. I hope that Jim fixes the Cross docs upon his return. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r6572 - in branches/cross-lfs/BOOK:
On Die, 2005-07-26 at 09:52 +1000, Greg Schafer wrote: For the record, here is what Jim changed: [...] snipped the evidence list For the record, all of my cross research is available via mailing list postings and scripts on the DIY website. It's there for anyone to see. The anti-LFS sentiments I was experiencing at the time are evident but these are now gone thanks to the sterling efforts of Matt. Just ignore the rants and focus on the technical facts :-) Jim, the evidence is clear. Please, I urge you to do the ethical thing and acknowledge you have used my research. Do you think you're the only one able to understand some parts of cross-building a system? Your first post on diy-linux where you talk about cross compilation dates from May 27, 2005. I've committed a toolchain build instruction with gcc without-threads and without glibc-headers, -startfiles, and gcc-shared on May 3, 2005 to my experimental branch of paldo. So I could accuse you of using and not crediting my research but I don't as I know that it's likely that you did your research on your own. So please don't accuse other people of copying just because they got the same idea or did similar research. You're not the only one doing some research. BTW: I've asked Ryan why he didn't use the simpler build method and IIRC he replied that he wants to keep the compatibility with older toolchains that don't support the simpler method. Regards, Jürg -- Jürg Billeter [EMAIL PROTECTED] -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
cross-lfs
Guys, I just talked to Jim a bit ago to try and clear up the issues as of late surrounding cross-lfs, what the status in general is, etc. First off let me start to clarify that cross-lfs is not made part of LFS officially in that it is integrated with the book and goes through the regular Quality Assurance processes. True, it's in LFS' svn repository but only because it's convenient for it to be there. For all intents and purposes it might as well be running on Jim's private machines while it is being developed and turned into something usable that can be integrated with the LFS Book. I know there was a bit of an issue, if not downright an outcry, when Jim made some changes a few days ago that some of you took issue with due to the lack of notification. Maybe it would have been nice if there was some discussion and/or advance notification, but in the end that is Jim's choice. When Cross-LFS gets to a point it becomes an official LFS product (for lack of a better description right now), then things will obviously change and no changes are to be made without discussion. Then there was an issue the change made was unwise or wrong to make. You know what guys, we all make changes sometimes that are later found to be unwise. And yes, sometimes those could have been prevented with better discussion and such. But come on, there is absolutely no excuse to start attacking people on this list and accusing them of things. Sometimes you just have to do what you think is right, even if nobody seems to agree, or you know up front nobody will agree. If a change is made and it's later found that it's better to undo it, we'll undo it. It's simple enough to do. If people can't remain civil through that and feel a need to resort to accusing one another of whatever, then maybe it is time for those people to kindly unsubscribe from this list and leave the rest of us alone. As for the downright accusation that Jim stole research from somebody else and did not give proper credit: nothing was stolen. Jim said (both here on the list and to me directly when I spoke with him earlier) that he looked at research of various people and didn't end up using everything. If the path he chose is similar to somebody elses path that does not mean anything was stolen. It merely means two people might have arrived at the same conclusion of their own accord. Lastly, as for development happening on IRC. It wasn't clear to me if you guys were refering to the specific changes that were made as a result of possible IRC discussions (which would explain the lack of discussion here prior to said changes being made). If that is the case, there was no discusion on IRC either. The change was thought to be a no-brainer and was just made. If that judgement proves to be bad, just undo the changes. There is, again, simply no need to get on various high horses and start causing trouble. In general, IRC isn't used (anymore) as a replacement for mailinglists. In the past it did happen because everybody on this list contributed to make this a hostile place to be. People came to IRC to report bugs because they became afraid to be flamed or ridiculed here. I don't even blame them for doing so. Development sort of migrated to IRC too for the same reasons. I myself am against main development happening on IRC rather than on the mailing lists. For this to be changed, we as a group have to smarten up. Only then will people feel comfortable again using this medium for discussing and developing whatever it is we might be involved with at any given time. I hope this at least clears some of the issues up. If there are more questions or concerns I will be more than happy to address them. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cross-lfs
Gerard Beekmans wrote these words on 07/26/05 16:57 CST: For all intents and purposes it might as well be running on Jim's private machines while it is being developed and turned into something usable that can be integrated with the LFS Book. When Cross-LFS gets to a point it becomes an official LFS product (for lack of a better description right now), then things will obviously change and no changes are to be made without discussion. I suppose you and I will just have to disagree with the philosophy of this method of operation. Understand it is okay to disagree, disagreement fosters discussion, and providing the discussion stays civil, can only be a good thing. However, if there is a chance that the Cross-LFS stuff can/will/should/might be/whatever the official LFS product, then folks should be able to discuss things and recommend/suggest changes, starting now. The way you say things, it is up to Jim to do whatever he feels like, then later, the group can decide to implement what Jim did. I would like to think that if Cross-LFS has a chance at becoming the default build method, the group should be involved with the project from the beginning.At least that's how I see it. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 17:03:01 up 115 days, 16:36, 2 users, load average: 0.95, 0.46, 0.21 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cross-lfs
Randy McMurchy wrote: However, if there is a chance that the Cross-LFS stuff can/will/should/might be/whatever the official LFS product, then folks should be able to discuss things and recommend/suggest changes, starting now. I can see your point - public interest, ideas and discussion often lead to very good results. So if the LFS community on the whole can learn to discuss things better together we might see some good things happen. On the other hand, Jim has been working on cross-lfs publicly with result being that anyone who wants can follow his work via the lfs-book list, test the builds themselves and offer comments or suggestions. It's not like there's ever really been closed development. So on that level, I'm not really sure I'm seeing what you're finding fault with. Should Jim ask for permission to make a change on a book that only until recently he was sure was producing a sane build? Our goal up to this point was just to get the thing working. If anyone at any time wanted to know more details on why a specific change was made, they could have very easily replied to the change on lfs-book, or emailed Jim personally. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: cross-lfs
Gerard Beekmans wrote these words on 07/26/05 17:33 CST: [snip good stuff] If we want this list to return to what it used to be, we first need to brush up on our inter-personal skills. The rest will automatically follow. Well said. And I, as much as anyone, need to follow the above suggestion. :-) Off-topic for this list follows, however many active contributors to this list commented on the below, so throwing it in here. FWIW, there was some cross-words over on BLFS-Dev a day or so ago between myself and Tushar. I am not one to hold grudges, and actually like peace and harmony (sometimes difficult to maintain when you are head strong). Tush and I have made peace with our issue, as any two rational guys should be able to do after a disagreement. -- Randy rmlscsi: [GNU ld version 2.15.94.0.2 20041220] [gcc (GCC) 3.4.3] [GNU C Library stable release version 2.3.4] [Linux 2.6.10 i686] 17:37:00 up 115 days, 17:10, 2 users, load average: 0.03, 0.06, 0.22 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r6572 - in branches/cross-lfs/BOOK:
Jeremy Huntwork wrote: What evidence? Surely I don't need to point out how easy it is to determine who is accessing what and when and where from, using apache logs, ip addresses, dns, etc etc etc? Secondly you say that you made those changes in the diy cross build as a result of your research. It appears you've missed the possibility that Jim may have arrived at the same or similar conclusions based on his own research. Get a grip :-) It's a stunning coincidence don't you think? I identify and criticize some major flaws in the implementation then within weeks each one of those flaws is addressed with some wholesale build method changes the likes of which haven't been seen since the cross stuff began? I am going out to buy myself a lottery ticket :-) (As I keep on repeating, my criticisms were leveled at a time when anti-LFS sentiments were a driving force, but of course that is now not the case. However, it's apparent that anti-Greg sentiments are still rife within LFS. Hopefully the spirit of cooperation that Matt and I have been discussing will help resolve this.) Of course credit should go where credit is due, and if Jim did actually use any of your work, he should give credit. Exactly. This is a key point in this debate. Not only my work, but any other resources that have been leaned upon. LFS has a poor record in the area of acknowledgments, but thankfully the situation is improving. Hopefully this thread has heightened the awareness of ethical issues in open source for folks. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: r6572 - in branches/cross-lfs/BOOK:
Okay all, let's just drop this right here and now please. I don't want to see another (flame) war start here. Jim said he looked at your work Greg, but he didn't use it. That looking at your work bit may account for some/most of the log entries you have been seeing. The coincidental timing of the changes that were made I'm not going to go into this. I'm not saying you are lying, I am also not saying Jim is lying. Coincidences do happen. People do win the multi-million dollar lotteries. One day pigs *will* fly when we figure out how to manipulate their genes. Let's give people the benefit of the doubt. It does no good to swing about accusations on this list. If you have to accuse somebody, take it in private please before discrediting somebody and quite possibly, later down the road, have it turn out false and the damage will be done. Greg, I'll send an email private to address, as you called it, the anti-Greg sentiments. There's no need to talk about those things here. -- Gerard Beekmans /* If Linux doesn't have the solution, you have the wrong problem */ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
