Jim Gifford wrote:
Again Greg provide us more information about the ICA, it seems to be
your own creation?
1. Read this post from Dan Nicholson:
http://article.gmane.org/gmane.linux.lfs.devel/8120
2. Look at the comments in the gsbuild scripts from DIY
3. Look at the jhalfs
Matthew Burgess wrote:
In which case, all I can suggest is you follow the process yourself:
1) Compile CLFS from a non-CLFS host
2) Use the newly built CLFS to build a second CLFS system (obviously using
exactly the same commands and package versions)
No, that's not quite right. The second
Greg Schafer wrote:
Jim Gifford wrote:
Again Greg provide us more information about the ICA, it seems to be
your own creation?
1. Read this post from Dan Nicholson:
http://article.gmane.org/gmane.linux.lfs.devel/8120
2. Look at the comments in the gsbuild scripts from DIY
Greg Schafer wrote:
Ryan Oliver wrote:
We all know what sysroot is for.
All sysroot does is shift the search paths underneath the sysroot, no
more, no less.
Well, yes. But Sysroot is specifically for *root* file systems. Here's
another data point from the GCC man/info/web docs:
On Mon, Jan 19, 2009 at 12:29 AM, Jim Gifford c...@jg555.com wrote:
Greg Schafer wrote:
Jim Gifford wrote:
Again Greg provide us more information about the ICA, it seems to be
your own creation?
1. Read this post from Dan Nicholson:
Dan Nicholson wrote:
How is it hearsay? Plenty of people (Greg, myself, Jeremy, Manuel,
Matthew, etc.) here have used this analysis to identify issues in the
build. The current ordering of the packages in LFS was determined
almost entirely through use of ICA.
Why aren't any of the big
On Mon, Jan 19, 2009 at 12:13 PM, Jim Gifford c...@jg555.com wrote:
Dan Nicholson wrote:
How is it hearsay? Plenty of people (Greg, myself, Jeremy, Manuel,
Matthew, etc.) here have used this analysis to identify issues in the
build. The current ordering of the packages in LFS was determined
Ryan Oliver wrote:
Don't mix up explanation with example.
This merely re-enforces the point I made above.
What? That you're using sysroot incorrectly?
FHS standard under the _logical root directory_ is not implied.
Huh? It's written in black and white. You're ignoring reality.
Exactly
Greg Schafer wrote:
Ryan Oliver wrote:
Don't mix up explanation with example.
This merely re-enforces the point I made above.
What? That you're using sysroot incorrectly?
No, that a sysroot is merely a target sytem root and cares not for what
is under a target system root.
Greg Schafer wrote:
Sidenote: Now that some toolchain devs are apparently using *native*
sysroot builds, there is a temptation to pursue a whole new build method
that bypasses most of Ch 5. However, we would most certainly lose a lot of
the advantages of the current 2-phase approach, so gut
Greg Schafer wrote:
Ryan Oliver wrote:
The sysroot build is misused in pretty much the same way the original
native plfs toolchain was misused.
Just another data point for the record.
Here, a senior toolchain person confirms how sysroot is meant to be used
(read the whole bug
Ryan Oliver wrote:
We all know what sysroot is for.
All sysroot does is shift the search paths underneath the sysroot, no
more, no less.
Well, yes. But Sysroot is specifically for *root* file systems. Here's
another data point from the GCC man/info/web docs:
--sysroot=dir
Use dir as
Greg Schafer wrote:
I've already said the CLFS Sysroot build is closest in spirit to how
sysroot is meant to work. But
1) it's cross compilation and therefore useless as a mainstream build
2) it fails ICA verification dismally
Regards
Greg
Again Greg provide us more information
On Sun, 18 Jan 2009 14:28:15 -0800, Jim Gifford c...@jg555.com wrote:
Greg Schafer wrote:
I've already said the CLFS Sysroot build is closest in spirit to how
sysroot is meant to work. But
1) it's cross compilation and therefore useless as a mainstream build
2) it fails ICA verification
Matthew Burgess wrote:
Jim,
What is it, exactly, you're after? Not wishing to patronize, but ICA
is just the process of compiling LFS from an LFS host and comparing
the binaries on the LFS host and the newly built LFS-from-LFS system.
There's obviously some differences that can be excluded
On Sun, 18 Jan 2009 15:19:22 -0800, Jim Gifford c...@jg555.com wrote:
I just want to see these test results and run the tests myself to see
what this is all about. I don't use jhalfs, and neither does most of
the people who work on CLFS.
I can't take one individuals word on things, because
Jim Gifford wrote:
I can't take one individuals word on things, because frankly I don't
trust some I can't validate myself.
Trust has very little to do with it, but I agree. Any scientific investigation
has to provide enough details to be able to duplicate the results. To do this,
we have
Ryan Oliver wrote:
The sysroot build is misused in pretty much the same way the original
native plfs toolchain was misused.
Just another data point for the record.
Here, a senior toolchain person confirms how sysroot is meant to be used
(read the whole bug report for context):
Greg Schafer wrote:
Ryan Oliver wrote:
It would take 5 minutes to generate a simple patch to do this (even by
Yep, of course. But even blind Freddie can see it won't be accepted by
upstream. Feel free to try.
Very quick patch attached.
Patch is there for you to have a play
Ryan Oliver wrote:
Very quick patch attached.
Patch is there for you to have a play around with as a starting point...
(for upstream they may want lib_str to be
#define static const char lib_str[] { DIR_SEPARATOR, lib,
DIR_SEPARATOR, 0 }
somewhere at the top of gcc.c, possibly with lib
Ryan Oliver wrote:
Except you then are placing tools compiled and linked against the host
in the directory that is supposed to be clean.
Huh? I'm grouping *temporary* tools together in the one dir. It's not the
dir that's supposed to be clean. It's the build method.
You unnecessarily
Greg Schafer wrote:
Ryan Oliver wrote:
Except you then are placing tools compiled and linked against the host
in the directory that is supposed to be clean.
Huh? I'm grouping *temporary* tools together in the one dir. It's not the
dir that's supposed to be clean. It's the build
Ryan Oliver wrote:
No, I solve problems for which you have not catered for yet.
CLFS deals with building from non-linux hosts.
Off topic
Isn't your supposed goal technical perfection that us mere LFS mortals
can only aspire to?
Not at all. Get the job done as quickly and efficiently as
Ryan Oliver wrote:
Greg Schafer wrote:
Hopefully, there are others like me that do not mind this
banter between Ryan and Greg. I don't look at it as arguing,
or trying to one-up each other. It is simply their way of
expressing their own ideas. I like it. And I'm learning from
it.
If you feel
Randy McMurchy wrote:
Ryan Oliver wrote:
There is technical information being passed. Simply look
at what is being said, and don't worry how it is being
said.
Let's say that you decided to eat at my restaurant. You sit down and
order some food. After some time, I return and slam down onto
Randy McMurchy wrote:
Ryan Oliver wrote:
Greg Schafer wrote:
Hopefully, there are others like me that do not mind this
banter between Ryan and Greg. I don't look at it as arguing,
or trying to one-up each other. It is simply their way of
expressing their own ideas. I like it. And
Jeremy Huntwork wrote:
I have been adapting Ryan's methods to LFS because I think that there
are certain improvements over what is currently in trunk. Specifically:
A quick glance shows you are bringing in one of CLFS's ugliest design
faults - the bizarre `/cross-tools' prefix. Let me
Greg Schafer wrote:
Jeremy Huntwork wrote:
I have been adapting Ryan's methods to LFS because I think that there
are certain improvements over what is currently in trunk. Specifically:
A quick glance shows you are bringing in one of CLFS's ugliest design
faults - the bizarre
Greg Schafer wrote:
By installing stuff into different prefixes, you are forced to butcher the
GCC source to coax it into searching the right places. Why? Because many
of the toolchain search paths are keyed off of $prefix. There is much less
hackery involved if you install into a single
Jeremy Huntwork wrote:
As far as 'butchering the source' goes, there's nothing done in the
first pass of GCC to the source that isn't done in pass 2. Essentially
it's the same sort of stuff we've _always_ done in pass 2 to ensure that
the compiler uses only the libs and headers in /tools.
Ryan Oliver wrote:
Incorrect. The initial point of installing into a separate directory
And this is documented where? Another CLFS strong point!
Dude, you can blather on all you like. But none of your rhetoric can hide
the fact your builds are as ugly as sin and incomprehensible by mere
Greg Schafer wrote:
Ryan Oliver wrote:
Incorrect. The initial point of installing into a separate directory
And this is documented where? Another CLFS strong point!
Dude, you can blather on all you like. But none of your rhetoric can hide
the fact your builds are as ugly as sin
Greg Schafer wrote:
Sorry, you're wrong and clearly not getting it. Meanwhile, it's apparent
you've turned into a Ryan nut hugger, just like the rest of the CLFS
crowd. God help LFS!
I honestly don't care anymore. LFS is a project without direction, without
leadership and apparently has
I have been using a modified LFS (built for 32/64bit at the same time)
and it worked well until the latest changes were introduced to trunk
(that use the -B flag). Specifically GCC pass2 does not find crt0.o
32bit (just see's the 64bit). I was curious if this is what the
buildsystem that 7.0 is
Nathan Coulson wrote:
I have been using a modified LFS (built for 32/64bit at the same time)
and it worked well until the latest changes were introduced to trunk
(that use the -B flag). Specifically GCC pass2 does not find crt0.o
32bit (just see's the 64bit). I was curious if this is what
On Mon, Jan 12, 2009 at 3:20 PM, Jeremy Huntwork
jhuntw...@linuxfromscratch.org wrote:
Nathan Coulson wrote:
I have been using a modified LFS (built for 32/64bit at the same time)
and it worked well until the latest changes were introduced to trunk
(that use the -B flag). Specifically GCC
Nathan Coulson wrote:
BTW, one thought that I've been having in my setup, is using /usr/lib
for 64bit, and /usr/lib/32 for 32bit [and /usr/lib/32/bin for
things like ncurses-config].
Interesting idea, but (as you note) it isn't standardized. This means
your dynamic linker will not be in the
37 matches
Mail list logo
