On Thu, Aug 09, 2007 at 04:28:47PM +1000, Greg Schafer wrote:
> Ok, it appears the GCC devs conveniently added a new (undocumented?)
> configure switch in 4.2 `--disable-stage1-checking' which does the right
> thing. Times for GCC-4.2.1 bootstraps without and with the switch are
> below:
Thanks. I
Greg Schafer wrote:
> PS - According to my build logs, GCC-4.2 takes almost *double* the amount
> of time of GCC-4.1 for a 3-stage bootstrap. This doesn't matter much on a
> modern dual-core system (16m 45s vs 8m 41s) but it's very noticeable on an
> older ppc mac mini (91m vs 43m). So maybe there
Alexander E. Patrakov wrote:
> I was trying to find a way to build some LFS-like x86_64 system from
> Debian Lenny x86 (which has 32-bit userspace, a patched compiler that
> accepts -m64 to produce 64-bit binaries, some multilib setup, and an
> option to install a 64-bit kernel).
Hmm, sounds l
Jeremy Huntwork wrote:
> I'm curious to know if the bootstrap would work if you used
> --disable-shared for gcc-pass1 and continued to use 'make bootstrap'.
>
This failed with the same "specs: Invalid argument" error.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/l
Alexander E. Patrakov wrote:
> I wrote:
>> In order to build /tools to the end, I had to make the following extra
>> adjustments:
> In order to build binutils stage2, I also need to add (surely) flex and
> (possibly) m4 and bison to Chapter 5.
>
I'm still curious what your results would be if y
I wrote:
> In order to build /tools to the end, I had to make the following extra
> adjustments:
In order to build binutils stage2, I also need to add (surely) flex and
(possibly) m4 and bison to Chapter 5.
--
Alexander E. Patrakov
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: h
Alexander E. Patrakov wrote:
> In order to build /tools to the end, I had to make the following extra
> adjustments: add --disable-libmudflap to gcc pass1, and replace "make
> bootstrap" with just "make" there (presumably, there is some mismatch
> with 64-bit glibc or headers and toolchain on th
Jeremy Huntwork wrote:
> Do you know off-hand if anything changes with gcc-4.2?
I've only tested x86 with GCC-4.2. I'll get to x86_64 and ppc when time
allows.
Regards
Greg
--
http://www.diy-linux.org/
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.o
Greg Schafer wrote:
> Anyhow, I still suspect there is a buglet involving MULTILIB_OSDIRNAMES
> somewhere in the GCC driver that needs to be accounted for in this
> `--disable-multilib' build method, but my brain hurts when trying to
> figure out all the twisty parts of gcc.c.
Thanks for your help
Jeremy Huntwork wrote:
> Jeremy Huntwork wrote:
>> As an aside, the effects of their not having a /lib64 dir or symlink
>> seems to be that if I want to use a CLFS system as a host, I *must* use
>> their pure64 patch. I tried a build last night without using that patch
>> and just using --disab
On Wed, Jul 25, 2007 at 05:45:48PM -0400, Ivan Kabaivanov wrote:
>
> The only big issue is 32bit vs 64bit. As someone already mentioned
> previously
> in this thread, there are almost nil benefits in building a 64bit userland.
> Very few applications can make use of being compiled 64bit. So
On Tuesday 24 July 2007 12:10, Matthew Burgess wrote:
> On Tue, 24 Jul 2007 11:59:39 -0400, Jeremy Huntwork
<[EMAIL PROTECTED]> wrote:
> > Matthew Burgess wrote:
> >> On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork
> >
> > <[EMAIL PROTECTED]> wrote:
> >>> The question is, do we want x86_64 to
On Wed, Jul 25, 2007 at 05:24:04PM +, Jeremy Huntwork wrote:
> can easily become:
>
> gcc -dumpspecs | sed -e 's@/tools@@g' \
>
> I can't test this on x86 right atm... would anyone be able to verify that this
> command would also work for x86?
Nevermind. I verified it. Will be adding this to
On Wed, Jul 25, 2007 at 08:07:24PM +0200, M.Canales.es wrote:
> I'm not sure what do you meant, but entities are resolved while loading the
> XMLs in memory and before processing the they with XSL, thus I don't see how
> could we say to xmllint/xsltproc that they must use one set of entities or
El Miércoles, 25 de Julio de 2007 19:10, Jeremy Huntwork escribió:
> Manuel, I'm slowly beginning to understand how the HLFS render 'magic'
> works. One question: would the 'condition'
For LFS we should use the arch= attribute. It's more semantically correct.
> parameter be usable in an ENTITY
Jeremy Huntwork linuxfromscratch.org> writes:
> 2) The commands to adjust the gcc spec file would have to change to
> incorporate either dynamic linker. (Also, the current command in chapter
> 5's adjusting the toolchain, "gcc -dumpspecs | sed
> 's ^/lib/ld-linux.so.2 /tools& g' \", assumes
Jeremy Huntwork linuxfromscratch.org> writes:
> If I end up getting it sorted it out, I'll let you take a look before I
> commit anything.
Manuel, I'm slowly beginning to understand how the HLFS render 'magic' works.
One question: would the 'condition' parameter be usable in an ENTITY
declaratio
M.Canales.es wrote:
> Could you continue using the x86_64 branch for now until jhalfs-2.3 will be
> released?
No problem.
> I think that at the weekend I will can start mergin the x86_64 changes into
> trunk. For a full set-up a new top-level index.html file must be created and
> the Makefile
El Martes, 24 de Julio de 2007 20:12, Jeremy Huntwork escribió:
> M.Canales.es wrote:
> > I prefer to use the HLFS-way for x86_64 integration.
>
> Well, you obviously know that setup better than I do. If you could help
> me set that up, I'd appreciate it.
I have many fronts open right now, with pr
M.Canales.es wrote:
> I prefer to use the HLFS-way for x86_64 integration.
Well, you obviously know that setup better than I do. If you could help
me set that up, I'd appreciate it.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscr
El Martes, 24 de Julio de 2007 19:51, Dan Nicholson escribió:
> Out of curiosity, will the Relax NG XML ease in generating multiple
> books from a common source?
Not, what Relax-NG make more easy is to customize the schema declaration. I.e,
to add new tags or attributes (placed on a diferent na
On 7/24/07, M.Canales.es <[EMAIL PROTECTED]> wrote:
> El Martes, 24 de Julio de 2007 17:59, Jeremy Huntwork escribió:
>
> > My biggest problem with this approach is that it gets to be a nightmare
> > to edit. But, it is do-able.
>
> See how HLFS manages the Glibc/uClibc - Linux-2.4/2.6 books flavou
El Martes, 24 de Julio de 2007 17:59, Jeremy Huntwork escribió:
> My biggest problem with this approach is that it gets to be a nightmare
> to edit. But, it is do-able.
See how HLFS manages the Glibc/uClibc - Linux-2.4/2.6 books flavours and ask
Robert if it hard to maintain. Four sepparte books
Matthew Burgess wrote:
> On Tue, 24 Jul 2007 11:59:39 -0400, Jeremy Huntwork
> <[EMAIL PROTECTED]> wrote:
>> Matthew Burgess wrote:
>>> On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork
>> <[EMAIL PROTECTED]> wrote:
The question is, do we want x86_64 to be a separate book, or
simply
>>
Matthew Burgess wrote:
> Hmm, that "nightmare" seems a bit extreme. Certainly, for native x86-64,
> which is the only additional target we're contemplating at the moment, having
> 2 paragraphs (or small sections at the most) in the book surrounded in the
> relevant profiling syntax, doesn't see
On Tue, 24 Jul 2007 11:59:39 -0400, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> Matthew Burgess wrote:
>> On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork
> <[EMAIL PROTECTED]> wrote:
>>
>>> The question is, do we want x86_64 to be a separate book, or simply
> roll
>>> these small changes into
Alan Lord wrote:
> * Bootloader, or rather lack-of
Yes, I keep forgetting about the boot loader. There's one more
difference - we'd probably want to add lilo/bin86 to the build.
Of course, you can always install grub to the mbr or partition without
installing grub's shell into the OS. Use the L
Matthew Burgess wrote:
> On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
>
>> The question is, do we want x86_64 to be a separate book, or simply roll
>> these small changes into a conglomerate book with x86?
>
> I'd certainly prefer them to be in the same book,
M
On Tue, 24 Jul 2007 11:40:24 -0400, Jeremy Huntwork <[EMAIL PROTECTED]> wrote:
> The question is, do we want x86_64 to be a separate book, or simply roll
> these small changes into a conglomerate book with x86?
I'd certainly prefer them to be in the same book, or at least in the same
sources/sv
Jeremy Huntwork wrote:
> Hello Everyone,
>
> I'm trying to decide how best to alter the x86_64 branch. If we adopt
> the basic principles from DIY-Linux, it would mean that as far as build
> instructions go, we only have to add 3 things:
> Even with all the above, it seems much simpler than try
Hello Everyone,
I'm trying to decide how best to alter the x86_64 branch. If we adopt
the basic principles from DIY-Linux, it would mean that as far as build
instructions go, we only have to add 3 things:
* Add --disable-multilib to each build of GCC (this has no effect on a
x86 build)
* In GC
Jeremy Huntwork wrote:
> As an aside, the effects of their not having a /lib64 dir or symlink
> seems to be that if I want to use a CLFS system as a host, I *must* use
> their pure64 patch. I tried a build last night without using that patch
> and just using --disable-multilib and appropriate sy
[EMAIL PROTECTED] wrote:
Lionel Lagarde wrote:
Hi all.
I have just bought a new pc and I want to install Linux there by
following the lfs book.
Someone has already managed to compile lfs on a amd64 system ?
If so, from what os ?
I'm using a x86_64 fedora core 4 and I ca
> Lionel Lagarde wrote:
>> Hi all.
>> I have just bought a new pc and I want to install Linux there by
>> following the lfs book.
>> Someone has already managed to compile lfs on a amd64 system ?
>> If so, from what os ?
>>
>> I'm using a x86_64 fedora core 4 and I can't compile gcc (the
>> compila
> Hi all.
> I have just bought a new pc and I want to install Linux there by
> following the lfs book.
> Someone has already managed to compile lfs on a amd64 system ?
> If so, from what os ?
>
> I'm using a x86_64 fedora core 4 and I can't compile gcc (the
> compilation fail on rebuilding xgcc wit
Lionel Lagarde wrote:
Hi all.
I have just bought a new pc and I want to install Linux there by
following the lfs book.
Someone has already managed to compile lfs on a amd64 system ?
If so, from what os ?
I'm using a x86_64 fedora core 4 and I can't compile gcc (the
compilation fail on rebuild
On Thu, 8 Sep 2005, Jeremy Huntwork wrote:
Jim Gifford wrote:
Interesting!! So either GCC is not compiling Glibc with NPTL correctly, or
we have a GCC 4.0.1 issue.
Matt Darcy is trying the Currently GLIBC snapshot.
If the snapshot works well, we should seriously consider using that in the
We have had people test the GCC4 branch and it doesn't affect it, which
is kinda of strange.
To recreate the two issues we have seen, just do configure and make,
with glibc or binutils. Each issue is specific to the architecture that
what makes it harder to track down.
glibc - 32/64 on x86_6
Jeremy Huntwork wrote these words on 09/08/05 14:06 CST:
> If the snapshot works well, we should seriously consider using that in
> the current gcc4 branch instead of the patches in place now.
To try and get a better understanding of the issues, can you tell me
what I need to look for to see if
Jim Gifford wrote:
Interesting!! So either GCC is not compiling Glibc with NPTL correctly,
or we have a GCC 4.0.1 issue.
Or, the current cross-lfs instructions need to be altered. As far as
I'm aware, following the gcc4 branch, noone has encountered any of the
issues yourself or Matt Darcy
Jim Gifford wrote:
Interesting!! So either GCC is not compiling Glibc with NPTL correctly,
or we have a GCC 4.0.1 issue.
Matt Darcy is trying the Currently GLIBC snapshot.
If the snapshot works well, we should seriously consider using that in
the current gcc4 branch instead of the patches
Now to add the twist to this tail. During testing I've personally seen
some wierd stuff with GCC 4.0.1, Glibc 2.3.5, and Binutils 2.16.1.
When I built an x86 to x86 system following the book exactly, I get to
binutils and I would get a Malformed Archive on all binutils static
libraries. Repeat
Matt Darcy wrote:
Hi all,
There appears to be a problem with the cross-build gcc4 project. From
dicussions on this it appears to be a compatability issue with gcc4
which displays its self on different platforms in different ways.
I have been working on the x86 to x86_64 multi-lib version of
43 matches
Mail list logo
