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:
http://linuxfromscratc
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 "
On 28 May 2005, you wrote in lfs.dev:
> 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:
>
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 ca
Greg Schafer wrote:
Using this as a reason for cross building is a hell of a stretch IMHO.
Once understood, the problem is minor and easily worked around. It's
simply an artifact of the way PATH is handled in the current build. More
info here
I think you entirely missed the point of Bryan's pos
Bryan Kadzban wrote:
> 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"
> b
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, gl
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 stuff
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 th
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 curren
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
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
host-machi
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 t
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
>>buil
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.
--
http://linuxfromscratch.or
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:
> 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) No
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 c
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 cr
On Fri, May 27, 2005 at 09:15:19AM -0500, 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 me
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.
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 po
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 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
on Friday, May 27, 2005 at 7:58 Archaic wrote:
[...]
" setups should be handled in hints and *not* in the book. Too many layers
" of abstraction will turn people off. What's the purpose of supporting
" more methods if it turns off the core audience of the book? I think we
" need to really con
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
Randy McMurchy wrote:
> 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 b
Matthew Burgess wrote:
That said, there is a case for perhaps moving from the current 'chroot'
approach to a 'reboot' approach as that will enable 32-bit->64-bit
cross-builds (assuming IA64/AMD64/EMT64 whatever they call it these
days). That may make the default book immediately useful to a la
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
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 o
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
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, edu
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 d
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 reading
El Jueves, 26 de Mayo de 2005 23:03, Jim Gifford escribió:
> 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.
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 i
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
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
host
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
host. I certainly can't
Jeremy Huntwork wrote:
This one, IMHO is the worst possible option to support in the book.
The others of course, too, have drawbacks, but this one is by far the
worst. I would rather see the book *only* have a chroot path than have
a tar/copy files for your new system.
In fact, the more 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 t
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 the chroot path anyway.
Exactly what I was saying..
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
On Sat, May 14, 2005 at 07:23:07AM -0700, Jim Gifford wrote:
>
> 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
That fact that it does depend on your setup, and that it requires
physical access makes this
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 netwo
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 fi
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 misund
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 s
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 t
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
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 un
On Sat, May 14, 2005 at 02:31:22AM +0200, M.Canales.es wrote:
>
> If the target host (remote or local) is a machine running linux, wy not to do
> the full construction from the begin directly at the target machine? In that
> case HOST=TARGET due that both are the target machine.
That is what I
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 tha
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 understand it.
1
54 matches
Mail list logo