Re: ICA/Farce

Bruce Dubbs wrote: > Umm, no. jhalfs parses the xml of the book and creates a Makefile that > builds > by the LFS book. Actually, it is quite convenient. Umm, yes. It's *VERY* convenient. I should know.. (Me wonders if Bruce realizes the whole "build straight from the doc" concept in jhalfs

Re: gmp required ABI=32

Tobias Gasser wrote: > i had to add ABI=32 as my system was identified ad 64bit. > > ./configure ABI=32 --prefix=/usr --enable-cxx --enable-mpbsd > > i'm using CFLAGS="-O3 -march=i486" as a global setting, overwritten for > some special cases mentionned in the book. > > any idea why i have to

Re: gmp required ABI=32

Ken Moffat wrote: > My box built gmp and the first part of chapter 6 during the night > without any apparent problem. The host system was LFS-6.3 with a > current kernel. I just looked into this. It appears the bug only tickles when CFLAGS are set. ie: if CFLAGS are set in the environment, it g

Re: r8591 - in trunk/BOOK: . chapter01 chapter03 chapter06

Greg Schafer wrote: > Randy McMurchy wrote: >> Not sure why you're seeing it. In fact I had 0 (zero) failures on my >> testsuite run. :-) >> >> ext/Sys/Syslog/t/00-load..ok >> ext/Sys/Syslog/t/constants

Re: Readjusting toolchain nitpick

Jeremy Huntwork wrote: > We can simplify the sed expression and get rid of the note entirely if we > change it to: > > -e 's@/tools@@g' > > Anyone have any objections to this change? I'd just like to make the following points: 1. You're introducing a distinct lack of clarity about what is

Re: Aiming for 7.0

Greg Schafer wrote: > In a (native) sysroot scenario, anything and _everything_ can be found > on the host. Here's a Binutils thread about a sysrooted ld which touches upon what I'm talking about: http://sourceware.org/ml/binutils/2008-08/msg00060.html Regards Greg -- http://w

Re: Aiming for 7.0

Jeremy Huntwork wrote: > Upstream appears to think that using sysroot is the correct approach sysroot is a complete non-starter for us. Think about it. Have you ever tried a sysroot build? In our current build methods, we go to *great* lengths to prevent stuff from being found on the host. In a (

Re: Aiming for 7.0

Jeremy Huntwork wrote: > What do you think is likely to happen in future versions and/or what is > your plan? GCC is not going to revert back, clearly. > Just continue to maintain the backport patch for future versions? Pretty much. It's similar in principle to the current specs handling ie: ch

Re: Aiming for 7.0

Jeremy Huntwork wrote: > 1. Move to DIY's new build method in trunk. If we ignore multilib and > any extra arch support for this step, the changes required aren't > actually that many, and they all take place pretty early in chapter 5. I realize you say "this step", but LFS is already too far

Re: Aiming for 7.0

Jeremy Huntwork wrote: > Greg, as I have your attention, I'm curious why the -fomit-frame-pointer > change is still present in your second pass of gcc. I thought the > purpose of this was to maintain compatibility between the first > bootstrapped pass of gcc and the second pass? GCC is no long

Re: r8754 - in trunk/BOOK: chapter01 chapter05 chapter06

jhuntwork wrote: > Initial addition of support for x86_64 ??? This is nothing like the new build method at all. It appears you've taken stuff from the old jh branch, which is now completely outdated because it's based on the old build method.. Ughh. Not sure where you're going dude, but this is

Re: The new build method is in...

Jeremy Huntwork wrote: > 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.) No. You've also omitted perhaps the most interesting feature of the whole thing - the ability to migrate from a 32-bit system to a 64-bi

Re: The new build method is in...

Jeremy Huntwork wrote: > Knock it off. I don't come to DIY and disparage your work. Huh? Get over yourself dude. You've *always* taken things so personally. Grow a thick skin. Remember I'm trying to support *you* implementing *my* work. Watch your tone and focus on the task at hand. Thanks. Reg

Re: The new build method is in...

Ryan Oliver wrote: > Couple of minor things > > 1: Chapter 6.15 - If you aren't bootstrapping the compiler, you wont be > using the newly created binutils to build your new gcc. Correct. DIY takes care of this with the `-B/usr/bin/' thing. Whether it actually matters much is questionable. As pe

Re: The new build method is in...

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 > place. I'll restate in clear terms. You're modifying/creating fil

Re: Sysroot based sane multilib toolchain build for LFS style builds [update]

Ryan Oliver wrote: > # Sysroot based SANE multilib cross-compiler build for LFS style builds Heh, this is hilarious. A new and improved build method goes into LFS and CLFS folks awake from the dead :-) Feeling some pressure guys? :-) Sorry mate, but this whole thing looks of very poor quality an

CLFS antics

> Author: jim > Log: > Creating of CLFS Native Structure Well, well, well. What have we here? What happened to the big `C' in CLFS guys? Changing your name to NLFS? I've seen some incredible stuff on the *LFS lists over the years but this appears to be the most breathtaking act of arrogance I've

Re: Adapting LFS SVN for multilib

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 bizarre `/cross-tools' prefix. Let me explai

Re: Adapting LFS SVN for multilib

Jeremy Huntwork wrote: > As far as 'butchering the source' goes, there's nothing done in the > first pass of GCC to the source that isn't done in pass 2. Essentially > it's the same sort of stuff we've _always_ done in pass 2 to ensure that > the compiler uses only the libs and headers in /tool

Re: Adapting LFS SVN for multilib

Ryan Oliver wrote: > Incorrect. The initial point of installing into a separate directory And this is documented where? Another CLFS strong point! Dude, you can blather on all you like. But none of your rhetoric can hide the fact your builds are as ugly as sin and incomprehensible by mere mortal

Re: Adapting LFS SVN for multilib

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 the dir that's supposed to be clean. It's the build method. You unnecessarily compli

Re: Adapting LFS SVN for multilib

Ryan Oliver wrote: > No, I solve problems for which you have not catered for yet. > CLFS deals with building from non-linux hosts. Off topic > Isn't your supposed goal technical perfection that us mere LFS mortals > can only aspire to? Not at all. Get the job done as quickly and efficiently as

Re: Adapting LFS SVN for multilib

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 senior toolchain person confirms how sysroot is meant to be used (read the whole bug report for context): http://l

Re: Adapting LFS SVN for multilib

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. Here's another data point from the GCC man/info/web docs: "--sysroot=dir Use dir

Re: Adapting LFS SVN for multilib

Jim Gifford wrote: > Again Greg provide us more information about the ICA, it seems to be > your own creation? 1. Read this post from Dan Nicholson: http://article.gmane.org/gmane.linux.lfs.devel/8120 2. Look at the comments in the gsbuild scripts from DIY 3. Look at the jhalfs implemen

Re: Adapting LFS SVN for multilib

Matthew Burgess wrote: > In which case, all I can suggest is you follow the process yourself: > > 1) Compile CLFS from a non-CLFS host > 2) Use the newly built CLFS to build a second CLFS system (obviously using > exactly the same commands and package versions) No, that's not quite right. The se

Re: LFS Toolchain

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. > > Some weeks ago, Ryan proposed a

Re: Adapting LFS SVN for multilib

quot; > and > "GAH OH NOES gcc source edits, sysroot misuse, FUD FUD unsubstantiated FUD" > is merely that the author was not Greg Schafer. Wow, man, you're starting to lose it. Stay focused! > I put this build together *solely to prove a point* No, you put this build togeth

Re: LFS Toolchain

Ryan Oliver wrote: > Look back into the clfs-lite that was proposed 4 years ago in the lfs wiki. > > Referenced here > http://linuxfromscratch.org/pipermail/lfs-dev/2005-April/051171.html Vapour. > 4 years ago your opinion was markedly different with regards to using > cross-compilers for any

Re: LFS Toolchain

Jeremy Huntwork wrote: > For those unfamiliar see: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 > > For those not interested in reading the entire bug history, the last > comment by a dev was: > > "Using the sysroot flags is the solution for Greg's scenario. In fact I > would say it mak

Re: LFS Toolchain

Jeremy Huntwork wrote: > No, sorry, I don't. In the comments of that bug report the dev suggests > using sysroot for pass 1 of gcc. Yeah, and he also says create $sysroot/usr/include. If you're going to hang your hat on the word of 1 junior GCC dev... > Also, haven't you noticed that making use

m4 badness

Hi, Just stumbled across this. You will likely want to fix it: http://lists.gnu.org/archive/html/m4-patches/2009-02/msg00010.html Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the ab

Re: inetutils before perl

On Wed, 15 Apr 2009 14:50:10 -0600, Archaic wrote: > +#define PHOSTNAME "/usr/bin/hostname" /* How to get the host name */ Side note - FHS says hostname should be /bin/hostname i.e. it's a bug. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev

Re: LFS-6.5 RC2 plans

On Wed, 29 Jul 2009 04:07:58 -0600, Matthew Burgess wrote: > On Wed, 29 Jul 2009 01:29:31 -0800, Rabbit wrote: > >> but I think we should use just only use i686-pc-linux-gnu because I >> think it doesn't make sense to use i686-pc-lfs-gnu. > > The 'i686-lfs-linux-gnu' came in through the move ac

Re: New e2fsprogs

On Wed, 26 Aug 2009 17:27:56 -0500, Bruce Dubbs wrote: > From a 64 bit system, we'd need to use cross compile techniques for > these files > so they don't try to use 64-bit addresses. Umm, what's wrong with installing a 32-bit libc? It's 1 extra package, it solves the grub problem, and it all

Re: New e2fsprogs

On Wed, 26 Aug 2009 18:23:53 -0500, Bruce Dubbs wrote: > A 32-bit libc is a consideration. I don't know how to do that yet. I lied. It's actually 2 extra packages :-/ One needs to build a 32-bit libc in Ch 5 too (so that GCC can be multilib) This is all covered in the DIY Refbuild (packages a

Re: New e2fsprogs

On Wed, 26 Aug 2009 18:32:28 -0500, William Immendorf wrote: > This has got me thinking: If we are going to build a 32-bit Glibc for > multilib LFS, why don't we do a fully multilib system for 64-bit, like > how CLFS does it? Because that way lies madness (as has been discussed many times before)

Re: New e2fsprogs

On Wed, 26 Aug 2009 18:58:53 -0500, Bruce Dubbs wrote: > bdu...@lfs6:/usr/sbin$ ldd grub > linux-gate.so.1 => (0xe000) > libncurses.so.5 => /lib/libncurses.so.5 (0xb7efd000) libc.so.6 > => /lib/libc.so.6 (0xb7ddc000) /lib/ld-linux.so.2 (0xb7f59000) > > Looks like i

Re: LFS Directions

On Thu, 17 Sep 2009 15:31:41 -0600, Matthew Burgess wrote: > On Thu, 17 Sep 2009 16:18:16 -0500, Bruce Dubbs > wrote: >> #2412 Add more rationale to Toolchain Technical Notes >> >> Who do we get to advise us on this one? > > I'd appreciate it if Greg could help contribute on this I'm ho

Re: LFS Directions

On Thu, 17 Sep 2009 16:12:43 -0700, Nathan Coulson wrote: > I have been experimenting with a multilib LFS System (where /lib, > /usr/lib are used for 64bit, and /lib/32, and /usr/lib/32 are used for > 32bit). I advise against this. Not FHS compliant and not what the big distros do. > The toolcha

Re: GRUB-1.97

On Thu, 29 Oct 2009 00:48:05 -0500, Bruce Dubbs wrote: > I have updated the book to GRUB-1.97. Grub2 appears to have a major regression in that installing into the PBR no longer works. Note - I'm talking about non-MBR installs, ie: installing Grub into a Partition Boot Record. I haven't looked

Re: GRUB-1.97

On Mon, 09 Nov 2009 17:36:53 -0600, Bruce Dubbs wrote: > I don't know for sure, but I think that install into a PBR is a > configuration issue. No, it's definitely a bug (and a regression at that). See these links: http://ubuntuforums.org/showthread.php?t=1284914 http://grml.org/grml2usb/#mbr-v

Re: Proposing a new LFS release

On Mon, 25 Jan 2010 01:39:13 +0100, Jean-Philippe MENGUAL wrote: > what kind of buildings can do a user exactly > with this stable (6.6)? From 64 to 64 bits? From 32 to 32? Or 32 to 64? Actually, the underlying build method supports all combinations: 32->32 64->64 32->64 64->32[*] (* the last o

Re: LFS Directions

On Mon, 01 Feb 2010 23:00:41 +0100, Mark Rosenstand wrote: > Much more clever would be to mention MAKEFLAGS in the intro somewhere, > and add -j1 as needed for the packages that don't support parallel make. Exactly as currently done in DIY Linux. > This is what I do in my build scripts, and out

Re: LFS Directions

On Mon, 01 Feb 2010 23:00:57 +, Matthew Burgess wrote: > What's your recommendation then? Pass '-j1' on the command line for all > 'make install' invocations? That's probably overkill. All I know is I've previously been burnt by both GCC and Glibc with `-j3' on 2 cores. And considering the i

Re: GAWK Test report LFS-6.6-rc1

On Thu, 04 Feb 2010 20:46:58 -0600, Bruce Dubbs wrote: > FAIL: stackoverflow2 > === > 1 of 5 tests failed > === > > I've determined that this is a kernel problem. I was using lfs-6.5 and > the kernel was 2.6.30.2. After booting to 2.6.32.7, this failure went > aw

Re: LFS Directions

On Tue, 02 Feb 2010 07:15:38 +, Greg Schafer wrote: > On Mon, 01 Feb 2010 23:00:57 +, Matthew Burgess wrote: > >> What's your recommendation then? Pass '-j1' on the command line for all >> 'make install' invocations? > > That's proba

Re: [lfs-dev] Build method revisions

On Mon, 27 Feb 2012 22:49:07 -0500, Jeremy Huntwork wrote: > The main differences (I'll outline all of them shortly) are the > pre-adjusting of gcc in pass 1 along with the use of sysroot and newlib. I'm so far out of touch I don't have the energy to shoot this down. For the record, I don't agre

Re: [lfs-dev] Build method revisions

On Thu, 01 Mar 2012 16:27:31 -0500, Jeremy Huntwork wrote: > And that's it. It's cleaner, more direct, and more closely tracks what > upstream has provided. I'm sorry to say this but your whole premise is based on hearsay and personal opinion. Instead of vague assertions about "upstream intenti

Re: [lfs-dev] Build method revisions

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 order to get back up-to-speed. One of the reasons

Re: [lfs-dev] Build method revisions

On Fri, 16 Mar 2012 22:29:29 -0400, Jeremy Huntwork wrote: > Greg, there's no need to make this personal. No worries dude. Not trying to cause trouble so my apologies if you've taken any offence. I just tend to get passionate about build method matters. > It was mostly reading those (and bits

Re: [lfs-dev] Possible problem with current glibc (LFS 7.2 cant recompile LFS 7.2)

On Sat, 25 Aug 2012 21:59:04 +0100, Jasmine Iwanek wrote: > Actually, when I copied in rpc/types.h, I put it in /usr/include/rpc and > that made the ch5-glibc build happy Um, doesn't anyone see the obvious problem here? The cross toolchain is apparently finding stuff on the host. The whole poin

Re: [lfs-dev] glibc and rpc headers

On Mon, 27 Aug 2012 05:20:39 +0100, Jasmine Iwanek wrote: > I'll have a poke at building glibc with no host headers shortly to see > what other headers get pulled in, if nothing else it'll keep Greg quiet Fat chance of that :-) Anyway, my immediate concerns have been allayed because it turns out

Re: Re-adding *startfile_prefix_spec

Jeremy Huntwork wrote: > There is a bug open to remove this feature from gcc. But, it is a year > old now and still open. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353 Not exactly. That bug report is about startfile_prefix_spec being a faulty spec. It coincidentally highlighted the fact

Re: Re-adding *startfile_prefix_spec

Jeremy Huntwork wrote: > Isn't using -B to find libraries an abuse as well? Huh? Using a documented switch for a documented purpose? RTFM :-) Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe

Re: Re-adding *startfile_prefix_spec

Jeremy Huntwork wrote: > Obviously '-B' works for you, and obviously, Ryan's methods work for > him. Is there a 'best for LFS' in all of that? When in doubt, play the multilib card! :-) But seriously, I dunno. I fail to see how you can equate the 2. Comparing cross compilation to native compilat

Re: Re-adding *startfile_prefix_spec

Greg Schafer wrote: > Personally, I don't believe in it and will never use it because: > > - the spec is faulty. It doesn't work when placed into an external file >for use by "gcc -specs=..." (luckily LFS is not using it externally). >Every other

Re: Re-adding *startfile_prefix_spec

Ryan Oliver wrote: G'day Ryan, good to see you alive and kicking on the list :-) Unfortunately, all you've done is told us why you don't like -B. You haven't addressed the core issue of this thread ie: startfile_prefix_spec. We'd all appreciate it if you could address the concerns that I've rai

Re: Re-adding *startfile_prefix_spec

Ryan Oliver wrote: > When you are doing an old style cross-toolchain build Nobody sane uses old style cross-toolchain build procedures these days :-) > (ie: not using a sysroot, all target libraries and includes installed > under /prefix/target/lib /prefix/target/lib64 > /prefix/target/{include

Re: perl libc patch incomplete?

Alexander E. Patrakov wrote: > The problem is that any header > in /usr/include but not in /tools/include will be found as existing by > Perl Configure script, thus leaking unwanted influence from the host to > Chapter 5 Perl. While nobody reported a failed compilation because of > that, it is

Re: perl libc patch incomplete?

Dan Nicholson wrote: > After looking over Configure for a while, I would suggest this > > sed -i 's,/usr/include,/tools/include,g' Configure Hmmm, yes it should work. But I believe hints/linux.sh is the place to sort this stuff out. I just tried adding: usrinc="${prefix}/include" to hints/linu

Re: Bootstrapping GCC

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' to the gcc build of chapter 6. Hm, this means you effectively end up building GCC 7 times, 3 times in

Re: Bootstrapping GCC

Jeremy Huntwork wrote: > The benefits of this is that, after it builds its stage 1 xgcc, even if > there are inconsistencies in the chapter 5 toolchain, gcc will always > find and use the correct binutils in /usr. Also it will build itself > using the same configuration the final product will h

Re: [DIY BUG] bash wants en_US locale

Alexander E. Patrakov wrote: > some tme ago I imported from DIY linux the statement that none of the > locales are really required. As it stands now, this statement is wrong. > When checking whether the ctype macros accept non-ascii characters, Bash > configure script attempts to set the en_US.

Re: binutils to change ld search behavior

Dan Nicholson wrote: > It appears that binutils ld will be changing its search behavior to > more closely follow ld.so. See this post: > > http://sources.redhat.com/ml/binutils/2006-02/msg00127.html > > It seems that rather than using the compiled in LIB_PATH that we make > use of in Ch. 5 to r

Re: r7381 - in trunk/BOOK: . chapter01 chapter03 chapter06

matthew wrote: > Author: matthew > Date: 2006-02-19 13:31:54 -0700 (Sun, 19 Feb 2006) > New Revision: 7381 > > Modified: >trunk/BOOK/chapter01/changelog.xml >trunk/BOOK/chapter01/whatsnew.xml >trunk/BOOK/chapter03/packages.xml >trunk/BOOK/chapter06/sed.xml >trunk/BOOK/general.

Re: Text in fstab page about /dev/shm

Dan Nicholson wrote: > I don't know much about the subject either, Chris. Here's the thread > for the original flame war that resulted in that wording, though: > > http://linuxfromscratch.org/pipermail/lfs-dev/2003-October/039106.html > > Maybe someone who understands the uses of SysV shared me

Re: r7392 - in trunk/BOOK: . chapter01 chapter03

matthew wrote: > Author: matthew > Date: 2006-02-21 13:50:22 -0700 (Tue, 21 Feb 2006) > New Revision: 7392 > > Modified: >trunk/BOOK/chapter01/changelog.xml >trunk/BOOK/chapter03/patches.xml >trunk/BOOK/patches.ent > Log: > Add Bash patches 009 and 010 from upstream Matt, patch 010 b

Re: r7392 - in trunk/BOOK: . chapter01 chapter03

Matthew Burgess wrote: > As regards to LFS unstable living up to its name, that's probably > because we chose the right name for it, i.e. we don't try and pretend > that it's something it isn't. I don't see why you thought a :-( was > necessary. Yes, testing could have been more thorough, but

Re: r7398 - in trunk/BOOK: . chapter01

archaic wrote: > Author: archaic > Date: 2006-02-27 18:26:57 -0700 (Mon, 27 Feb 2006) > New Revision: 7398 > > Modified: >trunk/BOOK/chapter01/changelog.xml >trunk/BOOK/general.ent >trunk/BOOK/patches.ent > Log: > New bash fixes patch adds patch 011 from Bash upstream. The patch is w

Re: RFC - Raw Kernel Headers

Alexander E. Patrakov wrote: > DJ Lucas wrote: > >> Another very minor point is trying to find a way to rip out all the >> __KERNEL__ portions > > That's what the "unifdef" tool in FreeBSD does. It also works in Linux. > > http://www.cs.cmu.edu/~ajw/public/dist/unifdef-1.0.tar.gz > > Note: Deb

Re: RFC - Raw Kernel Headers

Tushar Teredesai wrote: > Gentoo is using a script similar to the above script to sanitize the > headers. Do you have a pointer? Thanks. Regards Greg -- http://www.diy-linux.org/ -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See

Re: RFC - Raw Kernel Headers

Tushar Teredesai wrote: > The kernel-2.eclass file at > has > the gory details on how gentoo creates the headers. It has lot of > extra functions since the same elcass is also used for kernel > compilation. Ok, thanks. Tho' I had man

Re: RFC - Raw Kernel Headers

Alexander E. Patrakov wrote: > __iomem removal is not questionable at all. This macro indicates that > this is not a valid pointer that you can dereference directly, but a > cookie that you can pass to the ioremap() in-kernel function in order to > access the hardware via the MMIO mechanism. Th

Re: New LFS RElease?

Bryan Kadzban wrote: > Not quite true anymore; 2.6.16 also includes some new syscalls (openat > and friends) that will (may? probably "will") require changes in the > userspace headers. Most definitely, if you want them to be used that is :-) Tho' only Glibc-2.4 and above has support for the new

Re: RFC - Raw Kernel Headers -- Comparison Script Added

Jim Gifford wrote: > Just added a compare script. That will compare the difference between the > raw_headers produced with the headers script compared to the headers in > llh. Jim, I've been working along similar lines. I'm getting the diff down all the time. I've included some stuff below which

Re: RFC - Raw Kernel Headers -- Comparison Script Added

Bryan Kadzban wrote: > Greg Schafer wrote: >> echo '/* empty */' > linux/compiler.h > > Hmm... Is this really necessary? It is if you want to duplicate LLH. I should have added in my post that the above change requires more sanitization eg: removing __user, __force,

Re: RFC - Raw Kernel Headers -- Comparison Script Added

Jürg Billeter wrote: > Yes, LLH fails that criteria and it ships with a lot of kernel-only > stuff. Based on Jim's script I've written an extended version which > removes a lot of headers that shouldn't be part of the linux glibc > header set, AFAICT. Cool. But one has to ask how you arrived at t

Re: RFC - Raw Kernel Headers -- Comparison Script Added

Jürg Billeter wrote: > Very short rationale is given on top of each file group. Detailed > rationale for each header would unfortunately be too time consuming. Hmmm, that's not ideal. I'm assuming you've looked at each header and used your judgement to determine whether it should be removed or no

Re: RFC - Raw Kernel Headers -- Comparison Script Added

Jürg Billeter wrote: > I've also run a script to find used kernel headers over the sources of > the 800 packages (except kernel and headers packages). You can find the > results on http://www.paldo.org/headers/ Wow. Again, excellent work. > * headers-list: Sorted list of all found header refere

Re: RFC - Raw Kernel Headers -- Comparison Script Added

Jürg Billeter wrote: > I know that it's far from ideal but the only ideal way I see would be to > extensively add __KERNEL__ ifdefs to the linux headers upstream so that > the script could recognize automatically which headers are > kernel-internal. Unfortunately this probably won't happen in the

Re: RFC - Raw Kernel Headers

Jim Gifford wrote: > On a few of the lists I have seen this done with success > and found out that this is the recommended build method for GLIBC, still > checking on the status GCC and this situation. It has *always* been an option to compile Glibc against raw headers. Nothing there has changed.

Re: RFC - Raw Kernel Headers

DJ Lucas wrote: > Ran into difficulties tonight. Need to protect against kernel types > that conflict with glibc in linux/types.h. I'm not sure what you're trying say in this post. It would help if you specified the actual problem you are having. > The quick solution for xorg-server was to >

Re: testing inotify

Archaic wrote: > or better yet, does anyone see a need to include the new syscalls? I'm surprised this question has been asked. It's Glibc FAQ material: http://sources.redhat.com/glibc/glibc-faq.html#s-1.8 And for an explanation with more details, pls see here: http://www.diy-linux.org/piperma

Re: Future plans for xLFS

Dan Nicholson wrote: > So, --with-sysroot is only needed while building the toolchain? It > looks like the only other trick is using DESTDIR to get the install to > go to the right spot. I imagine perl is causing all kind of > nightmares. > > This looks awesome. Not to bash the work being done

Re: Bashing the tests, was Re: Glibc 32 bits check

Ken Moffat wrote: > Sounds good as a solution, but I'd like to understand what is wrong > - it looks like a side-effect of su'ing to lfs. The issue has already been reported upstream but no response apparently: http://lists.gnu.org/archive/html/bug-bash/2006-05/msg00018.html Regards Greg PS -

Latest ORBit2 (or why the BLFS dependency scheme sucks)

Hi Don't get me wrong, I like the BLFS dependency strategy a lot, and in fact I use a similar strategy here myself. Of course I'm referring to the way in which only direct deps are listed ie: deps that are implicitly pulled in are not listed. A classic example is popt. Lots of Gnome depends on pop

Re: Glibc-2.4 / kernel-headers

Dan Nicholson wrote: > Incidentally, David Woodhouse checked in a series of patches to his > repo due to all the failures in headers_check. We'll see what actually > gets into Linus' tree. > > http://kernel.org/git/?p=linux/kernel/git/dwmw2/kernel-headers.git;a=summary Ummm, that stuff is alread

Re: Upgrade to Linux-2.6.18

Bryan Kadzban wrote: > Hmm; it looks like unifdef is not included in the kernel tree. We're > going to have to add this to chapter 5. (Actually we'll have to build > it just before the kernel headers install in chapter 5; then we might as > well just use the version from /tools in chapter 6 also

Re: kdebase vs. linux headers

Matthew Burgess wrote: > The `-ansi' switch to the GNU C compiler defines __STRICT_ANSI__. > > It just so happens that the compilation of kdebase uses the -ansi > switch, hence the compilation problem. Now, I still don't know what the > correct solution is. Do we just kill the -ansi flag from

Re: kdebase vs. linux headers

On Thu, 05 Oct 2006 22:27:31 +0100, Matthew Burgess wrote: > Looking at > http://websvn.kde.org/tags/KDE/3.5.5/kdebase/kcontrol/joystick/joydevice.h?rev=591452&view=markup, > > that would appear to be the correct fix too! Strongly disagree. That's a workaround. The headers should compile with

Build order change - Re: r7807 - in trunk/BOOK: . chapter01 chapter06

> Author: matthew > Date: 2006-10-04 10:40:23 -0600 (Wed, 04 Oct 2006) > New Revision: 7807 > Upgrade to Coreutils-6.3 > Modified: trunk/BOOK/chapter06/chapter06.xml > === > --- trunk/BOOK/chapter06/chapter06.xml2006-09-29 01

Re: Binutils testsuite

On Wed, Oct 25, 2006 at 10:03:16AM +0600, Alexander E. Patrakov wrote: > if the user includes "-Os" in his CFLAGS, binutils tests in LFS-6.2 will > show 21 failures ("visibility" and "shared" tests). 18 of them don't > show up if the "binutils-2.17-ppc64_fix_testsuite-1.patch" testsuite fix ..

Re: expect patch testing

Jeremy Huntwork wrote: > So, I'm not sure where this leaves us. Exactly where you were before. Nothing has changed. > The bug does still seem to exist > in expect, but, at least currently, the test-suites that make use of > expect seem unaffected by the inclusion or absence of the patch. No.

Re: Upgrade to Linux-2.6.18

Jeremy Huntwork wrote: > Actually, after looking through the Linux Makefile a bit, I think our > commands for chapter 5 linux-headers can be simplified to the following: > > patch -Np1 -i ../linux-2.6.18.1-unifdef-1.patch > make mrproper > make headers_check > cp -Rv usr/include/* /tools/include

Re: Upgrade to Linux-2.6.18

Jeremy Huntwork wrote: > This has nothing to do with the way other packages work. This is *only* > applicable with this particular package and its Makefile. Why make a > temporary directory outside the build tree, install it there first, and > then manually move it to its final location when it

Re: Upgrade to Linux-2.6.18

Jeremy Huntwork wrote: > Have you actually studied the Makefile contents? The results of the > current commands would be the same as if you ran (which, btw, would also > avoid the problem with removing /tools/include): > > make mrproper > make headers_check > make headers_install > cp -av usr/

Re: Upgrade to Linux-2.6.18

Jeremy Huntwork wrote: > But if that's the case, headers_check re-runs everything you > just did in 'headers_install', which makes the 'headers_install' kind of > pointless. To me, it seems more like 'headers_check' is an extension of > 'headers_install', adding an extra step of verification.

Re: Minor build order breakage

Jeremy Huntwork wrote: > On a system based on very recent LFS development (last week or so...) I > see this: > > # grep /tools /usr/bin/* -R > /usr/bin/mk_cmds:SED=/tools/bin/sed > > This is because e2fsprogs is built before our final sed. Already reported... sadly, no action. http://linuxfrom

Re: Minor build order breakage

Matthew Burgess wrote: > Oh dear. Sorry about that folks. As Bruce points out though, Trac's > much better at remembering bugs than I am! This "must-use-trac" attitude from the LFS project is abhorrent IMHO. Most open source projects are just happy to receive any feedback whatsoever. Whatever

  1   2   3   >