From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25503 invoked by alias); 4 Dec 2007 20:23:06 -0000 Received: (qmail 25490 invoked by uid 22791); 4 Dec 2007 20:23:05 -0000 X-Spam-Check-By: sourceware.org Received: from mail.artimi.com (HELO mail.artimi.com) (194.72.81.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 04 Dec 2007 20:22:54 +0000 Received: from rainbow ([192.168.8.46] RDNS failed) by mail.artimi.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 4 Dec 2007 20:22:51 +0000 From: "Dave Korn" To: "'Thomas Dineen'" , References: <4755A3B9.9060601@ix.netcom.com> Subject: RE: Serious Bugs In Gcc Builds Date: Tue, 04 Dec 2007 20:23:00 -0000 Message-ID: <043501c836b3$71688420$2e08a8c0@CAM.ARTIMI.COM> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <4755A3B9.9060601@ix.netcom.com> Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2007-12/txt/msg00101.txt.bz2 On 04 December 2007 19:00, Thomas Dineen wrote: Hi Thomas. I've removed the main gcc@ list from the Cc: line, because so far I'm not sure we have any real bugs here. We can move the thread back across if/when we determine that there's definitely a bug to be addressed in the build system, or in gcc itself (the gcc@ list isn't responsible for problems in binutils or make), but I think a fair amount of the grief you've received is probably minor piloting error; we'll see as we go along. > Gentle People: > > I am writing to you today to document several serious build > bugs in GCC releases gcc-3.4.6, gcc-4.0.4, and gcc-4.1.2. > To be honest I have wasted several days of work on reflector > interaction and attempts to work around these issues all to no > avail! I have been unable to build a usable gcc on my Solaris 8 > Sparc System! Did you read http://gcc.gnu.org/install/specific.html first? > By the way don't bother flaming back at me I am way beyond > this and thus impervious! Hopefully by fixing the issues documented > below you will open up the GCC software to be usable by a larger > audience of users. These issues aren't /entirely/ well documented; you omit a lot of salient details, which I'll try and draw to your attention as you go along. It sounds like you're quite frustrated by the whole experience, so please try and have patience; posting a rant is of course a great way to let off steam, but the act of and state of mind during writing one isn't always conducive to clear, fully-detailed explanations... > Issue 1) The configure and build scripts insist (read that fight to the > death) on using the solaris linker (/usr/ccs/bin/ld) despite every > effort to the contrary, and this of course causes errors. The following > were my failed efforts to redirect it to the Gnu Linker (/opt/sfw/bin/gld): > a) Providing explicit command line direction to configure. > /export/home/tools/gcc/gcc-4.0.4/configure --with-gnu-ld --with-gnu-as > --with-as=/opt/sfw/bin/as --with-ld=/opt/sfw/bin/ld I wouldn't expect that one to work, since you typed "ld" instead of "gld" when specifying the --with-ld option. What happens if you correct it? > b) Provide links in the object directory attempting to redirect it: > ln -s /opt/sfw/bin/gld ld > c) Provide links in the executable directory attempting to redirect it: > ln -s gld ld > d) Reordering the path so that the Gnu Tools would appear first. > e) Removing the Solaris Linker from the path. Hard to know what's going on here. Missing salient details: did you clean and reconfigure each time, or did all these experiments take place in the same directory one after another? Did you do anything in between these steps at all or nothing? Also, it would be interesting to know what happens if you (temporarily) rename the linker or move it to some random directory where the configure scripts wouldn't know where to look; do they then find the gnu linker, or do they not find any linker at all? > Issue 2) Same as Issue 1 except for the Gnu assembler > (/opt/sfw/bin/gas). Looks like you made the same typo in your configure command as before. > Issue 3) After unzipping and untarring release gcc-4.1.2 I changed > the owner (chown) and file mode (chmod) to values compatible with > my environment. Is there something very unusual in your environment? I've never found it necessary to do this. Salient details missing: 1) why you did this 2) what you chown'd and chgrp'd to. > This caused build errors with make complaining of files > being touched or changes which required a call to makeinfo, and a further > complaint that makeinfo was missing. A subsequent test of makeinfo --version > in the same shell as the attempted build indicated that makeinfo was > present. That's a combination of two things, one to be expected, one a real bug. The to-be-expected bit is that you have re-ordered the timestamps and thus broken the dependencies between generated files and the source files they are generated from, so 'make' believes they are out-of-date and need rebuilding. The fact that it can't find makeinfo is some obscure bug that I think I've run into myself before, but it generally goes away after a clean reconfigure and build. > Issue 4) What's In A Name? Or what the hell should we name it? > When I down load and install various releases of GNU Bintools a > tool like GNU Make is sometimes called gmake and sometimes called > make. If you build and install it from source, it will always be called 'make'. If you download a binary from some random bloke off the internet, there's no way we can control what he/she does by way of naming it. Salient details missing: where you are downloading these releases from, and why you think make is part of binutils (it isn't at all, it's completely separate) and indeed whether "bintools" is another typo or perhaps someone's customised version of GNU binutils. > Issue 5) The build process is way to complicated for the average user > to negotiate successfully. The user interface should be simplified to the > following for a native compiler: > ./configure > gmake > gmake install That's what it already is, and it "just works" on most platforms. Solaris has some complications, mostly relating to historical problems that have existed in both binutils and the native toolchain. Missing salient details: what actually went wrong when you tried this. > - A listing or the commands used in the various build attempts: > ; > ; Gcc Build gcc-3.4.6 > ; > ; Use gmake gls, gas - required! > ; Using csh Well, there's one thing you did wrong. Please do go take a read of the target-specific installation instructions, they say something about using ksh on solaris. > ; Changed $path in /root/.cshrc to put /opt/sfw/bin first to pick up > ; GNU Tools first. > cd /export/home/tools/gcc > gunzip gcc-3.4.6.tar.gz > tar -xvif gcc-3.4.6.tar ; -i -> Ignore directory checksum errors. That's distressing. Missing salient details: Why are you ignoring checksum errors? If there's a checksum error, doesn't that mean something's gone horribly wrong? How can you be sure if you've downloaded a corrupted version of the tarball or not? Do you know for a fact whether your hard drive is faulty or not? > ln -s /opt/sfw/bin/gmake make > ln -s /opt/sfw/bin/gld ld > ln -s /opt/sfw/bin/gas as > /export/home/tools/gcc/gcc-3.4.6/configure --with-gnu-ld --with-gnu-as > --with-as=/opt/sfw/bin/as --with-ld=/opt/sfw/bin/ld Ok, you've created links that don't begin with 'g' in the object directory to all the files in /opt/sfw/bin where they do begin with 'g', then you've told configure to look for the wrong name in the wrong dir. First thing I'd try is not bothering with the links, and just correct the --with-as/ld= options. Anyway, there's a few bits of info for you to gather, a few bits of reading for you, and a few experiments to try. I don't have access to a solaris system these days, but AFAIK there are quite a few people who regularly do build solaris gcc, so it must be possible! cheers, DaveK -- Can't think of a witty .sigline today....