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
Greg Schafer wrote:
Jeremy Huntwork wrote:
It
is a new approach compared to earlier versions of LFS in that the the
first pass of binutils and gcc we are creating cross compilers and the
chapter 5 glibc is cross compiled. It is a native build from that point
forward.
Some weeks
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:
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
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
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
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
Apologies in advance, this mail will break the threading...
Possibly our mailservers white/grey listing is playing havoc with my
lfs-dev subscription (haven't received a mail since the 22nd)
Currently following this from the mail archives
Some history for folks that weren't around.
CLFS
Rick Houkes wrote:
2008/12/21 Rick Houkes rick.hou...@gmail.com:
The new LFS SVN, since the new build methoud was introduced, I was
able to build under 64-bit. After it was finished, I decided to add
some software to it, which went fine, until I got to openldap. It uses
a Perl library as
Ryan Oliver wrote:
#
# OK, how to build yourself out ch6
#
# install linux headers
# Build glibc 32 and 64 as per cross-lfs
# Toolchain adjustment
Ryan Oliver wrote:
One final thing.
Back in the day we used to supply the following patches to gcc for the
cross-toolchain builds
Starting with 3.4.3
http://svn.cross-lfs.org/svn/repos/cross-lfs-scripts/trunk/ryan/patches/gcc-3.4.3-clean_exec_and_lib_search_paths_when_cross-1.patch
Note: 2 errors in the previous messages textfile
/host-tools should be /cross-tools in the gcc/binutils build
C'n'P error with the glibc 64 bit build (march is listed there as
i686... nuke it)
[R]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ:
Ryan Oliver wrote:
Greetings folks
In regards to previous conversations on this list and a desire to post
something that is not considered idle speculation
find attached a build recipe for creating a multilib cross-toolchain
that neither misuses -B/foo/lib nor uses the untolerably
heinous
cross-compiler build for LFS style builds
# Ryan Oliver - 20081219
#==
# Yes, toolchain is basically cross-lfs minus the cross-gcc-final, and we
# are natively building the target-native toolchain (after booting
Jeremy Huntwork wrote:
Ryan Oliver wrote:
[snip]
Just some thoughts
Ryan, thanks for the feedback. I don't have anything specific to say in
connection with any of your points yet (I guess no one else does
either), but I will be looking them over in more detail as I have a free
Greg Schafer wrote:
Ryan Oliver wrote:
LFS isn't affected by the -specs handling bug as we do not pass
-specs=/some/specfile on the gcc command line
??? Not affected? LFS doesn't have the clean split between the 2 phases
like DIY does. I can simply wipe the chroot phase files
Greg Schafer wrote:
Ryan Oliver wrote:
LFS not affected in regards to the fact we can set any of
md_startfile_prefix{,_1} or startfile_prefix_spec in the specs file and
have it work because we DO use a standard specs file in the appropriate
place.
I'll restate in clear terms
Bryan Kadzban wrote:
echo slibdir=/lib64 configparms
before building (not sure why).
If you dont put that in it places all the output from the glibc build
into /usr/lib64
Best Regards
[R]
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Ryan Oliver wrote:
STARTFILE_PREFIX_SPEC is unpalatable to some for whatever reason, yet it
still exists in the gcc code to provide the only mechanism to override
the search path used for finding startfiles when cross-compiling (see
gcc.c line 6332, read the code and comments)
You should
Jeremy Huntwork wrote:
...Mostly.
With revision 8755, the new build method from DIY is in place with the
exception of support for multilib. (More on that in a second.)
I tried to make as many textual changes as I could to keep the accuracy
of the book on a high level, but I'm sure I
On Mon, 2006-02-06 at 18:43 -0700, Archaic wrote:
On Mon, Feb 06, 2006 at 07:26:15PM -0500, Jeremy Huntwork wrote:
Comments?
My comment is let's just build it right instead of relying on a make
target that builds gcc 3 times. If the wrong includes and libs are being
used, why can't we
On Tue, 2006-02-07 at 15:41 +1100, Greg Schafer wrote:
Jeremy Huntwork wrote:
In talking with Ryan Oliver, there seems to be one final thing that we
can do to our current build which will help stabilize it completely: add
'make bootstrap' to the gcc build of chapter 6.
Hm
On Tue, 2006-02-07 at 00:24 -0500, Jeremy Huntwork wrote:
Greg Schafer wrote:
Hm, this means you effectively end up building GCC 7 times, 3 times in
GCC-Pass1, 1 time in GCC-Pass2 and 3 times Ch6 GCC. It also means you end
This just made me think of something else, a mere side
On Sun, 2006-01-29 at 19:25 -0600, Randy McMurchy wrote:
I was just hoping that there could be a good discussion. And when
someone (especially one of Greg's stature in the toolchain foodchain
ladder) says something is bad, and gives what sounds like good reasons
(I am not qualified to agree
On Sat, 2006-01-28 at 13:07 +1100, Greg Schafer wrote:
Jeremy Huntwork wrote:
Isn't using -B to find libraries an abuse as well?
Huh? Using a documented switch for a documented purpose?
RTFM :-)
The purpose of the -B flag is to override GCC_EXEC_PREFIX, the path the
gcc driver uses to
On Sat, 2006-01-28 at 08:32 -0800, Dan Nicholson wrote:
On 1/27/06, Greg Schafer [EMAIL PROTECTED] wrote:
Ever looked at a build log of GCC itself? Guess what? -B.
/tools/src/build/gcc-build/gcc/xgcc -B/tools/src/build/gcc-build/gcc/
-B/usr/i686-pc-linux-gnu/bin/
On Sat, 2006-01-28 at 14:36 -0800, Dan Nicholson wrote:
On 1/27/06, Jeremy Huntwork [EMAIL PROTECTED] wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353
Our longtime Toolchain Maintainer, Ryan Oliver, still prefers to use
this method.
Um, the decision might be made for us
On Tue, 2005-11-22 at 20:47 +, Matthew Burgess wrote:
Tushar Teredesai wrote:
There is no advantage of hard-coding the UID/GID. (Just as there is no
advantage to hard-coding /tools into the LFS book but allowing users
to change $LFS but that is another topic).
Well, there's one
On Tue, 2005-11-22 at 20:54 +, Matthew Burgess wrote:
Jim Gifford wrote:
Now we need to re-evaluate the UID/GID's. We are going to need some
changes for the GID's for udev.
Why?
I'm basing this off of Kay Sievers work, with Debian and OpenSuse. This
will elminate and change
On Tue, 2005-11-22 at 13:15 -0800, Jim Gifford wrote:
Matt,
I should also mention Ryan is working on a way for us to santize our
own headers.
Don't dob me in yet ;-)
It can be done but man its a fair amount of work...
If worst comes to worst and llh doesn't release in a timely fashion
On Tue, 2005-11-22 at 21:14 +, Matthew Burgess wrote:
Jeremy Huntwork wrote:
1) Are those specific headers for that version necessary? Wouldn't
the
current ones work?
Well, they work for me (I've been running 2.6.14 for a while now).
However, I'd imagine that if the kernel gets a
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
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
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
On Mon, 2005-07-25 at 00:24 -0500, Tushar Teredesai wrote:
SNIP
That said, for a by-the-book LFS + BLFS installation it doesn't make
much sense to have multiple directories since there is only one
version of automake installed. That is the reason I symlink them on my
system.
Heh, same here,
On Tue, 2005-07-26 at 13:31 +0100, Ken Moffat wrote:
I've definitely got a strangeness in my current build scripts for
pure64 x86_64 from i686. First time I built it, running make check on
target glibc hung in inet tests. Looking at it, I discovered I had
omitted the fix_test patch.
On Wed, 2005-07-20 at 09:15 +0200, Jens Olav Nygaard wrote:
Since the subject became increasingly inaccurate, and since my
rate of hickups to installed packages indicates that this will
not be my last question, I swap in another thread...
Now reading the book more carefully, I notice that
Matthew Burgess wrote:
Jim Gifford wrote:
Matt, Jeremy, and LFS-Dev,
What are you feelings on cross-lfs moving to GCC 4.x?
There's already a gcc4 branch, but it's not seen any commits yet.
It's
now become outdated with regard to trunk. I'll wait for gcc-4.0.1 to
come out (they're just
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
Matthew Burgess wrote:
Folks,
I'm proposing we stop tracking/using HJL's binutils. Here's my
reasons:
1) It adds host dependencies of bison and flex
2) Recent bugs with HJL (stripping libc.a) have been hard to diagnose
and fix
3) FSF recently released 2.16, bringing it back up to speed
Ryan,
In the cross-tools section do we need to build 32 bit tools, or is
just building the 64 bit ones do the trick?
For a bi-arch/tri-arch toolchain, you need glibc built for each ABI,
so you can cross-build the /tools target native bi/tri-arch toolchain.
For the rest of the stuff going
Erik-Jan wrote:
Yo Erik-Jan :-) Good to hear from you again ;-)
SNIP
As you can see, in the first case it uses libgcc_s.so from the host,
in
the second case it uses the newly build libgcc_s.so.
Good catch... guess I really should do some more host=target builds
from ix86... Will check
Michael Kipper wrote:
Is there a centralized location (SVN branch, website, mailing list,
etc) with up to date information on building LFS for AMD64?
I'm having problems, and would like to see how others have done it
before I pepper you all with questions.
Best bet (until it gets folded
Greetings all,
Most here minor cleanups
4.5. Creating the $HOME/cross-tools Directory
Remove Last para ie:
The created symlink enables the toolchain to be compiled so that it
always refers to /cross-tools , meaning that the compiler, assembler,
and linker will work both in this chapter and this
Archaic wrote:
On Tue, Apr 19, 2005 at 08:23:03PM +0200, M.Canales.es wrote:
Another one: when you reboot you're alone. No mail, no web, no IRC,
no
possibility to ask for help if something go bad while building the
new
system.
IMO, his is a red-herring argument if the ability to chroot
TheOldFellow wrote:
SNIP
This separation means that there is no need to edit the specfiles or
interfere with the normal operation of the linker (as is done in the
current Pure-LFS derived LFS).
This is not entirely correct, we still need to edit the specs in
what was ch6 during the lock-in
Ken Moffat wrote:
nfs-utils ? (all my source is on an nfs mount).
Heh, I build portmap, tcp-wrappers and nfs-utils
(all my source and homedirs are nfs mounts)
Cross-compiling is a very educational experience, for those few who
manage to complete it (I've cross-compiled kernels,
[EMAIL PROTECTED] wrote these words on 04/18/05 21:55 CST:
Please folks, have a bit of a think about how things actually
work,
or actually take a look at how it hangs together, before going off
the deep end
Nobody's gone off the deep end, Ryan. We're just asking questions.
The LFS
49 matches
Mail list logo
