On Jan 16, 2012, at 1:54 PM, Bruce Dubbs wrote:
> /dev/root / ext3 rw,relatime,errors=continue,barrier=0
Interesting. I wonder if this is a side effect my using an initramfs. I assume
you have a monolithic kernel and you are using root= on the grub boot line?
JH
--
http://linuxf
On 2/3/12 2:02 AM, Bruce Dubbs wrote:
> and all 18 lines of output in boot.log are done in 3 seconds. Since
> udev is started at 1.08 seconds, that's 4 seconds to the login prompt
> form the grub selection.
Yep, I am experiencing the same with LightCube OS. About 4 seconds to
login prompt, incl
On 2/4/12 4:41 PM, Bruce Dubbs wrote:
> Increased or decreased? How much?
Sorry, yes, decreased.
Hmm, but with already minimal systems like ours, apparently not enough
to really matter. I hadn't accurately measured the difference between
bash and dash on the bootscripts until you asked but I d
On 2/4/12 7:04 PM, Bruce Dubbs wrote:
> In other words, whether it's bash or dash or ash, the shell program is
> only read in from disk once for all the bootscripts. The only other
> difference is the time it takes to actually run the scripts. For our
> scripts that are generally about 5-10 state
On 2/4/12 8:04 PM, Bruce Dubbs wrote:
> If you know of any issues it the current scripts, let me know.
Off the top of my head, the use of 'echo -e' and 'echo -n' is not
handled the same in every shell. Switching those to printf "...\n" and
printf "..." respectively is more universal.
In my scri
On 2/4/12 8:59 PM, Bruce Dubbs wrote:
> rc.site uses $() in two places. I don't think that's portable.
Actually, I believe that is fine. See:
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_06_03
> To be honest, I'm not sure I want to restrict the scripts to a
> l
On 2/4/12 9:21 PM, Jeremy Huntwork wrote:
> If you choose not to make the changes, then it's probably better to at
> least specify /bin/bash in the scripts, instead of pretending like
> they're portable via /bin/sh.
Ugh, I seem to have a knack for expressing myself badly - I r
Was just reviewing your kmod build instructions - haven't built it yet
myself, but it's noticeably missing lsmod - shouldn't this be another
symlink to kmod?
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above informati
On 2/7/12 12:21 AM, Bryan Kadzban wrote:
> Um, it's not missing. It's not in this list, correct:
>
>> for target in depmod insmod modinfo modprobe rmmod; do
>>ln -sv ../bin/kmod /sbin/$target
>> done
>
> But it is here, one line below:
>
>> ln -sv kmod /bin/lsmod
>
> :-)
Oh, odd. I totally mi
On 2/7/12 12:38 AM, Bruce Dubbs wrote:
> lsmod is in /bin. The rest in /sbin.
Wow, really need to get my eyes checked. OK, thanks.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
Hello,
I believe the cross patch in gcc pass1 is unnecessary. It does hail from
upstream where it seems they accepted the bit about having the option to
disable target libiberty, if required, but I don't believe they accepted
the zlib part, see: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47836
On 2/25/12 2:40 PM, Matt Burgess wrote:
> Hi Jeremy,
>
> Andy hit issues that were discussed in the thread starting at
> http://www.linuxfromscratch.org/pipermail/lfs-dev/2011-March/064617.html
Thanks for digging up that thread, I was having trouble tracking it
down. I'll read it over too.
JH
-
I've revised a local copy of the latest book to include some build
adjustments. The original concept was suggested on this list a couple
years ago by Ryan Oliver. I've been using it and adjusting it for the
past couple of years. It's how LightCube OS was bootstrapped.
The main differences (I'll ou
On 2/27/12 11:10 PM, Bryan Kadzban wrote:
> https://docs.google.com/viewer?a=v&q=cache:ms_KKFndiCkJ:www.x86-64.org/documentation/abi.pdf+linux+abi+64-bit+x86&hl=en&gl=us&pid=bl&srcid=ADGEEShHjrdWF0azVfQCEu-s8nYZAzhXt5X9e2WZeIC7fqrwtyLFFUztVtpzfZo3ucJZB49pJHfDqqZL90ngzTG4BBheeJgy22Dj8RY9P0AjWbbKcXPz
On 2/27/12 11:25 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>
>> I'd like to commit this to trunk, but I want to hear opinions first.
>
> Whoa. We've released lfs-7.1-rc1 and need to keep svn in sync until the
> 7.1 release is made.
Yeah, this can wait u
On 2/27/12 11:31 PM, Jeremy Huntwork wrote:
> On 2/27/12 11:10 PM, Bryan Kadzban wrote:
>> https://docs.google.com/viewer?a=v&q=cache:ms_KKFndiCkJ:www.x86-64.org/documentation/abi.pdf+linux+abi+64-bit+x86&hl=en&gl=us&pid=bl&
On 2/28/12 2:10 AM, Greg Schafer wrote:
> BTW, you might want to check your facts re the newlib switch. This
> sentence is clearly wrong:
>
> "This enables a very small standard C library that is included with GCC."
Indeed. newlib isn't shipped with GCC, the switch appears to just prep
GCC to exp
On 2/28/12 2:10 AM, Greg Schafer wrote:
> IMHO
> sysroot is fine for real cross compilation
> sysroot not fine for hybrid cross/native scenarios a'la current LFS
When you discussed the situation requiring the startfiles revert patch
with upstream they reviewed DIY's build process. Their answer, s
On 2/28/12 3:34 AM, Qrux wrote:
>
> Holy cow--this is for 7.1? Could this be tabled until 8, given the scope of
> the changes?
It's not for 7.1. There needs to be testing and acceptance first before
it gets pushed to trunk.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http
On 2/28/12 8:41 AM, Jeremy Huntwork wrote:
> Indeed. newlib isn't shipped with GCC, the switch appears to just prep
> GCC to expect the functions newlib has. When Ryan first suggested this
> one, he may have intended it to force inhibit_libc variable to be true
> as per http://
On 2/28/12 9:11 AM, Jeremy Huntwork wrote:
> On 2/28/12 2:10 AM, Greg Schafer wrote:
>> IMHO
>> sysroot is fine for real cross compilation
>> sysroot not fine for hybrid cross/native scenarios a'la current LFS
>
> When you discussed the situation requiring th
On 2/28/12 10:58 AM, Andrew Benton wrote:
> On Mon, 27 Feb 2012 23:31:26 -0500
> Jeremy Huntwork wrote:
>
>> I'll revert the 64-bit stuff and regen the diff.
>
> Sigh...
I know... my experience is like yours, that it does work in practice,
and it just feels simpler and
On 2/28/12 11:10 AM, Matt Burgess wrote:
> It's a shame that configure switch is so-called. It sounds from your
> description as if it really should be called '--without-libc' or
> something similar, as it doesn't actually try to determine/use newlib.
Agreed. I almost prefer modifying gcc/Makefil
On 2/27/12 11:10 PM, Bryan Kadzban wrote:
> The 64-bit x86 SysV ABI *REQUIRES* /lib64/ld-linux-x86-64.so.2 to be the
> runtime linker path. (This is a far more fundamental standard than LSB,
> as well.) See the (google-docs-import-from-PDF) version of the ABI
> standard:
>
> https://docs.google.c
On 2/28/12 10:42 AM, Andrew Benton wrote:
> Multilib is only of use if you want to run legacy binaries such as
> windows programs with wine.
Building Xen from source also required a 32bit libc, presumably for
supporting 32-bit hosts, although I didn't dig very far to determine why
specifically.
On 2/28/12 11:43 AM, Bruce Dubbs wrote:
> I agree that it looks funny. Also, I use an Intel 64 bit system, not
> AMD. What should it be for me?
>
> That said, I think /lib64/ld-linux-x86-64.so.2 is hard coded into
> binutils and changing that would have unknown consequences.
Anything hard coded
On 2/29/12 8:21 PM, Qrux wrote:
>> It was me that put that in the BLFS page. Thanks for your email to BLFS
>> dev about the problem with Bind.
>
> Why did we go in this circle?
Because he was kindly answering your questions.
You've been operating on a misunderstanding. There's nothing inherent in
On 2/29/12 11:33 PM, Qrux wrote:
> Irony aside, I think it's fine to ask people to clarify, to prevent confusion
> and save the time spent down rabbit holes.
Absolutely, that's what learning and sharing knowledge is all about. It
sounded to me as if you were expressing frustration with Andy and
On 3/1/12 11:43 AM, Qrux wrote:
> What, specifically, are you addressing when you say "shouldn't care"? Are
> you speaking theoretically about how BIND should be designed? Or
> practically, based on knowledge of the source? Just to be clear, I'm
> specifically talking about the ssl-engine/lib
On 3/1/12 4:41 AM, Pierre Labastie wrote:
> ---
> diff -ur iteration-1/usr/lib/libgmpxx.la iteration-2/usr/lib/libgmpxx.la
> --- iteration-1/usr/lib/libgmpxx.la 2012-02-29 15:54:39.0 +0100
> +++ iteration-2/usr/lib/libgmpxx.la 2012-02-29 17:59:46.0 +0
On 3/1/12 2:30 PM, Qrux wrote:
> You seem to be saying: "Okay...We break the not-fixable stuff--BUT,
> HEY--that's the only thing that prevents this from being the right thing to
> do."
No, that's not what I am saying. I'm saying everything is fixable and
the unknown issues this will bring up
On 3/1/12 2:47 PM, Gerard Beekmans wrote:
> The scheduled outage for tonight has been cancelled as the data centre
> completed all the work last night.
Aww, and I was so looking forward to it! :)
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
On 3/1/12 3:48 PM, Bruce Dubbs wrote:
> Could you please explain (again) the advantages of your proposal over
> the current process.
The biggest advantages are that we don't have to maintain a patch that
reverts upstream changes to make our build system work (the pass2
startfiles fix patch) and
On 3/1/12 3:47 PM, Qrux wrote:
> That's good. Smells like common ground.
>
> So, what are you advocating as far as testing goes? Bruce just brought up a
> good point about ownership and accountability. It does seem unclear who
> should be testing. What are your thoughts about that, especially
On 3/1/12 3:58 PM, Ken Moffat wrote:
> Apologies to JH for allowing myself to be drawn OT now that he's
> pulled that branch.
:) No worries. It's good to hear where everyone stands. And perhaps we
can revisit it in the not too distant future.
JH
--
http://linuxfromscratch.org/mailman/listinf
On 3/1/12 4:10 PM, Bruce Dubbs wrote:
>> 3) Commit-triggered build would require something that pulls the
>> scripts out of the book pages and assembles them in a build-able
>> format. Does that exist?
>
> Yes, we have a script that downloads the xml and rebuilds the book and
> puts it into place.
On 3/1/12 5:22 PM, Greg Schafer wrote:
> Instead of vague assertions about "upstream intentions" and the like, I'd
> really appreciate it (if you are going to meddle with the toolchain build
> method) that you at least do what I have done for years and offer
> detailed analysis and testing and full
On 3/1/12 6:49 PM, Bruce Dubbs wrote:
You propose adding
--with-sysroot=$LFS\
--with-lib-path=/tools/lib \
The idea of sysroot is that its supposed to configure your compiler and
linker to consider DIR as the root location where resources for your
cross target live.
~/bi
On 3/1/12 7:39 PM, Andrew Benton wrote:
> I'm still no nearer to figuring out why I get this error. Trying to
> follow Jeremy's new newlib build method fails for me at the first pass
> of gcc:
> checking for stdint.h... no
> checking for unistd.h... no
> checking for dlfcn.h... no
> checking for ob
On 3/2/12 12:44 AM, Jeremy Huntwork wrote:
> when using sysroot as opposed to not. The "+"s are with sysroot.
Sorry, that's backwards - I made one patch originally the other way and
then regdiffed it a second time later.
The top line of the diff should be descriptive enough:
On 3/3/12 1:11 PM, Qrux wrote:
> The security issues with production has been mentioned several times. I've
> sort of just assumed it was a friendly "caveat emptor", and filtered it out.
> But, it's now come up often enough where it seem to be implying something
> stronger than the assumption
On 3/3/12 6:01 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>>
>> I think the reason this comes up is because LFS is made up of a
>> limited number of developers (essentially hobbyists) that don't have
>> the time and resources to track down all security issues.
On 3/1/12 7:39 PM, Andrew Benton wrote:
> If I go back to the patch it wouldn't even be trying to
> configure-target-zlib.
The patch is good to have as a workaround, but I'd like to find out what
the issue is that's causing this. I fear it's either a problem with your
host's compiler or a bug in
On 3/1/12 4:27 PM, Jeremy Huntwork wrote:
> And because of the pre-adjusting there's even less chance to bring in
> something from the host system. The limits.h file is an example. The
> first pass of GCC doesn't install a full-featured limits.h file because
> it can
On 3/4/12 10:10 AM, Jeremy Huntwork wrote:
> For the proposed build method, this does not appear to be the case:
>
> Fixing headers into /mnt/lfs/sources/gcc-build/gcc/include-fixed for
> x86_64-unknown-linux-gnu target
> Forbidden identifiers: linux unix
> Finding direct
On 3/5/12 11:56 AM, Andrew Benton wrote:
> Sorry for being slow to respond, I've been busy :)
> I remember reading that gcc bug last year when I first hit the problem.
> I spent some time trying to implement the solutions proposed there but
> none of them worked. Reading through it again now I noti
On 3/5/12 6:57 PM, Qrux wrote:
>
> On Mar 4, 2012, at 7:10 AM, Jeremy Huntwork wrote:
>
>> On 3/1/12 4:27 PM, Jeremy Huntwork wrote:
>>> And because of the pre-adjusting there's even less chance to bring in
>>> something from the host system. The limits.h fil
On 3/2/12 11:10 AM, Bruce Dubbs wrote:
>> --- binutils-build-sysroot-libdir/ld/eelf_x86_64.c 2012-03-01
>> 23:31:31.789317951 -0500
>> +++ binutils-build-nosysroot-nolibdir/ld/eelf_x86_64.c 2012-03-02
>> 00:29:16.117697363 -0500
>
> Yes, I saw that. Reviewing.
How is that coming along?
J
On Mar 11, 2012, at 8:15 PM, Andrew Benton wrote:
> On Sun, 11 Mar 2012 23:54:44 +
> Matt Burgess wrote:
>
>> On Fri, 2012-03-02 at 00:39 +, Andrew Benton wrote:
>>> On Sat, 25 Feb 2012 19:40:49 +
>>> Matt Burgess wrote:
>>>
Andy hit issues that were discussed in the threa
On Mar 11, 2012, at 8:19 PM, Matt Burgess wrote:
> On Mon, 2012-03-12 at 00:11 +, Andrew Benton wrote:
>
>> I get the same error if I use scripts or if I copy and paste the
>> commands from the book. It is a bootstrapped build of gcc, and it fails
>> during the second or third pass (notice ho
On 3/12/12 7:25 AM, Pierre Labastie wrote:
> Le 12/03/2012 10:18, Andrew Benton a écrit :
>> I've only just woken up so I've not had time to check, but looking at
>> the output above I'm pretty sure ${LFS_TGT} is set because I can see
>> lots of `x86_64-lfs-linux-gnu'. I also think it's doing a boo
On 3/12/12 7:24 AM, Andrew Benton wrote:
> I mainly use my current LFS install, I get the same errors if I use a
> Fedora or Ubuntu live CD.
Which version specifically? If I get a chance, I'll download an iso and
fire up a virtual machine to see if I can replicate.
JH
--
http://linuxfromscratch
On 3/12/12 11:14 AM, Andrew Benton wrote:
> Fedora-16-x86_64-Live-Desktop.iso
>
> FWIW I can do you sysroot method if I patch gcc with the cross_compile
> patch and add these options to configure:
>--without-ppl --without-cloog \
>--without-target-libiberty --without-target-zlib
>
> I'm not
On 3/13/12 12:27 PM, Pierre Labastie wrote:
> Le 13/03/2012 16:18, Andrew Benton a écrit :
>>
>> I was unwilling to use jhalfs as I dislike sudo. However, needs must,
>> and the result?
>> [...]
>> This was using Jeremy's sysroot.diff on top of the LFS xml files. I
>> think vanilla LFS will work fo
On 3/13/12 1:21 PM, Andrew Benton wrote:
> ... and then I tried jhalfs with the vanilla LFS svn book and of
> course, I was wrong again, it failed in exactly the same way! Looking
> at the differences between the book and the scripts that work for me,
> the book has --disable-target-libiberty --dis
On Mar 13, 2012, at 6:03 PM, Andrew Benton wrote:
> On Tue, 13 Mar 2012 17:40:03 +
> Bruce Dubbs wrote:
>
>> I'm having a problem with why this is happening.
>
> Me too...
>
>> The jhalfs vanilla LFS
>> svn build worked perfectly for me.
>>
>> http://www.linuxfromscratch.org/~bdubbs/033-gcc
On 3/8/12 4:24 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> On 3/2/12 11:10 AM, Bruce Dubbs wrote:
>>>> --- binutils-build-sysroot-libdir/ld/eelf_x86_64.c 2012-03-01
>>>> 23:31:31.789317951 -0500
>>>> +++ binutils-build-nosysroot-nolibd
On 3/14/12 7:20 PM, Matt Burgess wrote:
> On Wed, 2012-03-14 at 23:11 +, Andrew Benton wrote:
>
>> With the full gcc-4.6.3 tarball I get the same results as everybody
>
> Wonderful! I'll sleep easier tonight now :-) I'm glad this has finally
> been solved.
Nice! Glad we got that one nailed d
On 3/15/12 4:51 PM, Greg Schafer wrote:
> On Wed, 14 Mar 2012 20:32:36 -0700, Bryan Kadzban wrote:
>
>> It seems that Greg never got the time to comment any more thoroughly on
>> the modifications, either. I'd kinda like to hear what he has to say,
>
> Well, I've been doing a lot of reading in ord
On Mar 17, 2012, at 11:11 AM, Thierry Nuttens wrote:
> It's not easy to find the right mail about Jeremy's new build method.
http://linuxfromscratch.org/pipermail/lfs-dev/2012-February/065826.html
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/f
On 3/17/12 12:26 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>
>> Everyone else, please do review all of the links and posts that Greg
>> provided. It was mostly reading those (and bits of the source) as well
>> as the tests/experimentation that convinced me that t
On 3/14/12 11:32 PM, Bryan Kadzban wrote:
> It *almost* looks like sysroot is the equivalent of a DESTDIR install,
> where all the libs are installed into/whatever/path,
> but ask for /whatever/path at runtime (e.g. when ld.so is looking for
> DT_NEEDED entries, or in DT_RPATH entries in libs thems
On 3/16/12 3:22 AM, Bryan Kadzban wrote:
> Removing the need for adjusting the toolchain does seem to hurt
> teaching; we're using some magic flags instead of editing the specs
> file. (OTOH the specs file is now more of a builtin thing in the gcc
> driver. I do still think it's useful to know ab
On 3/17/12 5:38 PM, Bruce Dubbs wrote:
> Until gcc-4.7 comes out I'm recommending we use the exiting jh branch of
> lfs and go ahead and put in these changes now with the release candidate
> packages. Then we can do some jhalfs style builds and test things out
> from there. When the new tool chai
On 3/17/12 8:25 PM, Bruce Dubbs wrote:
> Jeremy Huntwork wrote:
>> I killed the jh branch some weeks back (I don't think I had touched it
>> since 2008) but we could re-create it again, if you like.
>
> Sure. I just re-created it.
Great, thanks.
> Do you want me
On 3/18/12 6:44 PM, Bryan Kadzban wrote:
> Well, from the comments in the book, it's not libc; it's crt1/crt0/crtn,
> or whatever the files are named these days.
Yes, you are correct, it's the start files it can't find. I was just
being imprecise.
> One other thing I'm concerned about is enablin
On 3/22/12 5:43 PM, Thierry Nuttens wrote:
> In file included from /mnt/lfs/tools/include/features.h:382:0,
> from /mnt/lfs/tools/include/limits.h:27,
> from
> /mnt/lfs/tools/bin/../lib/gcc/x86_64-lfs-linux-gnu/4.7.0/include-fixed/limits.h:169,
>
On 3/22/12 6:01 PM, Pierre Labastie wrote:
> Why do you use :
>
> + make install_root=/tools install?
>
> With --prefix=/tools, all the files are installed in
> /tools/tools/{lib,include}
>
> Of course the sanity check fails, because it looks for files in
> /tools/{lib,include}
Yep, thanks, I th
On Mar 28, 2012, at 9:37 PM, DJ Lucas wrote:
> Drop is better for the book.
+1
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 3/29/12 3:54 PM, Pierre Labastie wrote:
> Le 29/03/2012 19:13, Pierre Labastie a écrit :
>> Hi,
>>
>> #include "..." search starts here:
>> #include<...> search starts here:
>> /mnt/lfs/tools/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/include
>>
>> /mnt/lfs/tools/bin/../lib/gcc/x86
On 4/22/12 11:33 AM, LFS Trac wrote:
> #3066: Chapter 5 ncurses fails with (old?) gpm on host
> -+--
> Reporter: dj@… | Owner: lfs-book@…
> Type: task | Status: new
On 4/22/12 2:23 PM, DJ Lucas wrote:
> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
> not a symlink, but rather a linker script that points to another linker
> script that points to an invalid destination (ie: no 64bit libgpm). I
> was going to close as invalid, but then
On 4/22/12 2:25 PM, Jeremy Huntwork wrote:
> On 4/22/12 2:23 PM, DJ Lucas wrote:
>> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
>> not a symlink, but rather a linker script that points to another linker
>> script that points to an invalid dest
On 4/22/12 2:35 PM, Bruce Dubbs wrote:
> It only makes a difference if we are going to actually use ncurses
> functionality
> between the time we bould it in Chapter 5 and Chapter 6. Otherwise we are
> just
> linking to the libraries.
>
> However, I don't have a problem with adding --without-gpm
On 4/22/12 2:35 PM, Jeremy Huntwork wrote:
> On 4/22/12 2:25 PM, Jeremy Huntwork wrote:
>> On 4/22/12 2:23 PM, DJ Lucas wrote:
>>> As it turns out, it was a problem with the host. /usr/lib64/libgpm.so is
>>> not a symlink, but rather a linker script that points to ano
On 4/22/12 2:49 PM, Pierre Labastie wrote:
> Solution:
> add the switch --with-native-system-header-dir=/tools/include to
> gcc-pass2 configure command.
> I've been building ten times on various (virtual) hosts with this switch
> without a problem.
I believe the proposed sysroot method also fixes
On 4/22/12 2:52 PM, Jeremy Huntwork wrote:
> On 4/22/12 2:49 PM, Pierre Labastie wrote:
>> Solution:
>> add the switch --with-native-system-header-dir=/tools/include to
>> gcc-pass2 configure command.
>> I've been building ten times on various (virtual) hosts with
On 4/22/12 3:48 PM, Pierre Labastie wrote:
> cp gcc/Makefile.in{,.orig}
> sed '/^CROSS_SYSTEM_HEADER_DIR/s@= .*@= /tools/include@' \
> gcc/Makefile.in.orig> gcc/Makefile.in
> cp gcc/cppdefault.c{,.orig}
> sed '/#define STANDARD_INCLUDE_DIR/s@"/usr/include"@0@g' \
> gcc/cppdefault.c.or
On 4/22/12 3:48 PM, Pierre Labastie wrote:
> I think the sysroot method can be simplified if using the switch above:
> you do not even need the part:
>
> cp gcc/Makefile.in{,.orig}
> sed '/^CROSS_SYSTEM_HEADER_DIR/s@= .*@= /tools/include@' \
> gcc/Makefile.in.orig> gcc/Makefile.in
> cp gcc/
On 4/22/12 4:09 PM, Jeremy Huntwork wrote:
> So CROSS_SYSTEM_HEADER_DIR should get set correctly if we've already
> specified NATIVE_SYSTEM_HEADER_DIR, which is what gets set via your switch.
>
> I'll just fix up the jh branch source and give another run and compare
So, I'm seeing that you have the aforementioned switches in both pass 1
and pass 2 gcc and I'm trying to understand exactly why.
Here's the changeset that introduced them:
http://wiki.linuxfromscratch.org/lfs/changeset/9349
And here's the ticket that started that ball rolling:
http://wiki.linuxf
On 4/22/12 5:59 PM, DJ Lucas wrote:
> On 04/22/2012 04:35 PM, Jeremy Huntwork wrote:
>> So, I'm seeing that you have the aforementioned switches in both pass 1
>> and pass 2 gcc and I'm trying to understand exactly why.
>
> In pass1 it simply speeds up the build
On 4/22/12 6:00 PM, Matt Burgess wrote:
> Given your reasoning, I don't see why they're needed either, but #2723
> explicitly mentioned link errors (although conveniently failed to copy
> and paste them). Now, admittedly, I never saw those errors myself, but
> then I only test on one arch on one h
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/22/12 6:41 PM, Jeremy Huntwork wrote:
woops, that wasn't supposed to send. Turned out to be a very minor
thread after all. :)
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 4/22/12 6:44 PM, DJ Lucas wrote:
> I'm not entirely positive, it's been a few years, but there was no need
> to compile unnecessary additions that eat up time. Granted, it is a very
> small savings in the grand scheme. That was the goal of those switches
> and several others at the time that GCC
On 4/22/12 11:36 PM, Bruce Dubbs wrote:
> gcc-pass2
[snip]
> Configure:
> Remove -B/tools/lib/ from CC
> Remove configure options
> --with-native-system-header-dir=/tools/include
> --without-ppl
> --without-cloog
The --with-native-syste
On 4/23/12 12:00 PM, Jeremy Huntwork wrote:
> The --with-native-system-header-dir=/tools/include option is actually an
> addition, not a removal. Everything else looks like it's correct, Bruce.
> (I think I forgot to remove the startfiles patch from chapter 3 and the
> patches.e
On 4/23/12 12:28 PM, Bruce Dubbs wrote:
> I also think we will need a paragraph or two in the "What's New" section
> explaining the changes.
Yeah, that might be good. Also a review of section 5.2 to make sure all
statements there are still correct.
JH
--
http://linuxfromscratch.org/mailman/lis
This changelog entry on 2012-04-05 isn't quite correct. It reads:
[matthew] - Use su from chapter 6 Coreutils in the Bash instructions,
instead of the one from chapter 5. Install su as su rather than su-tools
in chapter 5. Fixes #3057.
coreutils in chapter 6 doesn't install su. So the su you're
On 4/23/12 12:45 PM, Jeremy Huntwork wrote:
> This changelog entry on 2012-04-05 isn't quite correct. It reads:
>
> [matthew] - Use su from chapter 6 Coreutils in the Bash instructions,
> instead of the one from chapter 5. Install su as su rather than su-tools
> in ch
On 4/23/12 1:11 PM, Pierre Labastie wrote:
> The reason is that /tools/bin/su cannot work for a normal user,
> because the setuid bit cannot be set at install in chapter 5 (if
> installing as user lfs). Hence the choice of naming it su-tools, to
> prevent it to run (and fail) if the lfs user (who h
On 4/23/12 4:33 PM, Matt Burgess wrote:
> The fix for this is to add
> --with-native-system-header-dir=/tools/include to GCC's pass1 and pass2
> builds so that it doesn't look at /usr/include at all.
For the current build method, I think it's only required for pass 2.
Given the difference of our
On 4/23/12 11:42 PM, Bruce Dubbs wrote:
> That's it. I think Jeremy has done a great job.
Thanks :) glad it worked well for you.
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
On 26 Apr 2012, at 14:02, Ken Moffat wrote:
> Compare
> http://www.linuxfromscratch.org/lfs/view/development/chapter06/readjusting.html
> to
> http://www.linuxfromscratch.org/lfs/view/jh/chapter06/adjusting.html
I think it was a bad svn merge.
Let me see if I can fix.
JH
--
http://linuxfromscra
On 26 Apr 2012, at 15:10, Ken Moffat wrote:
> I've got a diff of chapter06/adjusting.xml from trunk/BOOK to
> branches/jh which looks as if it will do the right thing. I can
> apply it if you like ?
Sure - there's also these two minor ones:
Index: chapter05/gcc-pass2.xml
Looks like I missed some necessary text changes. At the bottom of
chapter 5 glibc, in the sanity check box, the following sentences are
no longer accurate and can be removed:
"Something may have gone wrong with the specs file amendment above. In
this case, redo the specs file amendment, being care
On May 5, 2012, at 10:24 AM, Jeremy Huntwork <
jhuntw...@lightcubesolutions.com> wrote:
Looks like I missed some necessary text changes.
There's also this statement made regarding the fixincludes script in GCC
pass 2: "In fact, running this script may actually pollute the buil
On 5/7/12 7:04 PM, Matt Burgess wrote:
> There's a comment in linux/a.out.h that it fixed
> up /tools/include/a.out.h so that looks OK. syslimits.h just includes
> limits.sh, so that looks fine too. limits.h has been fixed but there's
> no indication of which limits.h was used as input to it. I
Greetings all,
Consider two things:
1. We all hate long build times. Anything we can (reasonably and
accurately do) to speed up the build we do.
2. Chapter 5 are a set of throwaway tools (in some cases we only build
just what we want out of those tools, again, for sake of speed, i.e.,
gettext)
201 - 300 of 1449 matches
Mail list logo
