I think that purity and other axioms that are put forward at the
beginning of the build process are only as valuable as the benefits
they provide later on. If purity means stability, reliability or more
fried bananas at the end of the day, that's more important than the
philosophical value of a
Hugo Bernier wrote:
On that note, the most valuable tool to build a LFS system is a good
LFS live cd. I do have some suggestions to put forward but I'm unsure
if this is the right place to put them.
There is in fact a LFS livecd project, and it has its own mailing list:
Archaic wrote:
On Thu, May 26, 2005 at 01:44:10PM -0700, Jim Gifford wrote:
What about when you build on x86 for a different platform then chroot
is not an option at all. That's the reason we added that to the book.
For that I would suggest a livecd. How exotic must we get?
Would
Jim Gifford wrote these words on 05/27/05 01:48 CST:
Would be great, but the RaQ series and few other designs don't have the
ability to boot from a cdrom.That's why I'm persuing a method that is a
little easier for people to work with on all systems. NFS root booting.
This is the future of
Archaic wrote:
For that I would suggest a livecd. How exotic must we get?
Depends on what you are building for.
All well and good if your target actually has a cdrom, and there
actually is a livecd for your target platform...
Most of my sparc32's don't have a cdrom, and neither does my
On Fri, May 27, 2005 at 05:28:29PM +1000, [EMAIL PROTECTED] wrote:
Depends on what you are building for.
All well and good if your target actually has a cdrom, and there
actually is a livecd for your target platform...
Most of my sparc32's don't have a cdrom, and neither does my arm
R.Quenett wrote these words on 05/27/05 09:15 CST:
Pardon me for butting in here but, to me in my ignorance, the one
benefit that would justify (again, to me - I'm not trying to speak
for anyone else) almost anything would be the 'purity of the build'
(which I understand to mean the new
TheOldFellow wrote:
I must start by saying that I have not been interested enough in this
thread to have read every contribution in detail.
Having built a couple of POX86S (plain old X86 system) with cross-lfs
instructions, I've decided to take a copy of the latest svn
non-cross-lfs book and
R.Quenett wrote:
Pardon me for butting in here but, to me in my ignorance, the one
benefit that would justify (again, to me - I'm not trying to speak
for anyone else) almost anything would be the 'purity of the build'
(which I understand to mean the new build containing as close to zero
as
Randy McMurchy wrote:
I asked a very similar question a while back. After pressing the
issue, the answer was that for x86 builds, you end up with the
same thing regardless which build method you use. Note, however,
this only applies to non-cross builds.
I'm sorry, I must have missed this one.
TheOldFellow wrote:
The increased
complexity of the cross-lfs method has zero benefit in x86 AFAICS.
I'm not saying that cross-lfs isn't a great bit of work, it's just that
I don't see that it has any application to 95% of folk building LFS for
the first time, and the 5% who need a cross
On Fri, May 27, 2005 at 09:52:32AM -0500, Bruce Dubbs wrote:
I would also point out that the cross build method is necessary only
once per architecture. One you have a system built on a specific
arctitecture, a user can revert to the current method for a subsequent
build. Once a user can
Jeremy Huntwork wrote:
Increased complexity? For x86 - x86, I'm not sure I see it that way.
Let's break it down a bit. In the 5.x-6.x books, chapter 5, for your
toolchain, you built gcc 4 times, right? (static build we run 'make
bootstrap' with is more or less equal to 3 builds of gcc) Now,
TheOldFellow wrote:
We often (once a year or so) have a debate in LFS circles to decide if
those who want to try experimental stuff should be in the forefront, or
whether we should be trying to get a perfect book for newbies to build
with. The answer is a compromise, always was, always will be.
Jeremy Huntwork wrote:
It would be interesting/nice to
hear Gerard's take on this issue at this time. Esp. considering that he
still holds copyright on all this stuff.
Gerard who? I think there used to be someone called Gerard around here
once, long ago...
R.
--
Archaic wrote:
On Fri, May 27, 2005 at 09:52:32AM -0500, Bruce Dubbs wrote:
I would also point out that the cross build method is necessary only
once per architecture. One you have a system built on a specific
arctitecture, a user can revert to the current method for a subsequent
build. Once
El Viernes, 27 de Mayo de 2005 16:52, Archaic escribió:
Attempts to support building where
host!=target is hints territory as there are just too many variables for
a linear based book to contend with.
That's also my point.
In resumen:
Cross-build techniques are good.
To reboot using the
M.Canales.es wrote:
In resumen:
Cross-build techniques are good.
To reboot using the temp tools is good, noticing that when
host(machine+arch)=target(machine+arch) we can to use the old chroot way, if
dessired.
To try to solve the question How can I boot my target machine when
El Viernes, 27 de Mayo de 2005 21:08, Jim Gifford escribió:
http://documents.jg555.com/cross-lfs/x86/reboot/whatnext.html,
Object not found
But reading the XML file, that look sensible to me. Thanks.
--
Manuel Canales Esparcia
Usuario de LFS nº2886: http://www.linuxfromscratch.org
Bruce Dubbs wrote:
Has it been shown that the current method has leaks from the build
system into the new LFS system? If so, I'm not aware of them. Can
you point to anything specific?
If you use a host with new binutils (2.15.x), but are building old
binutils (2.14 was what was current when
Bryan Kadzban wrote:
If you use a host with new binutils (2.15.x), but are building old
binutils (2.14 was what was current when this issue came up), then after
you install the old binutils, linking won't work anymore. gcc's specs
file uses --as-needed, because 2.15.x supported it, but the ld
Jeremy Huntwork wrote:
Thanks for the case-in-point, Byran.
Was the SE-Linux afflicted FC3 distro also because of host infection, or
was that down to incorrect instructions? Basically what was happening
was that (I think) glibc was being built in chapter 5 against the host's
se-linux
Matthew Burgess wrote:
Was the SE-Linux afflicted FC3 distro also because of host infection, or
was that down to incorrect instructions? Basically what was happening
was that (I think) glibc was being built in chapter 5 against the host's
se-linux stuff. When we were chrooted in chapter 6,
Jeremy Huntwork wrote:
Increased complexity? For x86 - x86, I'm not sure I see it that way.
You have to be kidding, right? Everyone around here has obviously
forgotten what it's like to be a newbie. I'll repeat what I've stated in
the past:
- the greatest thing about LFS is that newbies can
Archaic wrote:
In an attempt to get this info both archived, and presented to the
larger community, I am writing up a synopsis of ideas that have been
floating around on IRC as to how to handle the chroot/reboot phase of
the cross-lfs book. I will list them and give a brief pro/con for each
as I
El Jueves, 26 de Mayo de 2005 22:11, Archaic escribió:
On Thu, May 26, 2005 at 04:05:41PM -0400, Jeremy Huntwork wrote:
After spending some time on the reboot section, I think it's a mistake
to include any of that extra stuff in the book. Esp. when it still seems
that more will be taking
Jon Ringle wrote:
On Thursday 26 May 2005 16:44, Jim Gifford wrote:
What about when you build on x86 for a different platform then chroot is
not an option at all. That's the reason we added that to the book.
I am working with the cross-lfs scripts to target an arm processor from an x86
Matthew Burgess wrote:
Then the book should point you at a 'how to move target files from
host to target where target!=host' style hint. Although the cross-lfs
book is an enabler for cross-lfsing, I'm not convinced that the
majority of our readers will in actual fact be cross-building their
Jim Gifford wrote:
Matt, that was one of the purposes of the cross-lfs was the
multi-architecture build, the reboot section is needed. I have it
working and have been making the changes. It's just at the reboot point
where there seems to be an issue.
I think that's what he was saying - Keep
Jeremy Huntwork wrote:
Keep it all on the same machine, but
change the chroot to a reboot section so that you can reboot into a
kernel that supports 64-bit. Where there is need to do that all on
another machine (an entirely different arch family) you get pointed
toward a hint.
Am I
Matthew Burgess wrote these words on 05/26/05 16:46 CST:
Jeremy Huntwork wrote:
Keep it all on the same machine, but
change the chroot to a reboot section so that you can reboot into a
kernel that supports 64-bit. Where there is need to do that all on
another machine (an entirely different
On Thu, May 26, 2005 at 01:44:10PM -0700, Jim Gifford wrote:
What about when you build on x86 for a different platform then chroot
is not an option at all. That's the reason we added that to the book.
For that I would suggest a livecd. How exotic must we get?
--
Archaic
Want control,
El Sábado, 14 de Mayo de 2005 07:36, Jim Gifford escribió:
My idea is the netboot thing. Since all the bootloaders in question will
work with NFS or TFTP booting.
Could you explain that in detail?
I'm not sure but IMHO, to can boot from net the BIOS must be configured first
to allow it, and
On Sat, 14 May 2005, M.Canales.es wrote:
El Sábado, 14 de Mayo de 2005 01:42, Archaic escribió:
Lastly, IMHO the combo HOST != TARGET only is usefull in two cases:
To build a full system (with X, servers, etc...) in a fast machine that will
be later instaled in a slow machine.
Or to build
El Sábado, 14 de Mayo de 2005 15:43, Ken Moffat escribió:
I think I've got a third - machines that can run a 32-bit or a 64-bit
system (i.e. x86_64 or ppc64) that are currently running 32-bit (i686 or
ppc). It's easy enough to install current 32-bit LFS on them, upgrading
to multilib
On Sat, 14 May 2005, M.Canales.es wrote:
Don't miss the point of this thread: Is there realy some case where you must
to build the packages up to reboot in one machine (the HOST) and then to
copy that temp system to other machine (the TARGET) to build the final
system?
Ah, I misunderstood
M.Canales.es wrote:
El Sábado, 14 de Mayo de 2005 07:36, Jim Gifford escribió:
My idea is the netboot thing. Since all the bootloaders in question will
work with NFS or TFTP booting.
Could you explain that in detail?
I'm not sure but IMHO, to can boot from net the BIOS must be configured
El Sábado, 14 de Mayo de 2005 16:23, Jim Gifford escribió:
It depends on your setup, we would have to create a netboot floppy. Take
a look at http://gentoo-wiki.com/HOWTO_Gentoo_Diskless_Install
From that page:
Booting the client
Now, just boot the client. Configure the bios and the network
El Sábado, 14 de Mayo de 2005 01:42, Archaic escribió:
Ideas? Comments? Suggestion? We need your input. Multiple perspectives
ultimately make for a better book. The above is merely my perspective
and likely does not cover all aspects needed to make a good decision.
There is some aspects that
Archaic wrote:
In an attempt to get this info both archived, and presented to the
larger community, I am writing up a synopsis of ideas that have been
floating around on IRC as to how to handle the chroot/reboot phase of
the cross-lfs book. I will list them and give a brief pro/con for each
as I
40 matches
Mail list logo
