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 th
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
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, ap
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 architectur
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 i
(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 i
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/p
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/li
ib="/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}%{thr
TH 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
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 con
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.
In chapter 7. If You Are Going to Boot section 7.14. Setting Up the
Environment the PATH is written but never gets overridden.
At least I can't find where it
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
s
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
Jeremy Huntwork wrote:
Perhaps, try symlinking /tools/include/stddef.h to
/tools/include/linux/stddef.h (based on
http://sources.redhat.com/ml/crossgcc/2005-09/msg00092.html ) ?
If that helps, the end of the thread hinted that other headers might
perhaps need the same treatment.
I'll give
Ken Moffat wrote:
If you are doing something unusual, it doesn't always do to trust the
error messages. Mostly, they are apt, but sometimes the cause of the
error is not what the person who wrote the message expected. I think
OSX used to give difficulties because it was, or is, case insensi
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
On Tue, 25 Oct 2005, Jeremy Huntwork wrote:
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 pa
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/posi
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"';\
ec
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
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
bec
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 no
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.
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
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 wil
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-
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
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
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
On Thu, 2005-10-20 at 11:55 +1000, Ryan Oliver wrote:
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 "sty
m
> 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
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 tests
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 th
On Sun, 16 Oct 2005, Justin R. Knierim wrote:
Attached is a patch to fix the alpha order of patches (mostly for mips).
Removed a grep patch that was listed twice on the mips patches page. svn
diff from /branches/cross-lfs/BOOK directory.
Thanks, commited in r7032.
Ken
--
das eine Mal
Attached is a patch to fix the alpha order of patches (mostly for
mips). Removed a grep patch that was listed twice on the mips patches
page. svn diff from /branches/cross-lfs/BOOK directory.
--
Justin R. Knierim
lfs at lfs dash matrix dot net
Index: materials/mips64/patches.xml
On Fri, 2005-10-14 at 14:52 -0400, Jeremy Huntwork wrote:
> 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:
> >
> > expor
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 packag
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 s
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 spec
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 b
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 y
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.linuxfromscra
> 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.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
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) add
of
books.
> 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 equ
El Sábado, 1 de Octubre de 2005 21:03, Jim Gifford escribió:
> 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
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
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.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfr
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
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,
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 prepari
Hi -
On an i686, I am trying to build a MIPS64 cross-compiler
for gcc-4.0.2 using the LFS book. This is marked as experimental -
Has anyone gotten through all of the steps?
I run into a problem near the end of the glibc build step
during the creation of libc.so because members of
libgcc are mabi=
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
Ken Moffat wrote:
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
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-
I suspect Jim and Manuel will be none too pleased to hear that I'm
running some "can it build itself" tests on Cross-LFS (inevitably, this
means chrooting rather than cross-building on a different system, and
I've noted the desire to drop chroot from Cross-LFS).
At t
-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?
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/fa
El Martes, 20 de Septiembre de 2005 19:53, Matthew Burgess escribió:
> I replied 22 minutes after Jim sent the original RFC, saying I agree
> with it in principle. Once Gerard confirms, Jim can email me in private
> and I'll set up the Subversion repository and book rendering. I don't
> have any
Jeremy Huntwork wrote:
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?
I replied 22 minutes after Jim sent the original RFC
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
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/li
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
> >
> 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 PROTEC
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.linuxfromscra
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.
That sounds like a good idea to me. +1
Justin
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe
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 ar
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 comme
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 suppo
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.
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
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
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
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,
> eventuall
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
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
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
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
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
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
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://linuxfromscra
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,
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 co
No problems Ken. But what do you think of my reasoning on the error
about the different symlink names for ld?
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.or
On Tue, 23 Aug 2005, Jim Gifford wrote:
Ken,
You may want to see what I did in the book, I've gotten several builds
working on MIPS64 and Sparc64(minus the bootloader issue.) Everything went
into /lib no problem, I think this may be an x86_64 issue only. The reason I
say this is that the ld
Ken,
You may want to see what I did in the book, I've gotten several
builds working on MIPS64 and Sparc64(minus the bootloader issue.)
Everything went into /lib no problem, I think this may be an x86_64
issue only. The reason I say this is that the ld symlink on MIPS64 and
Sparc64 are the s
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 l
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 ca
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/listi
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?
>
I haven't got into this yet, so I can only compare with my own pure64
using older versions of the toolchain (glibc-2.3.4). My ldd has
Jim Gifford wrote:
Thanx Doug. Change Made.
--enable-c99 -- enable the c99 standard (ISO/IEC 9899:1999)
Is it not enabled by default? I don't remember having any issues with
C99 features with a by-the-book GCC build.
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://
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
Ken, Ryan, Doug, and others
Do we need to make a change here for the pure64 build, or is further
testing needed?
--
--
[EMAIL PROTECTED]
[EMAIL PROTECTED]
LFS User # 2577
Registered Linux User # 299986
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscr
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 t
Thanx Justin. Applied.
--
--
[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
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 re
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
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
> t
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 t
in section 10.3 in the Pure64 book, I had to touch /etc/ld.so.conf in
order to get the compile to work (complained otherwise). Also, in the
make install section, I get the following error:
CC="gcc" /usr/bin/perl scripts/test-installation.pl /sources/glibc-build/
/usr/bin/ldd: line 167: /lib/ld-li
1 - 100 of 380 matches
Mail list logo
