Jeremy Huntwork jhuntwork at 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
Jeremy Huntwork jhuntwork at 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 at ^/lib/ld-linux.so.2 at /tools at g'
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:
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:
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
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
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 be a separate
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
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
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 the
This is a continuation from here:
http://linuxfromscratch.org/pipermail/lfs-dev/2007-July/059737.html
Starting a new thread because the last one was getting unwieldy and had
several different topics running through it.
Greg, the host I was working from was a current CLFS development
snapshot.
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
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
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:
snip /
Even with all the above, it seems much simpler than
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/svn
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,
My biggest
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
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 a conglomerate
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 seem too
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
roll
these small
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
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 flavours and
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
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
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 need
25 matches
Mail list logo
