From diy-linux-dev@diy-linux.org Sat Mar 1 23:52:15 2008 From: diy-linux-dev@diy-linux.org (George Makrydakis) Date: Sun, 2 Mar 2008 00:52:15 +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: <200803020052.15204.george@obsethryl.eu> 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. > > Thanks. > > -- > Dan A minor update: The private "talk" between me and the interested parties in LFS did not bear any fruit but prove beyond doubt a simple fact: as usual, LFS "leaders" have their own view of reality, right and wrong that does not exactly stick with facts. I have to postpone because right now I need to take my time offline and think about this very well. It is a question of what will be done, how it will be done in order to make things work to the benefit of the good guys. Excuse my haste in announcing the release, I had my reasons that are to be explained. I will be continuing to provide information to the interested parties via my site: http://lab.obsethryl.eu and the mailing list for the project http://lists.odreex.org Thank you, should you decide to keep this thread up Greg, and thanks again for the interest Dan. I will be reposting here only on the effective release, which will be done within reasonable time. George From diy-linux-dev@diy-linux.org Sun Mar 2 05:31:46 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sun, 2 Mar 2008 15:31:46 +1100 Subject: GCC 4.3 build method breakage (was Re: Status update) In-Reply-To: <20080228031815.GA1324@eyo32.local> References: <20080220030417.GA23559@eyo32.local> <20080228031815.GA1324@eyo32.local> Message-ID: <20080302043146.GA556@eyo32.local> On Thu, Feb 28, 2008 at 02:18:15PM +1100, Greg Schafer wrote: > 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.. Ok, it appears that libgcc moving to the toplevel is not the cause. Rather, it's due to an upstream change in the GCC driver (gcc.c) to make "relocated" toolchains function better. This is a very subtle change that most folks won't notice. I've posted a note to the GCC list but I suspect there will be little interest because very few folks are affected: http://gcc.gnu.org/ml/gcc/2008-03/msg00095.html In detail, during the GCC build process, after GCC itself is built, the just-built GCC is then used to compile libgcc* and the other target libraries (libstdc++, libgomp etc). Up to GCC 4.2.3, this just-built GCC would find and use the startfiles in $prefix (ie: /temptools/lib) which is exactly what we want. But 4.3 does not. The only reason why my 4.3 x86 builds are successful is that during this window in the GCC Pass 2 build process, startfiles from the *host* are being used!! The 64-bit builds are not using the host's startfiles because (1) they can't if the host is 32-bit or (2) I am nullifying STANDARD_STARTFILE_PREFIX_{1,2}, which of course then results in build failure. GCC 4.3 starts behaving properly once it gets installed into $TT_PFX. If upstream won't fix this, I'll have to find a way around it. One possibility is to use startfile_prefix_spec . But I'd rather not use this for all the reasons documented in the past, with the most important being it cannot be overriden with -specs= on the command line. Unless of course we apply a patch to the Pass 2 GCC to restore the 1999 behaviour. It'll break java, but then that doesn't matter for the temptools: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19353#c7 Another option might be to find a way to jam some -B's into the Makefiles but that feels kinda messy and might not work for multilib.. Has anyone else started playing with GCC 4.3? Does anyone have the C coding ability to understand the finer details of the inner workings of gcc.c ? I certainly don't.. Regards Greg From diy-linux-dev@diy-linux.org Sun Mar 2 09:48:44 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sun, 2 Mar 2008 19:48:44 +1100 Subject: GCC 4.3 build method breakage (was Re: Status update) In-Reply-To: <20080302043146.GA556@eyo32.local> References: <20080220030417.GA23559@eyo32.local> <20080228031815.GA1324@eyo32.local> <20080302043146.GA556@eyo32.local> Message-ID: <20080302084844.GA15181@eyo32.local> On Sun, Mar 02, 2008 at 03:31:46PM +1100, Greg Schafer wrote: > If upstream won't fix this, I'll have to find a way around it. One > possibility is to use startfile_prefix_spec . > Another option might be to find a way to jam some -B's into the Makefiles > but that feels kinda messy and might not work for multilib.. Or better still, just revert the few lines that cause the actual problem. The following patch to GCC Pass 2 seems to do the trick. Regards Greg diff -Naur gcc-4.3.0-RC-20080222.orig/gcc/gcc.c gcc-4.3.0-RC-20080222/gcc/gcc.c --- gcc-4.3.0-RC-20080222.orig/gcc/gcc.c 2008-01-24 18:57:12.000000000 +0000 +++ gcc-4.3.0-RC-20080222/gcc/gcc.c 2008-03-02 06:07:36.000000000 +0000 @@ -6370,6 +6370,11 @@ machine_suffix, standard_startfile_prefix, NULL), NULL, PREFIX_PRIORITY_LAST, 0, 1); + add_prefix (&startfile_prefixes, + concat (standard_exec_prefix, + machine_suffix, + standard_startfile_prefix, NULL), + NULL, PREFIX_PRIORITY_LAST, 0, 1); } /* Sysrooted prefixes are relocated because target_system_root is From diy-linux-dev@diy-linux.org Wed Mar 5 22:18:47 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Thu, 6 Mar 2008 08:18:47 +1100 Subject: GCC 4.3 build method breakage (was Re: Status update) In-Reply-To: <20080302043146.GA556@eyo32.local> References: <20080220030417.GA23559@eyo32.local> <20080228031815.GA1324@eyo32.local> <20080302043146.GA556@eyo32.local> Message-ID: <20080305211847.GA25652@eyo32.local> On Sun, Mar 02, 2008 at 03:31:46PM +1100, Greg Schafer wrote: > Ok, it appears that libgcc moving to the toplevel is not the cause. Rather, > it's due to an upstream change in the GCC driver (gcc.c) to make "relocated" > toolchains function better. This is a very subtle change that most folks > won't notice. I've posted a note to the GCC list but I suspect there will be > little interest because very few folks are affected: > > http://gcc.gnu.org/ml/gcc/2008-03/msg00095.html There was little interest as I suspected :-( I'm just going to run with the patch I posted for now. T'is a shame that GCC folks apparently don't care if they break existing setups everywhere that have been working for years. Reading between the lines, "relocated" toolchains are used heavily by the commercial entity "Codesourcery" and they also now provide GCC based toolchains for Windows that can, for example, target Google's Android platform. I suspect there are powerful forces at work here :-( I'm only concerned with the new build method, but the old method is also impacted, which means this also hits LFS. The changes in question are also responsible for the other testsuite issue I mentioned earlier: WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator Anyhoo, 4.3 is now released. I have most of it ready and will commit soon. The old method will not be supported for 4.3 so I'll also work on switching over to defaulting to the new method. While I'm at it, I'm also going to get rid of LLH. It's there only for the older GCC-3.4.6 based toolchain. But that older toolchain seems to work fine with headers_install headers and does work with the new build method, albeit with an additional patch on x86. Regards Greg From diy-linux-dev@diy-linux.org Thu Mar 6 02:37:07 2008 From: diy-linux-dev@diy-linux.org (Rich Edelman) Date: Wed, 5 Mar 2008 19:37:07 -0600 Subject: GCC 4.3 build method breakage (was Re: Status update) In-Reply-To: <20080305211847.GA25652@eyo32.local> References: <20080220030417.GA23559@eyo32.local> <20080302043146.GA556@eyo32.local> <20080305211847.GA25652@eyo32.local> Message-ID: <200803051937.08042.rcedelman@comcast.net> On Wednesday 05 March 2008 15:18, Greg Schafer wrote: > There was little interest as I suspected :-( I'm just going to run with > the patch I posted for now. T'is a shame that GCC folks apparently don't > care if they break existing setups everywhere that have been working for > years. Reading between the lines, "relocated" toolchains are used heavily > by the commercial entity "Codesourcery" and they also now provide GCC based > toolchains for Windows that can, for example, target Google's Android > platform. I suspect there are powerful forces at work here :-( I kind of suspect it may be possible to fix this using some combination of GCC_EXEC_PREFIX or something, but I'm not smart enough to figure it out. IMO, your patch is a better fix, it's just too bad that the GCC folks don't agree. > Anyhoo, 4.3 is now released. I have most of it ready and will commit soon. > The old method will not be supported for 4.3 so I'll also work on switching > over to defaulting to the new method. While I'm at it, I'm also going to > get rid of LLH. It's there only for the older GCC-3.4.6 based toolchain. > But that older toolchain seems to work fine with headers_install headers > and does work with the new build method, albeit with an additional patch on > x86. Well, it's not quite released. The latest -rc looks really good, but there hasn't yet been a release announcement on gcc-announce that I've seen, nor is it yet available at ftp.gnu.org/gnu/gcc. Good to know that you have the refbuild ready, though. Rich From diy-linux-dev@diy-linux.org Thu Mar 6 02:55:22 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Thu, 6 Mar 2008 12:55:22 +1100 Subject: GCC 4.3 build method breakage (was Re: Status update) In-Reply-To: <200803051937.08042.rcedelman@comcast.net> References: <20080220030417.GA23559@eyo32.local> <20080302043146.GA556@eyo32.local> <20080305211847.GA25652@eyo32.local> <200803051937.08042.rcedelman@comcast.net> Message-ID: <20080306015521.GA5839@eyo32.local> On Wed, Mar 05, 2008 at 07:37:07PM -0600, Rich Edelman wrote: > I kind of suspect it may be possible to fix this using some combination of > GCC_EXEC_PREFIX or something, but I'm not smart enough to figure it out. IMO, > your patch is a better fix, it's just too bad that the GCC folks don't agree. Yeah, I'm trying to figure out other options. Carrying a patch around forever is not ideal.. even if it's only for the temporary GCC Pass 2. > Well, it's not quite released. The latest -rc looks really good, but there > hasn't yet been a release announcement on gcc-announce that I've seen, nor is > it yet available at ftp.gnu.org/gnu/gcc. Good to know that you have the > refbuild ready, though. That's true. However, toolchain package releases tend to show up on sourceware.org first before they make their way to ftp.gnu.org. They also delay the release announcemnt to allow mirrors to catch up. ftp://sourceware.org/pub/gcc/releases Regards Greg PS - Rich, not sure whether you received my reply the other day. I received some crazy mesage from my ISP's mail server. I suspect Comcast are being over-zealous with their anti-spam methods. If you never received it, I'll try again from a Gmail account. From diy-linux-dev@diy-linux.org Thu Mar 6 16:43:16 2008 From: diy-linux-dev@diy-linux.org (diy-linux-dev@diy-linux.org) Date: Thu, 06 Mar 2008 15:43:16 +0000 Subject: GCC 4.3 build method breakage (was Re: Status update) Message-ID: <030620081543.21719.47D0111400058654000054D72200734364020E03040A0B0A0C9D@comcast.net> From: Greg Schafer > That's true. However, toolchain package releases tend to show up on > sourceware.org first before they make their way to ftp.gnu.org. They also > delay the release announcemnt to allow mirrors to catch up. > > ftp://sourceware.org/pub/gcc/releases Thanks for pointing that out. I was a bit confused when you said 4.3.0 was released.. I spent some time looking for it but never thought to look on sourceware.org. > PS - Rich, not sure whether you received my reply the other day. I received > some crazy mesage from my ISP's mail server. I suspect Comcast are being > over-zealous with their anti-spam methods. If you never received it, I'll > try again from a Gmail account. > Yeah I never got your response. :( Comcast lately has been pretty restrictive on email. I guess it's time to switch everything over to my gmail account. Feel free to re-send your response there as well: redelman at gmail dot com. Thanks! From diy-linux-dev@diy-linux.org Fri Mar 21 23:06:11 2008 From: diy-linux-dev@diy-linux.org (Greg Schafer) Date: Sat, 22 Mar 2008 09:06:11 +1100 Subject: GCC 4.3 build method breakage (was Re: Status update) In-Reply-To: <20080306015521.GA5839@eyo32.local> References: <20080220030417.GA23559@eyo32.local> <20080302043146.GA556@eyo32.local> <20080305211847.GA25652@eyo32.local> <200803051937.08042.rcedelman@comcast.net> <20080306015521.GA5839@eyo32.local> Message-ID: <20080321220611.GA14281@eyo32.local> On Thu, Mar 06, 2008 at 12:55:22PM +1100, Greg Schafer wrote: > On Wed, Mar 05, 2008 at 07:37:07PM -0600, Rich Edelman wrote: > > > I kind of suspect it may be possible to fix this using some combination of > > GCC_EXEC_PREFIX or something, but I'm not smart enough to figure it out. IMO, > > your patch is a better fix, it's just too bad that the GCC folks don't agree. > > Yeah, I'm trying to figure out other options. Carrying a patch around > forever is not ideal.. even if it's only for the temporary GCC Pass 2. Well, that took longer than I thought. GCC Devs are definitely not going to change it: http://gcc.gnu.org/PR35532 (Sidenote: how's this for a quotable quote "By building gcc you become a gcc developer, not a user" yeah right..) I tried looking for other ways around this problem, but none of the things I tried work with multilib. For example, adding -B$TT_PFX/lib/ to FLAGS_FOR_TARGET does the right thing for x86, but -B doesn't process the multilibs for startfile_prefixes. I then thought that changing the behaviour of -B to be more intuitive and actually process the multilibs might be worth a shot. Turns out that it's not so simple: http://gcc.gnu.org/ml/gcc/2008-03/msg00547.html In summary, I'll just stick with the patch. It's not such a huge deal. One interesting thing to come out of this episode is that the pro's are now starting to use sysrooted toolchains for native builds. But at this stage, I don't think that style of build is well suited for our use case. We intentionally go to great lengths to avoid any chance of stuffups with finding files on the host. On that note, I'm making a small change to GCC Pass 2. The current x86_64 only hacks to STANDARD_STARTFILE_PREFIX_{1,2} will now apply to all builds. It's the only safe way to ensure the host isn't searched. ie: echo ' /* Remove /usr/include from include search path. */ #undef STANDARD_INCLUDE_DIR #define STANDARD_INCLUDE_DIR 0 /* Remove /lib and /usr/lib from startfiles search path. */ #define STANDARD_STARTFILE_PREFIX_1 "" #define STANDARD_STARTFILE_PREFIX_2 ""' >> gcc/config/$DL_HEADER Regards Greg From diy-linux-dev@diy-linux.org Sat Mar 22 14:58:26 2008 From: diy-linux-dev@diy-linux.org (Alf mel) Date: Sat, 22 Mar 2008 07:58:26 -0600 Subject: GCC 4.3 build method breakage (was Re: Status update) In-Reply-To: <20080321220611.GA14281@eyo32.local> References: <20080220030417.GA23559@eyo32.local> <20080306015521.GA5839@eyo32.local> <20080321220611.GA14281@eyo32.local> Message-ID: <200803220758.26480.alf@mypals.org> On Friday 21 March 2008 04:06:11 pm Greg Schafer wrote: > Well, that took longer than I thought. GCC Devs are definitely not going > to change it: Greg, I truly appreciate your efforts in trying to resolve this (and so many other issues that come up in DIY-Linux) upstream. It seems from this article (http://lwn.net/Articles/272048/) the GCC developers don't care what they break and are not very willing to negotiate. I guess we're all going to have to be good little boys and girls and do what we're told. After all, that's the "open" way of doing things, especially in GNU land. :-) -- @ - Alf