Serious Bugs In Gcc Builds

[Dave Korn]

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=<path>
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....