From diy-linux-dev@diy-linux.org Mon Feb 4 00:12:42 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 4 Feb 2008 10:12:42 +1100 Subject: coreutils-6.10 Message-ID: <20080203231242.GA19085@eyo32.local> Hi List, I'm looking at getting latest Coreutils into the Refbuild.. Some changes will be necessary: - no more bz2 tarball (bad move IMHO) only lzma and gz. We'll use the gz. - `su' and `hostname' no longer installed by default. Can still install them by passing `--enable-install-program=hostname,su' which is what I'll do initially to maintain the status quo. - there's a Makefile bug that causes failure when installing `su'. Upstream have already fixed it. I'll use this sed: sed -i.bak 's/installed_su)\t/installed_su);\t/' src/Makefile.in - some programs can now be disabled by default which means we can lose the current hacks and instead pass `--enable-no-install-program=kill,uptime' - the gnulib component now comes with its own testsuite. The first problem is the `test-getaddrinfo' test which tries to resolv domain names and fails due to lack of /etc/resolv.conf in the chroot. I'll just disable this test for now with a sed: sed -i.bak 's/test-getaddrinfo\$(EXEEXT) //' gnulib-tests/Makefile.in the second problem occurs when we build as root (LFS style) then run the testsuite as the dummy user. It craps out with a permissions error that can be fixed with this sed (after make): chown -v dummy gnulib-tests/.deps - `mktemp' is now provided by Coreutils and cannot easily be disabled due to it being an integral part of the testsuite. For now I'll just drop `mktemp' from Debianutils with a possible view to dropping Debianutils entirely in the future. - When using `--enable-install-program=hostname,su' the Temptools Perl requires the "POSIX" module. Note - LFS has been installing this module (unnecessarily?) for years. It used to be required only when building Coreutils from CVS or maybe some pre-releases. - However, there is another problem related to the above. Coreutils testsuite now fails due to missing Perl "Errno" module. This module appears to be different to the others and cannot be installed in the same way. For now, I've just taken the soft option and installed a full Perl in the Temptools phase. This is less than satisfactory so I challenge anyone to come up with a solution. That's all I can think of for now. Regards Greg From diy-linux-dev@diy-linux.org Mon Feb 4 16:45:30 2008 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Mon, 4 Feb 2008 07:45:30 -0800 Subject: coreutils-6.10 In-Reply-To: <20080203231242.GA19085@eyo32.local> References: <20080203231242.GA19085@eyo32.local> Message-ID: <91705d080802040745u502201e2s5cc968b8041e8c34@mail.gmail.com> On Feb 3, 2008 3:12 PM, Greg Schafer wrote: > > - However, there is another problem related to the above. Coreutils > testsuite now fails due to missing Perl "Errno" module. This module > appears to be different to the others and cannot be installed in the same > way. For now, I've just taken the soft option and installed a full Perl > in the Temptools phase. This is less than satisfactory so I challenge > anyone to come up with a solution. I recently ran my head into a while on that one. Like you noticed, since it's not a static extension, you can't configure it the same way since. However, you can just tack the correct make target on: make perl utilities ext/Errno/pm_to_blib I don't recall how I reached that conclusion, but it seems to work. I needed it because I wanted to use a temporary autoconf. My commit message says something about recreating $(nonxs_ext). -- Dan From diy-linux-dev@diy-linux.org Mon Feb 4 22:30:16 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 5 Feb 2008 08:30:16 +1100 Subject: coreutils-6.10 In-Reply-To: <91705d080802040745u502201e2s5cc968b8041e8c34@mail.gmail.com> References: <20080203231242.GA19085@eyo32.local> <91705d080802040745u502201e2s5cc968b8041e8c34@mail.gmail.com> Message-ID: <20080204213016.GA23788@eyo32.local> On Mon, Feb 04, 2008 at 07:45:30AM -0800, Dan Nicholson wrote: > make perl utilities ext/Errno/pm_to_blib > > I don't recall how I reached that conclusion, but it seems to work. I > needed it because I wanted to use a temporary autoconf. My commit > message says something about recreating $(nonxs_ext). *boggle* I doubt I'd ever have figured that one out.. The Perl build system is a freakin nightmare.. Thanks champion! :-) Regards Greg From diy-linux-dev@diy-linux.org Tue Feb 5 07:33:38 2008 From: diy-linux-dev@diy-linux.org (Alf mel) Date: Mon, 4 Feb 2008 23:33:38 -0700 Subject: Problems with new build method and Perl Message-ID: <200802042333.38259.alf@mypals.org> I've been playing around with the new build method and I'm having troubles with Perl in the temptools phase. When I build the temptools, everything is properly linked to the libraries in /temptools/lib, except for perl. Perl insists on linking to the host glibc and not to the glibc in /temptools. Has anyone else encountered this problem? Any suggestions on what might be wrong? Did I miss a step somewhere? -- @ - Alf From diy-linux-dev@diy-linux.org Tue Feb 5 13:20:08 2008 From: diy-linux-dev@diy-linux.org (Alf mel) Date: Tue, 5 Feb 2008 05:20:08 -0700 Subject: Problems with new build method and Perl In-Reply-To: <200802042333.38259.alf@mypals.org> References: <200802042333.38259.alf@mypals.org> Message-ID: <200802050520.08394.alf@mypals.org> On Monday 04 February 2008 11:33:38 pm Alf mel wrote: > Has anyone else encountered this problem? Any suggestions on what might > be wrong? Did I miss a step somewhere? I found my problem. I forgot to make the cc -> gcc in GCC Pass 2. Every package looks for gcc specifically, except for perl, of course. -- @ - Alf From diy-linux-dev@diy-linux.org Tue Feb 5 18:56:33 2008 From: diy-linux-dev@diy-linux.org (Ivan Kabaivanov) Date: Tue, 5 Feb 2008 12:56:33 -0500 Subject: Problems with new build method and Perl In-Reply-To: <200802050520.08394.alf@mypals.org> References: <200802042333.38259.alf@mypals.org> <200802050520.08394.alf@mypals.org> Message-ID: <200802051256.33923.chepati@yahoo.com> On Tuesday 05 February 2008 07:20, Alf mel wrote: > On Monday 04 February 2008 11:33:38 pm Alf mel wrote: > > Has anyone else encountered this problem? Any suggestions on what might > > be wrong? Did I miss a step somewhere? > > I found my problem. I forgot to make the cc -> gcc in GCC Pass 2. Every > package looks for gcc specifically, except for perl, of course. Actually, well behaving packages look for cc, "dumb and lazy" ones look for gcc. There are more than one c compilers available ... IvanK. From diy-linux-dev@diy-linux.org Wed Feb 6 02:32:49 2008 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Tue, 5 Feb 2008 17:32:49 -0800 Subject: coreutils-6.10 In-Reply-To: <20080204213016.GA23788@eyo32.local> References: <20080203231242.GA19085@eyo32.local> <91705d080802040745u502201e2s5cc968b8041e8c34@mail.gmail.com> <20080204213016.GA23788@eyo32.local> Message-ID: <91705d080802051732k3ba61154p941f22460a464745@mail.gmail.com> On Feb 4, 2008 1:30 PM, Greg Schafer wrote: > On Mon, Feb 04, 2008 at 07:45:30AM -0800, Dan Nicholson wrote: > > > make perl utilities ext/Errno/pm_to_blib > > > > I don't recall how I reached that conclusion, but it seems to work. I > > needed it because I wanted to use a temporary autoconf. My commit > > message says something about recreating $(nonxs_ext). > > *boggle* > > I doubt I'd ever have figured that one out.. The Perl build system is a > freakin nightmare.. Thanks champion! :-) You're welcome. I took another look, and I can explain a bit. Try this: ./configure ... -Dnonxs_ext='Errno' and look at $(nonxs_ext) in Makefile. Now, find a Makefile target that will pull in $(nonxs_ext). :) I couldn't do it cleanly. -- Dan From diy-linux-dev@diy-linux.org Wed Feb 6 04:00:30 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Wed, 6 Feb 2008 14:00:30 +1100 Subject: coreutils-6.10 In-Reply-To: <91705d080802051732k3ba61154p941f22460a464745@mail.gmail.com> References: <20080203231242.GA19085@eyo32.local> <91705d080802040745u502201e2s5cc968b8041e8c34@mail.gmail.com> <20080204213016.GA23788@eyo32.local> <91705d080802051732k3ba61154p941f22460a464745@mail.gmail.com> Message-ID: <20080206030030.GA27599@eyo32.local> On Tue, Feb 05, 2008 at 05:32:49PM -0800, Dan Nicholson wrote: > You're welcome. I took another look, and I can explain a bit. Try this: > > ./configure ... -Dnonxs_ext='Errno' Diffing the results of that against a plain ./configure ... shows no real difference ie: the makefile still shows: nonxs_ext = ext/Errno/pm_to_blib > and look at $(nonxs_ext) in Makefile. Now, find a Makefile target that > will pull in $(nonxs_ext). :) I couldn't do it cleanly. Ughh, stop punishing me! I think your current solution is just fine :-) Regards Greg From diy-linux-dev@diy-linux.org Mon Feb 11 01:53:50 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 11 Feb 2008 11:53:50 +1100 Subject: perl-5.10.0 Message-ID: <20080211005350.GA26536@eyo32.local> Hi List, Anyone tried the latest Perl? I've taken a quick look and everything looks mostly OK. Couple of things to note: - there is a new test failure in the Syslog module: ext/Sys/Syslog/t/syslog.......................................# Failed test 'setlogsock() should return true: ''' # at ../ext/Sys/Syslog/t/syslog.t line 204. FAILED at test 176 I thought it may have been due to no running syslog in the chroot but then I checked latest Fedora spec file and lo and behold: "Update Sys::Syslog to 0.24, to fix test failures" Looking at the patch itself: [BUGFIX] CPANT-RT#32001: Skip the setlogsock('stream') tests when /dev/log is unavailable (Brendan O'Dea). The mimimal lines from the patch needed to make the testsuite pass are: skip "not testing setlogsock('stream'): _PATH_LOG unavailable", 10 unless -e Sys::Syslog::_PATH_LOG(); I'll make a patch for this. - there is a new module "Compress/Raw/Zlib" which includes a local copy of Zlib source. Probably best to force it to use the system Zlib. The README documents how to do this but this one liner seems to do the trick: sed -i.bak '/BUILD_ZLIB/s/True/False/' ext/Compress/Raw/Zlib/config.in there are other vars in that file controlling -L and -I but they aren't worth worrying about IMHO. -L is definitely no problem and the is identical to the system installed header. - the current seds for GCC-4.2* are no longer needed - something I hadn't noticed before - --prefix defaults to /usr so I can drop this from the chroot cmds. Regards Greg From diy-linux-dev@diy-linux.org Tue Feb 12 04:35:33 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 12 Feb 2008 14:35:33 +1100 Subject: perl-5.10.0 In-Reply-To: <20080211005350.GA26536@eyo32.local> References: <20080211005350.GA26536@eyo32.local> Message-ID: <20080212033533.GA20984@eyo32.local> On Mon, Feb 11, 2008 at 11:53:50AM +1100, Greg Schafer wrote: > The mimimal lines from the patch needed to make the testsuite pass are: > > skip "not testing setlogsock('stream'): _PATH_LOG unavailable", 10 > unless -e Sys::Syslog::_PATH_LOG(); > > I'll make a patch for this. Actually, a sed would be better: sed -i.bak \ "/if grep/a skip \"not testing setlogsock('stream'): _PATH_LOG unavailable\", 10 \ unless -e Sys::Syslog::_PATH_LOG();" \ ext/Sys/Syslog/t/syslog.t > - there is a new module "Compress/Raw/Zlib" which includes a local copy of > Zlib source. Probably best to force it to use the system Zlib. The README > documents how to do this but this one liner seems to do the trick: > > sed -i.bak '/BUILD_ZLIB/s/True/False/' ext/Compress/Raw/Zlib/config.in No sed needed as this seems to work too: make BUILD_ZLIB=False Regards Greg From diy-linux-dev@diy-linux.org Tue Feb 19 00:50:33 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Tue, 19 Feb 2008 10:50:33 +1100 Subject: GCC-4.3 Message-ID: <20080218235033.GA13997@eyo32.local> Hi List, Latest GCC is getting ready for release. I made some time to revisit the 4.3 build to see where we stand. Interesting to note that Fedora essentially skipped 4.2 but are charging full steam ahead with 4.3. - as mentioned before, first and foremost, the 4.3 build requires the GMP and MPFR libraries. Looking at the configury, there is support for building these libs as part of the GCC source tree itself. This would appear to be the safest and most robust method avoiding any host issues. Something like this after cd'ing into the unpacked GCC src dir: bunzip2 -dc ${TT_PFX}/src/tarballs/gmp-4.2.2.tar.bz2 | tar xf - bunzip2 -dc ${TT_PFX}/src/tarballs/mpfr-2.3.1.tar.bz2 | tar xf - mv -v gmp* gmp mv -v mpfr* mpfr (I've used the older tar extraction method for max' compat'. Could probably improve on the above for the Chroot phase) - will need yet another configure switch for GCC Pass1: --disable-decimal-float - Glibc fails to build because GCC's internal include structure has changed. This upstream patch fixes it: http://sourceware.org/ml/glibc-cvs/2008-q1/msg00110.html - The "gcc-4.2-branch-hash-style-gnu-1.patch" no longer applies. Fedora no longer provide the patch as they applied it to their vendor svn branch on gcc.gnu.org. I'll make a new "4.3" patch or maybe a sed. - Tar-1.19 fails to build. Fedora use a patch and the latest tar on alpha.gnu.org has similar changes. Until we get a new tar release, I think I'll just solve it with this instead: ./configure CFLAGS="-O2 -pipe -fgnu89-inline" - Binutils testsuite has some failures in ld which I'm yet to investigate: FAIL: shared (non PIC) FAIL: shared (non PIC, load offset) FAIL: shared (PIC main, non PIC so) - There is a new failure in Glibc testsuite on x86 (yet to investigate): glibc-build/math/test-ildoubl.out] Error 1 - GCC testsuite look OK except for a warning about "Could not compile gcc.dg/compat/struct-layout-1 generator" (yet to investigate): http://gcc.gnu.org/ml/gcc-testresults/2008-02/msg01278.html More later.. Feel free to comment and/or pass on your 4.3 adventures. Looking at the Fedora dev list, a fair number of C++ sources will require patches. Regards Greg PS - if the host GCC is 2.95 or earlier, the build fails. I've reported it upstream and a fix should be forthcoming: http://gcc.gnu.org/ml/gcc/2008-02/msg00315.html From diy-linux-dev@diy-linux.org Wed Feb 20 04:04:17 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Wed, 20 Feb 2008 14:04:17 +1100 Subject: Status update Message-ID: <20080220030417.GA23559@eyo32.local> Hi List, I have received *very* little feedback on the next gen build method. I firmly belive it is a major improvement over the current method and would like to push forward with it. As a first step, I've put up a new gsbuild tarball which defaults to the new method. Hopefully, this will result in more testing coverage. I've basically stopped running builds with the old method. It's just not worth the hassle when the new method is so much better, faster, more flexible, more robust, etc. The new method works with GCC-4.3. tho' I have to do some more 64-bit builds to be sure. I haven't done any PowerPC testing lately because the Mac Mini inexplicably stopped giving me the boot menu and now boots straight into Mac OS X :-( Therefore, the rough plan is this: - make the new build method the Refbuild default - after a few months, phase out the old method I'm aware this plan might have implications for LFS seeing as LFS have been referring to DIY as a kind of "upstream" for toolchain/build method matters. But hopefully the LFS folks will see the benefits and jump on board. In summary, if you haven't done so already, please test the new method and send some feedback. Regards Greg From diy-linux-dev@diy-linux.org Wed Feb 20 07:13:04 2008 From: diy-linux-dev@diy-linux.org (Slava S. Kardakov) Date: Wed, 20 Feb 2008 09:13:04 +0300 Subject: Status update In-Reply-To: <20080220030417.GA23559@eyo32.local> References: <20080220030417.GA23559@eyo32.local> Message-ID: ------=_Part_15585_26060496.1203487984904 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline New method works fine for me (gcc-4.2.3, glibc-2.7). -- Best Regards, Slava S. Kardakov On 2/20/08, Greg Schafer wrote: > > Hi List, > > I have received *very* little feedback on the next gen build method. I > firmly belive it is a major improvement over the current method and would > like to push forward with it. As a first step, I've put up a new gsbuild > tarball which defaults to the new method. Hopefully, this will result in > more testing coverage. > > I've basically stopped running builds with the old method. It's just not > worth the hassle when the new method is so much better, faster, more > flexible, more robust, etc. > > The new method works with GCC-4.3. tho' I have to do some more 64-bit > builds > to be sure. I haven't done any PowerPC testing lately because the Mac Mini > inexplicably stopped giving me the boot menu and now boots straight into > Mac > OS X :-( > > Therefore, the rough plan is this: > > - make the new build method the Refbuild default > - after a few months, phase out the old method > > I'm aware this plan might have implications for LFS seeing as LFS have > been > referring to DIY as a kind of "upstream" for toolchain/build method > matters. > But hopefully the LFS folks will see the benefits and jump on board. > > In summary, if you haven't done so already, please test the new method and > send some feedback. > > Regards > Greg > > __________________________ > Unsubscribe information at > http://www.diy-linux.org/mailman/listinfo/diy-linux-dev > ------=_Part_15585_26060496.1203487984904 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline New method works fine for me (gcc-4.2.3, glibc-2.7).

--
    Best Regards,
       Slava S. Kardakov


On 2/20/08, Greg Schafer <gschafer@zip.com.au> wrote:
Hi List,

I have received *very* little feedback on the next gen build method. I
firmly belive it is a major improvement over the current method and would
like to push forward with it. As a first step, I've put up a new gsbuild
tarball which defaults to the new method. Hopefully, this will result in
more testing coverage.

I've basically stopped running builds with the old method. It's just not
worth the hassle when the new method is so much better, faster, more
flexible, more robust, etc.

The new method works with GCC-4.3. tho' I have to do some more 64-bit builds
to be sure. I haven't done any PowerPC testing lately because the Mac Mini
inexplicably stopped giving me the boot menu and now boots straight into Mac
OS X :-(

Therefore, the rough plan is this:

- make the new build method the Refbuild default
- after a few months, phase out the old method

I'm aware this plan might have implications for LFS seeing as LFS have been
referring to DIY as a kind of "upstream" for toolchain/build method matters.
But hopefully the LFS folks will see the benefits and jump on board.

In summary, if you haven't done so already, please test the new method and
send some feedback.

Regards
Greg

__________________________
Unsubscribe information at
http://www.diy-linux.org/mailman/listinfo/diy-linux-dev

------=_Part_15585_26060496.1203487984904-- From diy-linux-dev@diy-linux.org Wed Feb 20 12:22:20 2008 From: diy-linux-dev@diy-linux.org (Alf mel) Date: Wed, 20 Feb 2008 04:22:20 -0700 Subject: Status update In-Reply-To: <20080220030417.GA23559@eyo32.local> References: <20080220030417.GA23559@eyo32.local> Message-ID: <200802200422.20509.alf@mypals.org> On Tuesday 19 February 2008 08:04:17 pm Greg Schafer wrote: > I have received *very* little feedback on the next gen build method. Sorry. Here goes my feedback. Short: it works well. I have tested 32-bit to 32-bit builds and 32-bit to 64-bit multilib builds. There are some gotchas and I have found one possible problem. (See the long explanation for details.) Long: I've been testing the new build method for about 3 weeks. As you mentioned for LFS, I use DIY-Linux as my upstream build method for my project, SLIM. It wasn't easy to convert the new method to SLIM, but I did manage to make the conversion. One of the first gotchas I ran into was that my Live CD was built with stack protection. As it turns out, building 64-bit libraries in the temptools phase with a 32-bit stack-protected host system simply doesn't work. The first problem is gawk. It builds, it seems to run well, but when configuring coretuils, the resulting Makefile is crap and it simply doesn't work. Removing the new gawk allows the build to continue, but then you won't have a working gawk going into the chroot phase. However, I found it impossible to get to the chroot phase because building perl also triggered stack protection. I didn't find a way to get around that one. The solution was to remaster my entire Live CD with a 32-bit build that didn't include stack protection and that solved the problem. That Live CD is now capable of building both 32-bit and 64-bit systems. The other gotcha I encountered was building a 64-bit kernel from a 32-bit host kernel. Before building binutils a second time, the book says you need to compile a 64-bit kernel, except that every time I would try I would get a GCC error that kernel mode was not supported in 32-bit mode (I can't remember the exact wording). (Yes, I did make sure to use the new x86_64-diy-linux-gnu-gcc.) At that point I used the LFS Live CD to boot into a 64-bit environment and continue the build from there. I think it would be nice to provide exact instructions on how to build a 64-bit kernel in a 32-bit environment. The current "build a 64-bit kernel and reboot into it!" message was not enough to guide me through this process, I'm afraid. :-) Once I got over those hurdles, I was able to build the base systems without problem. The only thing I have encountered is going beyond the book and trying to install nfs-utils 1.1.1. The build fails with "/usr/bin/rpcgen -l -o mount_clnt.c mount .x: cannot find any C preprocessor (cpp)". cpp is installed in /usr/bin, so modifying Makefiles to call rpcgen with "-Y /usr/bin" solves the problem. I really don't know where rpcgen is looking for cpp. (The binary does contain a plain-text reference to /cpp, but I don't know if that's where it is looking). The problem occurs with both Glibc 2.6.1 and Glibc 2.7 in 32-bit and 64-bit. I don't remember having this problem with the old build method. Google shows this post where it says the problem is with the user's installation: http://wiki.linuxfromscratch.org/blfs/ticket/1768 Could someone please check on this for me? Is my build to blame for this problem? Any clues on how to fix it? Anyway, that's my report. Overall I think the new build system is great. -- @ - Alf From diy-linux-dev@diy-linux.org Wed Feb 20 23:42:42 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Thu, 21 Feb 2008 09:42:42 +1100 Subject: Status update In-Reply-To: <200802200422.20509.alf@mypals.org> References: <20080220030417.GA23559@eyo32.local> <200802200422.20509.alf@mypals.org> Message-ID: <20080220224242.GA16967@eyo32.local> On Wed, Feb 20, 2008 at 04:22:20AM -0700, Alf mel wrote: > One of the first gotchas I ran into was that my Live CD was built with > stack protection. As it turns out, building 64-bit libraries in the > temptools phase with a 32-bit stack-protected host system simply doesn't > work. The first problem is gawk. It builds, it seems to run well, but > when configuring coretuils, the resulting Makefile is crap and it simply > doesn't work. Ugh, no ideas about that I'm sorry. You will need to post some exact details of the actual errors so we can try and figure out what's up. > The other gotcha I encountered was building a 64-bit kernel from a 32-bit > host kernel. Before building binutils a second time, the book says you > need to compile a 64-bit kernel, except that every time I would try I would > get a GCC error that kernel mode was not supported in 32-bit mode (I can't > remember the exact wording). (Yes, I did make sure to use the new > x86_64-diy-linux-gnu-gcc.) How did you tell it to use the 64-bit coss-gcc? Clearly, I still have plenty more docs to write, but I just blindly assumed everyone knows how to cross compile a kernel. Sorry about that. It's briefly documented in the main kernel Makefile. Here's an example (I just tested it right now): make mrproper make ARCH=x86_64 defconfig make ARCH=x86_64 CROSS_COMPILE=x86_64-diy-linux-gnu- Obviously you'll want your own config rather than a default defconfig (32-bit emulation *MUST* be enabled of course). And also keep in mind that i386 and x86_64 kernel arches have now merged into "x86" which provides new possibilities, but the basic idea is as above. > The only thing I have encountered is going beyond the book and > trying to install nfs-utils 1.1.1. The build fails > with "/usr/bin/rpcgen -l -o mount_clnt.c mount .x: cannot find any C > preprocessor (cpp)". cpp is installed in /usr/bin, so modifying Makefiles > to call rpcgen with "-Y /usr/bin" solves the problem. Ok, I currently have the cpp thing remmed out in the new build: #ln -sfv ../usr/bin/cpp $PM_DEST/lib I did this because I wasn't sure about the lib64 issue and I also wanted to find out whether any programs still relied on it.. I guess some do :-) > Anyway, that's my report. Overall I think the new build system is great. Thanks for the feedback so far guys. Please keep it coming. Regards Greg From diy-linux-dev@diy-linux.org Fri Feb 22 17:24:28 2008 From: diy-linux-dev@diy-linux.org (Pierre Labastie) Date: Fri, 22 Feb 2008 17:24:28 +0100 Subject: Bug in tar testsuite ? In-Reply-To: <20080220224242.GA16967@eyo32.local> References: <20080220030417.GA23559@eyo32.local> <200802200422.20509.alf@mypals.org> <20080220224242.GA16967@eyo32.local> Message-ID: <47BEF73C.3020509@club-internet.fr> Hello happy Diylinuxers, This report to ask if somebody has seen the same issue with the tar testsuite: It has happenned several times that the test suite of tar failed. At first, I thought it was reproducible, so I did not take note of which test and I tried again. Sometimes it passed, sometimes not... And I am not sure it is always the same test. Today, test 29 failed. Here is the log: ------------------------------------- # -*- compilation -*- 29. listed01.at:26: testing ... ./listed01.at:29: mkdir gnu (cd gnu TEST_TAR_FORMAT=gnu export TEST_TAR_FORMAT TAR_OPTIONS="-H gnu" export TAR_OPTIONS rm -rf * mkdir directory genfile --length 10240 --pattern zeros --file directory/file1 # Let the things settle sleep 1 tar --create \ --file=archive.1 \ --listed-incremental=listing \ directory/file* tar tf archive.1 || exit 1 sleep 1 genfile --length 10240 --pattern zeros --file directory/file2 echo "separator" tar --create \ --file=archive.2 \ --listed-incremental=listing \ directory/file* || exit 1 tar tf archive.2 || exit 1 ) --- - 2008-02-22 11:21:35.184398179 +0100 +++ /home/pkgmgr/src/tar-1.19/tests/testsuite.dir/at-stdout 2008-02-22 11:21 :34.000000000 +0100 @@ -1,4 +1,3 @@ directory/file1 separator -directory/file2 29. listed01.at:26: 29. --listed for individual files (listed01.at:26): FAILED ( listed01.at:29) --------------- This stopped the build. I started again (I use gsbuild, so that it restarts where it failed, with a clean build directory, so that tar is rebuilt from scratch each time), and then the test passed. I started 3 times from the same point (I had made a backup of the whole $SYSROOT hierarchy at the time it failed), and it passed all 3 times... The initial filesystem was reiserfs on lvm (did not pass). The second try was ext3 on a primary partition (pass) the third was reiserfs on the same primary partition (pass) the fourth was back on the same reiserfs on lvm volume (pass !). I have tried to google on it, and I found this thread : http://www.mail-archive.com/bug-tar@gnu.org/msg01652.html which looks quite the same although it is another test. As far as I remember, I think this one failed earlier, but I lose the logs... The bug-tar mailing list does not seem to give a resolution of the issue, but I might not have been able to find it (how does this bug system work ?). Sincerely Pierre From diy-linux-dev@diy-linux.org Sat Feb 23 00:26:45 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sat, 23 Feb 2008 10:26:45 +1100 Subject: Bug in tar testsuite ? In-Reply-To: <47BEF73C.3020509@club-internet.fr> References: <20080220030417.GA23559@eyo32.local> <200802200422.20509.alf@mypals.org> <20080220224242.GA16967@eyo32.local> <47BEF73C.3020509@club-internet.fr> Message-ID: <20080222232645.GA14569@eyo32.local> On Fri, Feb 22, 2008 at 05:24:28PM +0100, Pierre Labastie wrote: > This report to ask if somebody has seen the same issue with the tar > testsuite: > It has happenned several times that the test suite of tar failed. > At first, I thought it was reproducible, so I did not take note of which > test and I tried again. Sometimes it passed, sometimes not... And I am > not sure it is always the same test. Today, test 29 failed. Here is the log: Yes, I used to see these intermittent failures too. It was usually 26 or 29 or both. Inexplicably, the failures stopped for me a few months back. I haven't seen one for a while. However, judging from the various reports to bug-tar, I suspect there is definitely something amiss, probably just a few missing `sleep' statements in the tests. More info here: http://www.mail-archive.com/lfs-book@linuxfromscratch.org/msg09457.html > The bug-tar mailing list does not seem to give a resolution of the > issue, but I might not have been able to find it (how does this bug > system work ?). If you can reproduce it, you should report it. Be sure to send in your log files as per the maintainer's request: http://lists.gnu.org/archive/html/bug-tar/2007-08/msg00009.html Regards Greg From diy-linux-dev@diy-linux.org Sat Feb 23 01:00:19 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sat, 23 Feb 2008 11:00:19 +1100 Subject: GCC-4.3 In-Reply-To: <20080218235033.GA13997@eyo32.local> References: <20080218235033.GA13997@eyo32.local> Message-ID: <20080223000019.GA8659@eyo32.local> On Tue, Feb 19, 2008 at 10:50:33AM +1100, Greg Schafer wrote: > Something like this after cd'ing into the unpacked GCC src dir: > > bunzip2 -dc ${TT_PFX}/src/tarballs/gmp-4.2.2.tar.bz2 | tar xf - > bunzip2 -dc ${TT_PFX}/src/tarballs/mpfr-2.3.1.tar.bz2 | tar xf - > mv -v gmp* gmp > mv -v mpfr* mpfr > > (I've used the older tar extraction method for max' compat'. Could > probably improve on the above for the Chroot phase) For the Chroot phase, I'll use this: if [[ $GCC_VER > 4.2.9 ]]; then tar -xf $TT_PFX/src/tarballs/mpfr-2.3.1.tar.bz2 --transform='s/-2.3.1//' tar -xf $TT_PFX/src/tarballs/gmp-4.2.2.tar.bz2 --transform='s/-4.2.2//' fi > - Tar-1.19 fails to build. Fedora use a patch and the latest tar on > alpha.gnu.org has similar changes. Until we get a new tar release, I > think I'll just solve it with this instead: > > ./configure CFLAGS="-O2 -pipe -fgnu89-inline" Actually, to keep it compatible across versions I'll do this after ./configure: [[ $GCC_VER > 4.2.9 ]] && sed -i.bak '/^CFLAGS/s/$/ -fgnu89-inline/' lib/Makefile > - Binutils testsuite has some failures in ld which I'm yet to investigate: > > FAIL: shared (non PIC) > FAIL: shared (non PIC, load offset) > FAIL: shared (PIC main, non PIC so) Latest HJL release still has these failures, but latest checkout from CVS head doesn't. I can't pinpoint exactly which patch fixes these so I'm thinking the next HJL release will probably be best for GCC-4.3 > - There is a new failure in Glibc testsuite on x86 (yet to investigate): > > glibc-build/math/test-ildoubl.out] Error 1 Interestingly, the failures from GCC-4.2 do not occur (even without the glibc-2.6-x86-math-tests-1.patch). This new failure looks like it can be made to pass by creating a similar patch: testing long double (inline functions) Failure: Test: expm1 (1) == M_El - 1.0 Result: is: 1.71828182845904523532e+00 0xd.bf0a8b14576953500000p-3 should be: 1.71828182845904523543e+00 0xd.bf0a8b14576953600000p-3 difference: 1.08420217248550443401e-19 0x8.00000000000000000000p-66 ulp : 1.0000 max.ulp : 0.0000 Maximal error of `expm1' is : 1 ulp accepted: 0 ulp Test suite completed: 3593 test cases plus 2988 tests for exception flags executed. 2 errors occurred. I've noticed one other oddity with GCC-4.3. A configure test in Bash hangs (times out eventually) which passes with GCC-4.2: checking for working mktime... no This results in the included mktime being used instead of the system supplied one. Will investigate.. Regards Greg From diy-linux-dev@diy-linux.org Sat Feb 23 10:00:14 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sat, 23 Feb 2008 20:00:14 +1100 Subject: GCC-4.3 In-Reply-To: <20080223000019.GA8659@eyo32.local> References: <20080218235033.GA13997@eyo32.local> <20080223000019.GA8659@eyo32.local> Message-ID: <20080223090014.GA17917@eyo32.local> On Sat, Feb 23, 2008 at 11:00:19AM +1100, Greg Schafer wrote: > I've noticed one other oddity with GCC-4.3. A configure test in Bash hangs > (times out eventually) which passes with GCC-4.2: > > checking for working mktime... no > > This results in the included mktime being used instead of the system > supplied one. Will investigate.. Looks like Gawk is also affected. Essentially, any package affected by this issue needs to be repackaged with a newer (unreleased?) Autoconf. http://lists.gnu.org/archive/html/autoconf-patches/2006-12/msg00100.html We can work around it for now by overriding the test: ./configure ac_cv_func_working_mktime=yes Regards Greg From diy-linux-dev@diy-linux.org Sat Feb 23 21:34:55 2008 From: diy-linux-dev@diy-linux.org (Jeremy Huntwork) Date: Sat, 23 Feb 2008 15:34:55 -0500 Subject: Status update In-Reply-To: <20080220030417.GA23559@eyo32.local> References: <20080220030417.GA23559@eyo32.local> Message-ID: <47C0836F.2050103@linuxfromscratch.org> Greg Schafer wrote: > The new method works with GCC-4.3. tho' I have to do some more 64-bit builds > to be sure. I haven't done any PowerPC testing lately because the Mac Mini > inexplicably stopped giving me the boot menu and now boots straight into Mac > OS X :-( Sounds like a yaboot problem. Have you tried setting it up again from a powerpc rescue CD? Anyway, I have a G4 here collecting dust. If you want me to try out your build method using your scripts, I can do so, although it might take a day or so to finish. -- JH From diy-linux-dev@diy-linux.org Sun Feb 24 00:47:59 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sun, 24 Feb 2008 10:47:59 +1100 Subject: Status update In-Reply-To: <20080220224242.GA16967@eyo32.local> References: <20080220030417.GA23559@eyo32.local> <200802200422.20509.alf@mypals.org> <20080220224242.GA16967@eyo32.local> Message-ID: <20080223234759.GA3594@eyo32.local> On Thu, Feb 21, 2008 at 09:42:42AM +1100, Greg Schafer wrote: > On Wed, Feb 20, 2008 at 04:22:20AM -0700, Alf mel wrote: > > The only thing I have encountered is going beyond the book and > > trying to install nfs-utils 1.1.1. The build fails > > with "/usr/bin/rpcgen -l -o mount_clnt.c mount .x: cannot find any C > > preprocessor (cpp)". cpp is installed in /usr/bin, so modifying Makefiles > > to call rpcgen with "-Y /usr/bin" solves the problem. > > Ok, I currently have the cpp thing remmed out in the new build: > > #ln -sfv ../usr/bin/cpp $PM_DEST/lib > > I did this because I wasn't sure about the lib64 issue and I also wanted to > find out whether any programs still relied on it.. I guess some do :-) Ok, it looks like /lib/cpp is hardwired in the Glibc source for rpcgen. lib64 doesn't come into it. In other words, rpcgen is broken without the symlink. I'll re-enable it. Regards Greg From diy-linux-dev@diy-linux.org Sun Feb 24 16:15:16 2008 From: diy-linux-dev@diy-linux.org (Michael Roderick) Date: Sun, 24 Feb 2008 07:15:16 -0800 (PST) Subject: bug in gcc-pass2? In-Reply-To: <20080223165621.11501.38954.Mailman@kanangra.vm.bytemark.co.uk> Message-ID: <224923.61069.qm@web55908.mail.re3.yahoo.com> --0-1267262468-1203866116=:61069 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In the temptools phase (x86 build), the new gsbuild dies in gcc-pass2 after symlinking /temptools/bin/cc to gcc with the following error: attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libbogus.so failed attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libbogus.a failed Oops ERROR: build of "gcc-pass2" failed! Is there something radically simple I'm not thinking about here, or did I neglect a critical step somewhere? Mike --0-1267262468-1203866116=:61069 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In the temptools phase (x86 build), the new gsbuild dies in gcc-pass2 after symlinking /temptools/bin/cc to gcc with the following error:

attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libbogus.so failed
attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libbogus.a failed
Oops

ERROR: build of "gcc-pass2" failed!

Is there something radically simple I'm not thinking about here, or did I neglect a critical step somewhere?

Mike
--0-1267262468-1203866116=:61069-- From diy-linux-dev@diy-linux.org Sun Feb 24 21:49:21 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Mon, 25 Feb 2008 07:49:21 +1100 Subject: bug in gcc-pass2? In-Reply-To: <224923.61069.qm@web55908.mail.re3.yahoo.com> References: <20080223165621.11501.38954.Mailman@kanangra.vm.bytemark.co.uk> <224923.61069.qm@web55908.mail.re3.yahoo.com> Message-ID: <20080224204921.GA12889@eyo32.local> On Sun, Feb 24, 2008 at 07:15:16AM -0800, Michael Roderick wrote: > In the temptools phase (x86 build), the new gsbuild dies in gcc-pass2 > after symlinking /temptools/bin/cc to gcc with the following error: > > attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libbogus.so failed > attempt to open /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libbogus.a failed > Oops > > ERROR: build of "gcc-pass2" failed! > > Is there something radically simple I'm not thinking about here, or did I > neglect a critical step somewhere? Hmm,, it's failing the sanity check. ie: for some reason it's still searching for libs on the host when it shouldn't.. I'm asuming you're building GCC 4.2.3 and you also have that same version installed on this host, yes? I might have to rethink the sanity check. Please execute: echo 'main(){}' | cc -x c -lbogus -v -Wl,--verbose - &> foo and send me off-list the contents of "foo". Thanks. Regards Greg From diy-linux-dev@diy-linux.org Mon Feb 25 17:25:34 2008 From: diy-linux-dev@diy-linux.org (Pierre Labastie) Date: Mon, 25 Feb 2008 17:25:34 +0100 Subject: bug in gcc-pass2? In-Reply-To: <20080224204921.GA12889@eyo32.local> References: <20080223165621.11501.38954.Mailman@kanangra.vm.bytemark.co.uk> <224923.61069.qm@web55908.mail.re3.yahoo.com> <20080224204921.GA12889@eyo32.local> Message-ID: <47C2EBFE.2050705@club-internet.fr> Greg Schafer a =E9crit : > On Sun, Feb 24, 2008 at 07:15:16AM -0800, Michael Roderick wrote: > > =20 >> In the temptools phase (x86 build), the new gsbuild dies in gcc-pass2 >> [...] >> =20 > [...] > > I'm asuming you're building GCC 4.2.3 and you also have that same versi= on > installed on this host, yes? I might have to rethink the sanity check.[= ...] > =20 Just to let you know that the build with the latest gsbuild, and=20 NEXT_GEN_BUILD=3Dy, on Debian Lenny (that is with GCC 4.2.3) worked to=20 completion on my computer (save for the random failures in the tar=20 testsuite). I know that the "it worked for me" things are not of great=20 help, but since you seem to think that the host gcc might be the issue... Added before sending : it passes with NEXT_GEN_BUILD=3Dn, too. Below is the result of --dry-run, of {gcc,ld} --version on the host and=20 of /lib/libc.so.6 ------------------------build@b07-cluster:/temptools/src/gsbuild$=20 ./gsbuild.sh --dry-run Finding tarballs and verifying their md5sums... done. Options Summary: Next Gen Build Method: Yes Target: i686-diy-linux-gnu Bi-arch: No ICA Build: No Normal Test Suites: Yes Optional Test Suites: No Kernel Headers: linux-kernel-headers NLS Build: Yes Log Debug: No PM Build: Yes (PACMAN) GCC Version: 4.2.3 GLibc Version: 2.7 Binutils Version: 2.18 SUCCESS: All pre-build sanity checks passed! --------------------------- build@b07-cluster:/temptools/src/gsbuild$ gcc --version gcc (GCC) 4.2.3 (Debian 4.2.3-1) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is N= O warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOS= E. ---------------------------- build@b07-cluster:/temptools/src/gsbuild$ ld --version GNU ld (GNU Binutils for Debian) 2.18.0.20080103 Copyright 2007 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) a later=20 version. This program has absolutely no warranty. ----------------------------- build@b07-cluster:/temptools/src/gsbuild$ /lib/libc.so.6 GNU C Library stable release version 2.7, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ------------------------------ build@b07-cluster:/temptools/src/gsbuild$ uname -a Linux b07-cluster 2.6.22-3-686 #1 SMP Sun Feb 10 20:20:49 UTC 2008 i686=20 GNU/Linux ------------------------------ Regards Pierre From diy-linux-dev@diy-linux.org Thu Feb 28 04:18:15 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Thu, 28 Feb 2008 14:18:15 +1100 Subject: Status update In-Reply-To: <20080220030417.GA23559@eyo32.local> References: <20080220030417.GA23559@eyo32.local> Message-ID: <20080228031815.GA1324@eyo32.local> On Wed, Feb 20, 2008 at 02:04:17PM +1100, Greg Schafer wrote: > The new method works with GCC-4.3. tho' I have to do some more 64-bit builds > to be sure. Bugger.. just hit a major snag with 64-bit multilib. GCC-Pass2 craps out when building the shared libgcc. Can't find the startfiles: /temptools/x86_64-unknown-linux-gnu/bin/ld: crti.o: No such file: No such file or directory As of GCC 4.3, libgcc has moved to the top level in the build system. This could be a real nasty one to pin down.. wish me luck.. > I haven't done any PowerPC testing lately because the Mac Mini > inexplicably stopped giving me the boot menu and now boots straight into Mac > OS X :-( I have this back now as Jeremy's suggestion to run yaboot from a rescue cd did the trick. PowerPC testing can now happen. Regards Greg From diy-linux-dev@diy-linux.org Fri Feb 29 16:15:05 2008 From: diy-linux-dev@diy-linux.org (George Makrydakis) Date: Fri, 29 Feb 2008 17:15:05 +0200 Subject: Hello everyone, a small announcement Message-ID: <200802291715.05837.gmakmail@gmail.com> Hello everyone, Some of you know about this already, but here it goes: Here is where the proposal I have been talking about is to have home: http://progress.odreex.org All code is original and no one but yours truly has contributed to what you are to receive. The design is also of yours truly and it started more than one year ago (on/off development for various reasons). The initial release aims at developers, the goal is to provide a completely agnostic system building platform, without any dependencies to the end users, but a working C++ compiler. Internationalization is embedded in the system, it is XML oriented, it abstracts package management. For those interested in a web - counterpart, it has already been taken care of. I am to release a first important set of features, this release does not give a complete toolkit, but a toolkit for people to use and develop their own books, the way they want them without anyone calling the shots. That is, there is no hardcoding, unlike what you find in current automation methods, the end user calls the shots. The way they want it, they way they don't want it, they can even build their own builder to do things differently if they wish to. I would have a lot more to say, but it is neither the place, or the time. What is odreex? A component framework. A library set. A toolkit. A swiss army knife. Expect the release tomorrow at some point. Mailing lists at: http://lists.odreex.org Enjoy George Makrydakis From diy-linux-dev@diy-linux.org Fri Feb 29 16:42:49 2008 From: diy-linux-dev@diy-linux.org (Dan Nicholson) Date: Fri, 29 Feb 2008 07:42:49 -0800 Subject: Hello everyone, a small announcement In-Reply-To: <200802291715.05837.gmakmail@gmail.com> References: <200802291715.05837.gmakmail@gmail.com> Message-ID: <91705d080802290742t3e53bf83qd6b28b1389b5c555@mail.gmail.com> On Fri, Feb 29, 2008 at 7:15 AM, George Makrydakis wrote: > Hello everyone, > > Some of you know about this already, but here it goes: > > Here is where the proposal I have been talking about is to have home: > > http://progress.odreex.org > > All code is original and no one but yours truly has contributed to what you > are to receive. The design is also of yours truly and it started more than one > year ago (on/off development for various reasons). Where's the code? I didn't see anything about checking out the sources. Thanks. -- Dan From diy-linux-dev@diy-linux.org Fri Feb 29 19:52:07 2008 From: diy-linux-dev@diy-linux.org (George Makrydakis) Date: Fri, 29 Feb 2008 20:52:07 +0200 Subject: Hello everyone, a small announcement In-Reply-To: <91705d080802290742t3e53bf83qd6b28b1389b5c555@mail.gmail.com> References: <200802291715.05837.gmakmail@gmail.com> <91705d080802290742t3e53bf83qd6b28b1389b5c555@mail.gmail.com> Message-ID: <200802292052.07366.gmakmail@gmail.com> On Friday 29 February 2008 17:42:49 Dan Nicholson wrote: > On Fri, Feb 29, 2008 at 7:15 AM, George Makrydakis wrote: > > Hello everyone, > > > > Some of you know about this already, but here it goes: > > > > Here is where the proposal I have been talking about is to have home: > > > > http://progress.odreex.org > > > > All code is original and no one but yours truly has contributed to what > > you are to receive. The design is also of yours truly and it started more > > than one year ago (on/off development for various reasons). > > Where's the code? I didn't see anything about checking out the sources. Hello Dan, thank you for your interest, as I state in the same posting: > On Fri, Feb 29, 2008 at 7:15 AM, George Makrydakis wrote: > > Expect the release tomorrow at some point. Mailing lists at: > > > > http://lists.odreex.org > > > >Enjoy So it is tomorrow (Saturday, my timezone is GMT + 2 now), I am doing some testing and writing some examples on how to use it. > Thanks. Thank you for your interest. > -- > Dan > > __________________________ > Unsubscribe information at > http://www.diy-linux.org/mailman/listinfo/diy-linux-dev George