Serious Bugs In Gcc Builds

Serious Bugs In Gcc Builds

[Thomas Dineen]

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!

       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.

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

Issue 2) Same as Issue 1 except for the Gnu assembler
(/opt/sfw/bin/gas).

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

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. This causes confusion and thus errors in that the Gcc build scripts
use make. I would suggest standardizing on the names to prevent confusion.
To this end I would suggest that GNU Make always, always, always be
called gmake and when you want to use GNU Make in your project that
you type gmake.

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

- A listing or the commands used in the various build attempts:
;
; Gcc Build gcc-3.4.6
;
; Use gmake gls, gas - required!
; Using csh
; 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.
mkdir gcc-3.4.6-obj
chmod 777 gcc-3.4.6-obj
cd gcc-3.4.6-obj
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
gmake DESTDIR=/export/home/tools/gcc/gcc-3.4.6-bin install

;
; Gcc Build gcc-4.0.4
;
; Use gmake gls, gas - required!
; Using csh
cd /export/home/tools/gcc
gunzip gcc-4.0.4.tar.gz
tar -xvif gcc-4.0.4.tar   ; -i -> Ignore directory checksum errors.
cd gcc-4.0.4-obj
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-4.0.4/configure  --with-gnu-ld  --with-gnu-as 
--with-as=/opt/sfw/bin --with-ld=/opt/sfw/bin
gmake DESTDIR=/export/home/tools/gcc/gcc-4.0.4-bin install

;
; Gcc Build gcc-4.1.2
;
; Use gmake gls, gas - required!
; Using csh
cd gcc-4.1.2-obj
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-4.1.2/configure  --with-gnu-ld  --with-gnu-as 
--with-as=/opt/sfw/bin --with-ld=/opt/sfw/bin
gmake DESTDIR=/export/home/tools/gcc/gcc-4.1.2-bin install







 

Re: Serious Bugs In Gcc Builds

[Peter A. Friend]

On Dec 4, 2007, at 11:00 AM, Thomas Dineen wrote:

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

Well, if one politely requests help it generally will not result in  
flames.

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

Why do you wish to use GNU ld and as? On Solaris systems I have  
always used Sun ld and as, and if I recall correctly, the older GCC  
documentation would tell you to do that. I don't immediately recall  
what the issue was, and I don't know if it's still an issue. If there  
is a specific need to use GNU ld and as then perhaps someone else can  
chime in on this one.

> 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. This causes confusion and thus errors in that the Gcc build  
> scripts
> use make. I would suggest standardizing on the names to prevent  
> confusion.
> To this end I would suggest that GNU Make always, always, always be
> called gmake and when you want to use GNU Make in your project that
> you type gmake.

I don't see how this is a GNU bug, it's more of a development  
environment issue. When we install GNU make we install it as "make"  
and also provide a hard link as "gmake". If it was only installed as  
gmake then people would have to alter all of their stuff (something  
they may not have access to do) to call gmake.

For my Solaris environment I have the GNU tools in my path first,  
followed by /usr/ccs/bin. This makes sure that GNU versions of m4,  
grep, sed and make are used, and Sun versions of as and ld are used.


> 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

The build procedure for GCC can be cumbersome. There are a lot of  
options, a lot of systems to support, and a lot of ways for the  
procedure to break. This in itself is an argument against average  
users trying to attempt builds themselves.

Cheers,

Peter

Re: Serious Bugs In Gcc Builds

[Thomas Dineen]

Peter:

     I think the idea here is the make the S/W easier to access and use,
thus opening up the user base to become hopefully larger, maybe
exponentially larger. Keep in mind I and one of the biggest supporters
or fans of GNU Freeware, and conversely one of the biggest haters of
Microsoft. To destroy MS you must make your tools easier to access
and use, to the point of being usable by the average user. BTW my
skills are well beyond average and if I cannot succeed here a large number
of even knowledgeable users will not succeed here.

Thomas Dineen

Peter A. Friend wrote:

>
> On Dec 4, 2007, at 11:00 AM, Thomas Dineen wrote:
>
>>
>>        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.
>
>
> Well, if one politely requests help it generally will not result in  
> flames.
>
>>
>> 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
>> 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.
>
>
> Why do you wish to use GNU ld and as? On Solaris systems I have  
> always used Sun ld and as, and if I recall correctly, the older GCC  
> documentation would tell you to do that. I don't immediately recall  
> what the issue was, and I don't know if it's still an issue. If there  
> is a specific need to use GNU ld and as then perhaps someone else can  
> chime in on this one.
>
>> 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. This causes confusion and thus errors in that the Gcc build  
>> scripts
>> use make. I would suggest standardizing on the names to prevent  
>> confusion.
>> To this end I would suggest that GNU Make always, always, always be
>> called gmake and when you want to use GNU Make in your project that
>> you type gmake.
>
>
> I don't see how this is a GNU bug, it's more of a development  
> environment issue. When we install GNU make we install it as "make"  
> and also provide a hard link as "gmake". If it was only installed as  
> gmake then people would have to alter all of their stuff (something  
> they may not have access to do) to call gmake.
>
> For my Solaris environment I have the GNU tools in my path first,  
> followed by /usr/ccs/bin. This makes sure that GNU versions of m4,  
> grep, sed and make are used, and Sun versions of as and ld are used.
>
>
>> 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
>
>
> The build procedure for GCC can be cumbersome. There are a lot of  
> options, a lot of systems to support, and a lot of ways for the  
> procedure to break. This in itself is an argument against average  
> users trying to attempt builds themselves.
>
> Cheers,
>
> Peter
>
>
>

Re: Serious Bugs In Gcc Builds

[Eric Botcazou]

[Please do not cross post between lists, it's gcc-help material]

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

Everything is documented so there is not much to fix.  See in particular
http://gcc.gnu.org/install and the pages linked to from there.

> 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

There is an inconsistency here: your GNU linker is /opt/sfw/bin/gld and you 
pass /opt/sfw/bin/ld to the configure script.  Otherwise, it's the correct 
configure line if /opt/sfw/bin/as and /opt/sfw/bin/ld are working GNU tools.

> Issue 2) Same as Issue 1 except for the Gnu assembler
> (/opt/sfw/bin/gas).

Likewise.

> 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. This causes confusion and thus errors in that the Gcc build scripts
> use make. I would suggest standardizing on the names to prevent confusion.
> To this end I would suggest that GNU Make always, always, always be
> called gmake and when you want to use GNU Make in your project that
> you type gmake.

'gmake' will work just fine for GCC.

> 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

export CONFIG_SHELL=/bin/ksh
$srcdir/configure ...
gmake
gmake install

is not much more complicated and works flawlessly on Solaris.

-- 
Eric Botcazou

Re: Serious Bugs In Gcc Builds

[Ted Byers]

--- "Peter A. Friend" <octavian@corp.earthlink.net>
wrote:

> 
> On Dec 4, 2007, at 11:00 AM, Thomas Dineen wrote:
> 
> > 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. This causes confusion and thus errors in
> that the Gcc build  
> > scripts
> > use make. I would suggest standardizing on the
> names to prevent  
> > confusion.
> > To this end I would suggest that GNU Make always,
> always, always be
> > called gmake and when you want to use GNU Make in
> your project that
> > you type gmake.
> 
> I don't see how this is a GNU bug, it's more of a
> development  
> environment issue. When we install GNU make we
> install it as "make"  
> and also provide a hard link as "gmake". If it was
> only installed as  
> gmake then people would have to alter all of their
> stuff (something  
> they may not have access to do) to call gmake.
> 
> For my Solaris environment I have the GNU tools in
> my path first,  
> followed by /usr/ccs/bin. This makes sure that GNU
> versions of m4,  
> grep, sed and make are used, and Sun versions of as
> and ld are used.
> 
If I have a naming issue, as in makefiles compiling
fortran code that assume the fortran compiler is g77
(yes I know that is a bug, but I am dealing here with
open source packages distributed by others), and once
I have compiled gcc, the compiler that should be used
is gfortran, I just create an alias that results in
gfortran being invoked whenever the the g77 compiler
is invoked, effectively hiding the ancient compiler
that ships with cygwin and ensuring the new one is
used instead.  This is something I learned the hard
way, studying bash.  But, it seems to work fine when
trying to compile any of the various open source
packages using gcc 4.2.1 within cygwin.  

> 
> > 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
> 
> The build procedure for GCC can be cumbersome. There
> are a lot of  
> options, a lot of systems to support, and a lot of
> ways for the  
> procedure to break. This in itself is an argument
> against average  
> users trying to attempt builds themselves.
> 
I don't know about that.  

The configure, make, make check, make install sequence
seems to work fine for me, and I am not a compiler
developer.  Granted, a little trial and error allows
me to add specific options to improve things, but
configuring and then building, testing and installing
GCC is not what I would call hard, even for the
average user who can read.  And there is little option
in some cases, since, for example, on cygwin, the last
time I checked, the most recent GCC available for
download was version 3.4.  If I were content to just
accept what cygwin chooses to provide, I would always
be stuck with older tools.  Yet, building gcc allows
me to work with the latest release, so I can benefit
from all the improvements that become available as
they become available.

I wouldn't want an average user to be scared off of
trying to build GCC just because a few have some
trouble.  I don't work with beta products, but in my
experience with releases of GCC, trying to compile
them on Windows using cygwin, I found the
documentation available to be fine and the process to
be relatively easy compared to other applications I
build.

Cheers,

Ted

Re: Serious Bugs In Gcc Builds

[Tony Wetmore]

Thomas Dineen wrote:
 > 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

Thomas,

I don't think the "ln -s" commands work as you expect.  Those commands 
will create symlinks "ld" and "as" in your current working directory 
(i.e. /export/home/tools/gcc/gcc-3.4.6-obj), not in /opt/sfw/bin.

So when you specify "/opt/sfw/bin/as", you are *not* using the symlink 
that you just created.  Instead, I think you should specify, for example:

   --with-ld=/export/home/tools/gcc/gcc-3.4.6-obj/ld

Or why not just skip the symlinks and specify:

   --with-gnu-ld --with-ld=/opt/sfw/bin/gld

Does that not work?

--
Tony Wetmore

RE: 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....

Re: Serious Bugs In Gcc Builds

[Rask Ingemann Lambertsen]

On Tue, Dec 04, 2007 at 11:00:09AM -0800, Thomas Dineen wrote:
>       By the way don't bother flaming back at me

   People don't usually admit that they are flaming. :-)

> The following
> were my failed efforts to redirect it to the Gnu Linker (/opt/sfw/bin/gld):
							   ^^^^^^^^^^^^^^^^
> /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
				      ^^^^^^^^^^^^^^^
[...]
> /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
[...]
> /export/home/tools/gcc/gcc-4.0.4/configure  --with-gnu-ld  --with-gnu-as 
> --with-as=/opt/sfw/bin --with-ld=/opt/sfw/bin
				   ^^^^^^^^^^^^
[...]
> /export/home/tools/gcc/gcc-4.1.2/configure  --with-gnu-ld  --with-gnu-as 
> --with-as=/opt/sfw/bin --with-ld=/opt/sfw/bin

   How about getting the --with-as and --with-ld options right? For
starters, they aren't even the same in your two GCC 4.04 examples!

-- 
Rask Ingemann Lambertsen
Danish law requires addresses in e-mail to be logged and stored for a year

Re: Serious Bugs In Gcc Builds

[Lionel B]

On Tue, 04 Dec 2007 11:44:24 -0800, Thomas Dineen wrote:

> Peter:
> 
>      I think the idea here is the make the S/W easier to access and use,
> thus opening up the user base to become hopefully larger, maybe
> exponentially larger. Keep in mind I and one of the biggest supporters
> or fans of GNU Freeware, and conversely one of the biggest haters of
> Microsoft. To destroy MS you must make your tools easier to access and
> use, to the point of being usable by the average user.

So it's a little tricky to build from source and install a large, 
complex, sophisticated, cross-platform, open source compiler suite. How 
surprising. Now... when did *anyone* - average user or not - build and 
install a MS compiler suite from source (apart from an MS employee)?

I suspect you will find that the "average user" of GCC is using a pre-
built GCC configured for easy install in their environment by some kindly 
package maintainer - and in "environment" I include MS Windows (cf. 
MinGW, Cygwin, etc.). Not so different, then, from installing a MS 
compiler (except, obviously, cheaper, better, cross-platform and open 
source).

[...]

-- 
Lionel B

Re: Serious Bugs In Gcc Builds

[Tom Browder]

On Dec 5, 2007 3:30 AM, Lionel B <lionelb.nospam@gmail.com> wrote:
> On Tue, 04 Dec 2007 11:44:24 -0800, Thomas Dineen wrote:
...
> >      I think the idea here is the make the S/W easier to access and use,
...
> So it's a little tricky to build from source and install a large,
> complex, sophisticated, cross-platform, open source compiler suite. How
> surprising. Now... when did *anyone* - average user or not - build and
> install a MS compiler suite from source (apart from an MS employee)?
...
> I suspect you will find that the "average user" of GCC is using a pre-
> built GCC configured for easy install in their environment by some kindly
> package maintainer - and in "environment" I include MS Windows (cf.
> MinGW, Cygwin, etc.). Not so different, then, from installing a MS
> compiler (except, obviously, cheaper, better, cross-platform and open
> source).

Game, set, and match to Lionel!

-Tom

Re: Serious Bugs In Gcc Builds

[Tom St Denis]

Lionel B wrote:
> So it's a little tricky to build from source and install a large, 
> complex, sophisticated, cross-platform, open source compiler suite. How 
> surprising. Now... when did *anyone* - average user or not - build and 
> install a MS compiler suite from source (apart from an MS employee)?
>   

I don't think it would be a radically huge task to get a decent coverage 
of configurations [for both GCC and binutils] in some type of wrapper 
script.  Granted, you can't cover all possible weird configurations, but 
why would something that can target the common platforms [e.g. ARM, PPC, 
MIPS, x86] be so hard?

But other than that I agree.  I've been using GCC [and related tools] 
for quite some time, and almost always it's tools I just download as 
binaries [or have gentoo build for me].  Having put together my own ARM 
cross compiler before, I can say from experience that the process could 
be easier.


My 2 cents...

Tom

Re: Serious Bugs In Gcc Builds

[Ian Lance Taylor]

Tom St Denis <tstdenis@ellipticsemi.com> writes:

> Lionel B wrote:
> > So it's a little tricky to build from source and install a large,
> > complex, sophisticated, cross-platform, open source compiler
> > suite. How surprising. Now... when did *anyone* - average user or
> > not - build and install a MS compiler suite from source (apart from
> > an MS employee)?
> >
> 
> I don't think it would be a radically huge task to get a decent
> coverage of configurations [for both GCC and binutils] in some type of
> wrapper script.  Granted, you can't cover all possible weird
> configurations, but why would something that can target the common
> platforms [e.g. ARM, PPC, MIPS, x86] be so hard?

This is free software.  As the saying goes: patches welcome.

Most of us are not going to write those scripts, because for simple
cases we know the few steps required, and for complicated cases we use
existing scripts like crosstool or buildroot.

Ian

RE: Serious Bugs In Gcc Builds

[Duft Markus]

Hi!

Really i don't find it that hard. For commonly used and well supported
targets, it's as simple as configure, make, make install with some
arguments (but those aren't that hard to figure out).

I somebody wants to build a compiler (or even better a cross compiler),
he should be at least be able to figure out some configure switches i
think. Otherwise he/she won't get happy with the compiler then either,
because most other packages builds are exactly the same complexity as
gcc's (ok, gcc has some extras on board, but they don't matter here i
think).

Cheers, Markus

Tom St Denis <> wrote:
> Lionel B wrote:
>> So it's a little tricky to build from source and install a large,
>> complex, sophisticated, cross-platform, open source compiler suite.
>> How surprising. Now... when did *anyone* - average user or not -
>> build and install a MS compiler suite from source (apart from an MS
>> employee)? 
>> 
> 
> I don't think it would be a radically huge task to get a decent
> coverage of configurations [for both GCC and binutils] in some type
> of wrapper script.  Granted, you can't cover all possible weird
> configurations, but why would something that can target the common
> platforms [e.g. ARM, PPC, MIPS, x86] be so hard?
> 
> But other than that I agree.  I've been using GCC [and related tools]
> for quite some time, and almost always it's tools I just download as
> binaries [or have gentoo build for me].  Having put together my own
> ARM cross compiler before, I can say from experience that the process
> could be easier.
> 
> 
> My 2 cents...
> 
> Tom


-- 
5. Dezember 2007
Salomon Automation am  Schweizer Forum fur Logistik, Lausanne, CH




Salomon Automation GmbH - Friesachstrasse 15 - A-8114 Friesach bei Graz
Sitz der Gesellschaft: Friesach bei Graz
UID-NR:ATU28654300 - Firmenbuchnummer: 49324 K
Firmenbuchgericht: Landesgericht fur Zivilrechtssachen Graz