Re: x86_64 build method
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 declaration? If it is, the differences between the books could be even more minimal as we can set an entity for the target triplet and dynamic linker based on the arch we are building. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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' \, assumes that we will find the name of the dynamic linker at the beginning of the line. In x86_64, this isn't the case. I think that at least the chapter6/readjusting phase could be made a little simpler. On the x86_64 arch this command: gcc -dumpspecs | sed \ -e 's@/tools/lib64/ld-linux-x86-64.so.2@/lib64/[EMAIL PROTECTED]' \ 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? -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 and the bits you were able to confirm. And sorry for being a little bit testy on the other threads. At least we now have a definite working setup in the branch. Enough that I was able to build a 64-bit LiveCD based on it. (More on that shortly...) Do you know off-hand if anything changes with gcc-4.2? Now that we have a separate branch for 6.3, trunk will be milestoned for 7.0 which means updating glibc and gcc. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 --disable-multilib and appropriate symlinks and gcc pass1 failed when it got to stage1 of the bootstrap. I didn't get the opportunity to add a /lib64 symlink and test it further... Hmm, that's interesting. I didn't expect that. I suppose that if the above is correct this also means that your native build expects a /lib64 dir or symlink on the host? This is confirmed. Adding /lib64 and /usr/lib64 symlinks to a CLFS host enables gcc to bootstrap in pass1 without using the pure64 patch. Initially I thought this part of the pure 64 patch: --- gcc-4.2.0.orig/gcc/config/i386/t-linux642007-05-16 19:21:19.0 -0400 +++ gcc-4.2.0/gcc/config/i386/t-linux64 2007-05-18 17:04:36.0 -0400 @@ -6,7 +6,7 @@ MULTILIB_OPTIONS = m64/m32 MULTILIB_DIRNAMES = 64 32 -MULTILIB_OSDIRNAMES = ../lib64 ../lib +MULTILIB_OSDIRNAMES = ../lib ../lib32 was why you weren't seeing the -L/lib/../lib64 stuff in your -v output. I tried my build with just that part changed but I still ended up with -L/lib/../lib appearing (which wasn't in your log). Therefore I don't really know what is going on :-( Tho' it does appear from what you say that the host's /lib* layout does indeed play a role. Ideally, the build method should work no matter what the /lib* layout on the host is. But I must say, it does appear that any 64-bit host that is missing /lib64 and /usr/lib64 is not kosher. After all, the facts are that a) the lib64 stuff is the default config throughout the entire upstream toolchain sources, b) the big distros all appear to use lib64 and c) lib64 is apparently mandated by the LSB (tho' it's a bit vague there judging from my casual glance). But on the flipside, all of the above possibly assumes a multilib setup? Dunno. It would be very interesting if all the 64-bit distros could be surveyed (ie: ls -ld /l*) to find out their /lib* layout arrangements and whether they are multilib or pure 64. 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. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 ultrasparc (64bit sparc) I've always done what the ultrasparc gurus have suggested for many years, 32bit userland + 64bit cross compiler and 64bit kernel. So if you decide to support x86_64 you'll end up needing a cross compiler just for the kernel. Oh, and you don't actually need multilib glibc either if you go with pure 32bit/pure 64bit userland. Even though 64bit CPUs sold outnumber 32bit CPUs sold at the moment, the installed base of 32bit CPUs is far larger than 64bit CPUs. So I suggest LFS remain for the foreseeable future purely 32bit userland. For traditional 64-bit platforms, that is true. On my own mac G5 (which needs a 64-bit kernel), the only real benefit of multilib is that I get to run the testsuite on the kernel compiler. OTOH, I get to say this one goes up to 64 ;). Having said that, I don't actually notice that the 64-bit parts of my desktop (that would be gimp, gnumeric, kde, the audio apps, and icewm on multilib) are slower, nor do I notice that the 32-bit desktop as a whole is any more responsive to e.g. changing the active window - in fact if anything it *feels* slower with 32-bit userspace. But enough of traditional multilib 64-bit platforms, I'm not about to propose that ppc64 be added to LFS ;-) For x86_64, the situation is very different. The problem with x86 is that it lacks registers, so gcc produces slow code. With x86_64, the code is faster. A 64-bit kernel also appears to avoid the problems of accessing large amounts of memory (I say appears because none of my boards have more than 2GB of memory, and hardware or bios limitations have been reported several times on lkml). For sure, it avoids the whole idea of highmem and bounce buffers in kernelspace. I was hoping that this discussion would be deferred until after the holiday season. If not, I guess I'll have to come down in the 64 bits good, 32 bits less good camp for x86|x86_64. The LFS family of projects are all about learning and *building* the software. Building multilib can be an aggravation - the base system has to build packages with libraries in both sizes (for LFS we could argue about a few of them, but the problem is that *somebody* will find an application that they want to build in the other size), and inevitably that sometimes means wasting time by installing the associated programs from the first size and then overwriting them with the programs from the second size. Sure, the base system is not a big deal, it just takes longer. The real multilib fun is in BLFS - can you say gdk-pixbuf-query-loaders or gnome servers ? I'm tempted to suggest that this would be a good time to put ppc (32-bit only) back into the book, but I'm not sure if there is a big enough user base to make that worthwhile ? ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 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 problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. 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 onerous to me. Once in there, I doubt they'd need amending much - probably only if newer GCC versions change relevant portions of the specs file. Of course, if more targets are desired in the future, our approach may well need to change, but for now I think x86 x86-64 native builds capture the largest section of the LFS audience and anyone else can continue on to CLFS. Regards, Matt. Speaking from experience building LFS on x86, ppc (32bit) and sparc (both 32 and 64 bit), except for the dynamic linker and the boot loader, there is little to no difference in the instructions when building on different architectures. So with minimal effort the book can be modified to apply universally. 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 ultrasparc (64bit sparc) I've always done what the ultrasparc gurus have suggested for many years, 32bit userland + 64bit cross compiler and 64bit kernel. So if you decide to support x86_64 you'll end up needing a cross compiler just for the kernel. Oh, and you don't actually need multilib glibc either if you go with pure 32bit/pure 64bit userland. Even though 64bit CPUs sold outnumber 32bit CPUs sold at the moment, the installed base of 32bit CPUs is far larger than 64bit CPUs. So I suggest LFS remain for the foreseeable future purely 32bit userland. Ideally, parts of CLFS would be merged into LFS. I never understood the need for CLFS. Presumably it was for people like me who were building LFS on non-x86 architectures. But CLFS is just complicating what is a rather simple procedure. The only useful things in it are the extra packages needed for different architectures. And the instructions to build a cross compiler. Everything else is just LFS. I understand the reluctance of the LFS devs to explicitly support non-x86 build as someone has to spend the time and effort to test the instructions on those other architectures. But I still maintain that since you're discussing the inclusion of x86_64, you might as well consider modifying the instructions minimally so that, even if the book doesn't mention non-x86, the instructions will still work. I'm talking about the dynamic linker and the sed command fixing the gcc specs. IvanK. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 declaration? If it is, the differences between the books could be even more minimal as we can set an entity for the target triplet and dynamic linker based on the arch we are building. 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 the other at sources load time. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 the other at sources load time. Thanks, that answers my question. :) -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 book shortly. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
x86_64 build method
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. All that 'ls -ld /l*' shows me is: drwxr-xr-x 5 root root 2696 2007-07-19 16:35 /lib 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 symlinks and gcc pass1 failed when it got to stage1 of the bootstrap. I didn't get the opportunity to add a /lib64 symlink and test it further... I suppose that if the above is correct this also means that your native build expects a /lib64 dir or symlink on the host? I found a Ubuntu CD and a spare partition, so I'll be using them as a host for my next test. I may also run a DIY build, just to familiarize myself more with your current setup. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 symlinks and gcc pass1 failed when it got to stage1 of the bootstrap. I didn't get the opportunity to add a /lib64 symlink and test it further... I suppose that if the above is correct this also means that your native build expects a /lib64 dir or symlink on the host? This is confirmed. Adding /lib64 and /usr/lib64 symlinks to a CLFS host enables gcc to bootstrap in pass1 without using the pure64 patch. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 GCC pass 2, adjust the multilib spec, MULTILIB_OSDIRNAMES. DIY just removes this completely. * Add the symlinks /lib64 - /lib and /usr/lib64 - /usr/lib 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? If we did, for the latter two additions we could add a uname test before the command. Personally I favor making them one book, but were we to do that, we would have to rethink a few things: 1) The way the text reads when it speaks about target triplets and dynamic linkers and the appropriate names for these. For x86_64, the dynamic linker is ld-linux-x86-64.so.2 and the target triplet is usually x86_64-unknown-linux-gnu. 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 '[EMAIL PROTECTED]/lib/ld-linux.so.2@/tools@g' \, assumes that we will find the name of the dynamic linker at the beginning of the line. In x86_64, this isn't the case. 3) The toolchain tests would have to be changed to reflect the output of either testcase. Usually this is because the output of the test involves the name of the dynamic linker or the target triplet. Lastly, we would want to test to see if someone is building natively from a CLFS host that doesn't include /lib64 or /usr/lib64. If they are, it's a simple matter of adding those symlinks before starting the build. Even with all the above, it seems much simpler than trying to maintain two separate books. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 trying to maintain two separate books. -- JH Forgive the intrusion but I thought this worth saying... Of course it might be complete hogwash in which case please enlighten me ;-) (I'm quite thick-skinned too) A while ago now I looked at building CLFS for my AMD 64 processor. But after doing some research, IIRC I discovered that there was almost no gain to be had from building LFS as *pure* 64bit and there were quite a few problems, namely: * Bootloader, or rather lack-of * Building BLFS on top of a pure 64b LFS was - at the time - impractical and untested * Several apps and closed-source binaries widely used were not available for 64bit architectures. Unless this has significantly changed (in which case I'll be building a new LFS64 next week ;-)) I think some rather bold and legible text at the start of the book needs to make it clear that there may be little point in doing this unless you know what to do next. Alan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 repository. I think Dan suggested we could use some XSL-foo (profiling?) to generate two different books from the same XML sources. This is certainly my preferred method as it eases maintainance (both books receive fixes/feature enhancements at the same time) and eases readability (readers only see 1 straight flow of instructions, even there would only be 2 if...else type choices to make currently). I think this is also how CLFS works with its different targets, though I'll admit it's been a very long time since I looked at those sources. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 LiveCD, for example. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 book with x86? I'd certainly prefer them to be in the same book, My biggest problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. 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 onerous to me. Once in there, I doubt they'd need amending much - probably only if newer GCC versions change relevant portions of the specs file. Of course, if more targets are desired in the future, our approach may well need to change, but for now I think x86 x86-64 native builds capture the largest section of the LFS audience and anyone else can continue on to CLFS. Regards, Matt. -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 onerous to me. Once in there, I doubt they'd need amending much - probably only if newer GCC versions change relevant portions of the specs file. Of course, if more targets are desired in the future, our approach may well need to change, but for now I think x86 x86-64 native builds capture the largest section of the LFS audience and anyone else can continue on to CLFS. Well, if that's the preferred method, I'll give it a go. Let me see what I can do... -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 changes into a conglomerate book with x86? I'd certainly prefer them to be in the same book, My biggest problem with this approach is that it gets to be a nightmare to edit. But, it is do-able. 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 onerous to me. Once in there, I doubt they'd need amending much - probably only if newer GCC versions change relevant portions of the specs file. Of course, if more targets are desired in the future, our approach may well need to change, but for now I think x86 x86-64 native builds capture the largest section of the LFS audience and anyone else can continue on to CLFS. There is one other place we need to address in a x86_64 system: ii. Audience Why would you want to build an x86_64 system? To me there are more drawbacks than advantages. I'm not saying not to do it, because one of the reasons to build it is because It is there. and one of the major objectives of the book is education. Other reasons to build it include the need to manipulate very large (3G) files, to work with very large databases, to fully take advantage of physical RAM 4G, or to run specialized software efficiently (Computational fluid dynamics anyone?). The disadvantages are numerous and need to be mentioned. Issues include boot loader problems, lack of support for 64-bit closed source binaries such as flash, and potential problems in building some open source packages. Minor issues include slightly larger binaries. Also the point needs to be made that the speed of execution will probably not significantly increase for most applications and in some cases may be slower than a 32-bit systems. -- Bruce -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 are generated from one common sources tree. CLFS uses a diferent, more complex, method due that 12 book need be generated. But also, there is only one common sources tree. I prefer to use the HLFS-way for x86_64 integration. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 ask Robert if it hard to maintain. Four sepparte books are generated from one common sources tree. CLFS uses a diferent, more complex, method due that 12 book need be generated. But also, there is only one common sources tree. I prefer to use the HLFS-way for x86_64 integration. Out of curiosity, will the Relax NG XML ease in generating multiple books from a common source? If we're considering using Relax NG for LFS-7.0, that should be kept in mind. -- Dan -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 namespace) to the default DocBook-XML set while allowing separate or combined schemas validation. For example, in the old times when the migration to XML/XSLT was initiated, one of the cool new features discussed was that we would be able to change the book screen blocks to nALFS sintax. That has no sense right now, of course. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 priority on doing the jhalfs-2.3 release. Could you continue using the x86_64 branch for now until jhalfs-2.3 will be released? 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 be modified to support multiple books build. -- Manuel Canales Esparcia Usuario de LFS nº2886: http://www.linuxfromscratch.org LFS en castellano: http://www.escomposlinux.org/lfs-es http://www.lfs-es.info TLDP-ES: http://es.tldp.org -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
Re: x86_64 build method
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 be modified to support multiple books build. If I end up getting it sorted it out, I'll let you take a look before I commit anything. -- JH -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
