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
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 comme
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
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 ph
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
>>
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.o
. also attached the glibc-2.9-libgcc_eh patch used within (more for
clfs folks reading, you guys copy libgcc.a)
# Greetings folks
# Here is something that may interest you
#
# Ryan Oliver - 20081219
#
#
# Sysroot
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: http://www.linuxfromscratch.org/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 untolerabl
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
# an
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
Rick Houkes wrote:
> 2008/12/21 Rick Houkes :
>
>> 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 part of its
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 ba
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 b
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
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
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
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 senio
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.
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.
>>
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
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 u
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/ -B/usr/i686-pc-linux
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
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 ag
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 ca
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&#
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
Steve Crosby wrote:
>For the LFS build - is there a recommendation about building LFS from
>Linux
>or Solaris?
MUCH easier from linux ;-)
There is this little matter of no ext2 write support under solaris...
(genext2fs may help out here... I haven't got that far yet)
>Just looking for some
Greetings all,
I finally got around to overhauling the cross-lfs script framework,
and the scripts have been updated to (mostly) handle current lfs testing
packages
Latest version is 3.1.1
As usual, they're available under
http://www.linuxfromscratch.org/~ryan/scripts/cross-lfs
for the masochist
Archaic wrote:
>
>On Wed, Mar 30, 2005 at 04:55:18PM -0600, Randy McMurchy wrote:
>>
>> I mentioned this same thing at the beginning of this month. I
>> have several systems running current SVN versions of LFS without
>> any issues I can think of.
>
>FWIW, I have installed (and used constantly
Randy McMurchy wrote:
>[EMAIL PROTECTED] wrote these words on 03/31/05 00:34 CST:
>
>> linux-pam 0.77 ( 0.78 barfed )
>
>I would be interested in knowing what exactly went wrong with the
>Linux-PAM-0.78 installation.
Yeah, me too... didn't have time to debug at the time...
Quite possibly due
TheOldFellow wrote:
>Jeremy Utley wrote:
>> TheOldFellow wrote:
>>
>>
>>>Yes, my intention was to show some alternatives and provoke a
>dicussion.
>
>> If you like examining scripts for ideas, try taking a look at
>these:
>>
>> svn co svn://be-linux.org/cross-lfs/cross-lfs/trunk cross-lfs
>
>J
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, cross-comp
>[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.
>Th
>TheOldFellow wrote:
Kick ass :-)
Thanks for doing this (I never seem to get around to doing doco)
This looks like a damn fine template to work from
Anyway
>
>4.Now we build the cross compiler gcc by passing the configure
>option
>--host and --target.
>
>+++
>I don't understand all the
TheOldFellow wrote:
>
>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"
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
Jeremy Utley wrote:
>Just for a heads up to the rest of the community. Since one of the
>goals of the new cross-lfs stuff is to make a useable 64-bit build
>of
>LFS, and since I have a AMD64 machine with LOTS of empty hard drive
>space, I'm working on setting up partitions with each of the ma
Greg Schafer wrote:
> Jim Gifford wrote:
>
>
>>For the 7.x release we are planning to release a cross compiled
>>multi-architecture book. The build process will allow you to build for
>>any architecture to any other architecture. So you will be able to build
>>a PowerPC starter system on a Pentium
Greetings all
Quick fixup required, be it a patch or sed...
Somewhere along the way I managed to forget to add the edit to
NATIVE_SYSTEM_HEADER_DIR in gcc/makefile.in .
edit is
sed -i '[EMAIL PROTECTED](^NATIVE_SYSTEM_HEADER_DIR =\)[EMAIL PROTECTED]
/tools/[EMAIL PROTECTED]' \
gcc/Makefil
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
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 fold
Erik-Jan wrote:
Yo Erik-Jan :-) Good to hear from you again ;-)
>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 what
oat-linux-gnu/3.4.3/../../../../armv4l-softfloat-linux-gnu/lib/
/tgt-tools/lib/armv4l-softfloat-linux-gnu/3.4.3/
/tgt-tools/lib/
Regards
[R]
Submitted by: Ryan Oliver <[EMAIL PROTECTED]>
Date: 20050502
Description:
Removes standard_exec_prefix_2 from library search path when cross-compiling
ie
Jeremy Huntwork wrote:
>
>Therefore, the question comes up, how do we get the cross-compiled
>tools over to the target machine and set up the user to finish the
>remaining book? To date, I think the suggested method has been to tar
>up the tools and kernel, and copy them over, *somehow*.
Heh
> Just to say im not sure where your going but i hope to
> have each compilier stored away for emulation, could be handy for lfs >
users,
Each compiler? Just do a multilib build, you only need one...
Will release a new cross-lfs within the next 2 days or so, looks good
so far for bi-arch x86
Jeremy Huntwork wrote:
If multilib, are we creating a /lib64 and keeping /lib 32-bit,
or will it be /lib32 and /lib as 64-bit? Should we allow the user to
decide which of these options or paths to take and support all decisions?
Best stay /lib /lib64, trust me...
I'm still working on hackery for
[EMAIL PROTECTED] wrote:
Ryan,
I used your 3.1.1 cross-lfs scripts to build nice multiarch x86_64 system.
Had a couple of minor errors that were fixed once booted in native system.
heh, you'll get that ;-)
Some may already be fixed, a fair bit has changed since the 3.1.1
tarball...
One real problem
> I have the same board, but I had problems with suse, distro of choice and
fc
> but I think it was two. I'll download gentoo or fc3 tomorrow and try it
> again. Probably gentoo, ive been wanting to try it anyway, and never
have.
> But do I need the cross tools or can I just follow the svn ver
>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 g
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
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:
>
>Matt, Jeremy, and LFS-Dev,
>
> What are you feelings on cross-lfs moving to GCC 4.x?
>
> Or do you want to continue the testing with 3.4.4, then after
>that's
>completly stablized, then move to
> GCC 4.x?
>
> I've looked at what Ryan has done, not to many things to
>chang
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 (the
[EMAIL PROTECTED] wrote: -
>To: LFS Developers Mailinglist
>From: Jeremy Huntwork
>Sent by: [EMAIL PROTECTED]
>Date: 06/17/2005 07:34AM
>Subject: Re: Cross-LFS build method
>
>Archaic wrote:
>> On Thu, Jun 16, 2005 at 11:19:14PM +0200, M.Canales.es wrote:
>>
>>>In that case, that is the
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 tha
On Tue, 2005-07-26 at 11:54 +0200, Jürg Billeter wrote:
> BTW: I've asked Ryan why he didn't use the simpler build method and IIRC
> he replied that he wants to keep the compatibility with older toolchains
> that don't support the simpler method.
True, but it is a moot point for lfs which will o
On Mon, 2005-07-25 at 00:24 -0500, Tushar Teredesai wrote:
> 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, th
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. App
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
On Thu, 2005-10-13 at 16:57 +0100, Ken Moffat wrote:
> But for the moment I'm stuckin conventional multilib at the temporary
> gcc (32-bit libgcc_s.so overwriting the 64-bit, no doubt I broke
> something in my scripts earlier). So, for the moment, anybody who wants
> to install into /lib (64
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:
> >
> > export BUILD32="-mabi=32"
> > export BUILD64="-mabi=64"
>
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 i
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
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'
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
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 fash
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 kern
On Sun, 2005-11-27 at 23:39 -0600, Tushar Teredesai wrote:
> On 11/25/05, Gerard Beekmans <[EMAIL PROTECTED]> wrote:
> >
> > 1) I consider them part of a well rounded development system.
>
> They are only required by pacakge maintainers and I doubt there are
> many who LFSers who need to use these
On Thu, 2005-12-15 at 19:32 -0500, Jeremy Huntwork wrote:
> Also, as I mentioned earlier in this thread, talking with Ryan set me on
> a little bit of a purity path. One thing he suggested, however, which
> I'm finding hard to put faith in at this point. He mentioned the purity
> of the build is s
On Thu, 2006-01-05 at 19:43 -0500, Joel Miller (RIT Student) wrote:
> Having read this list for a long time, I too would like to see lfs-hackers
> reinstated where stuff can be thrown about and tested so that it can be
> refined before it is brought to this list where the tough questions of
> ge
On Thu, 2006-01-05 at 18:20 -0700, Archaic wrote:
> On Fri, Jan 06, 2006 at 12:11:06PM +1100, Ryan Oliver wrote:
> >
> > +1, it should never have been removed.
>
> I just don't understand why development shouldn't happen on a
> development list? Why shouldn&#x
74 matches
Mail list logo
