gcc 4.6.0

gcc 4.6.0

[Bill Cunningham]

    The compilation I just did of gcc 4.6.0 seems to have worked. I did two 
things differently. I used a build directory outside of the source 
directory. And secondly I compiled with c++ support. I used 
the --enable-languages=c,c++ switch also.

    I would rather have compiled without the c++ support. I don't use c++ 
much and it took a very long time to compile. Does anyone know which two of 
these things may have really made the difference?

Bill

Re: gcc 4.6.0

[Axel Freyn]

On Sat, Jun 04, 2011 at 01:43:56PM -0400, Bill Cunningham wrote:
>    The compilation I just did of gcc 4.6.0 seems to have worked. I did 
> two things differently. I used a build directory outside of the source  
> directory. And secondly I compiled with c++ support. I used the 
> --enable-languages=c,c++ switch also.
>
>    I would rather have compiled without the c++ support. I don't use c++  
> much and it took a very long time to compile. Does anyone know which two 
> of these things may have really made the difference?

Hi Bill,


as documented on http://gcc.gnu.org/install/configure.html it's a bad
idea to use a build directory inside the source tree:
"First, we highly recommend that GCC be built into a separate directory
from the sources which does not reside within the source tree. This is
how we generally build GCC; building where srcdir == objdir should still
work, but doesn't get extensive testing; building where objdir is a
subdirectory of srcdir is unsupported. "

So probably that made the difference...

Axel

Re: gcc 4.6.0

[Jonathan Wakely]

On 4 June 2011 18:43, Bill Cunningham wrote:
>   The compilation I just did of gcc 4.6.0 seems to have worked. I did two
> things differently. I used a build directory outside of the source
> directory. And secondly I compiled with c++ support. I used the
> --enable-languages=c,c++ switch also.
>
>   I would rather have compiled without the c++ support. I don't use c++ much
> and it took a very long time to compile. Does anyone know which two of these
> things may have really made the difference?

http://gcc.gnu.org/ml/gcc-help/2011-06/msg00066.html

Do you not believe all the documentation saying that configuring
inside the source tree might fail?
Even when doing so causes your build to fail, and not doing so causes
it to succeed?

Re: gcc 4.6.0

[Bill Cunningham]

Jonathan Wakely wrote:

> http://gcc.gnu.org/ml/gcc-help/2011-06/msg00066.html
>
> Do you not believe all the documentation saying that configuring
> inside the source tree might fail?

    That's the key word *might*. What I read is that it hasn't had extensive 
testing. I should never have tried a build directory inside the source tree 
though because that is definately not supported.

> Even when doing so causes your build to fail, and not doing so causes
> it to succeed?

    That's quite probably then what the problem was. This is the first 
version of gcc I've ever compiled that wasn't within the source directory. 
This version is evidently a "bird of a different feather".

Bill

Re: gcc 4.6.0

[Jonathan Wakely]

On 4 June 2011 19:27, Bill Cunningham wrote:
>
>   That's quite probably then what the problem was. This is the first version
> of gcc I've ever compiled that wasn't within the source directory. This
> version is evidently a "bird of a different feather".

The docs have said not to do it for at least 10 years so if it worked
previously you got lucky.

Re: gcc 4.6.0

[kevin diggs]

Hi,

On Sat, Jun 4, 2011 at 1:51 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> The docs have said not to do it for at least 10 years so if it worked
> previously you got lucky.
>

With all the trouble this causes one wonders why it is not caught and
flagged as an error ...

kevin

Re: gcc 4.6.0

[Kai Ruottu]

6.6.2011 23:47, kevin diggs kirjoitti:
> Hi,
>
> On Sat, Jun 4, 2011 at 1:51 PM, Jonathan Wakely<jwakely.gcc@gmail.com>  wrote:
>>
>> The docs have said not to do it for at least 10 years so if it worked
>> previously you got lucky.
>>
>
> With all the trouble this causes one wonders why it is not caught and
> flagged as an error ...

Five GCCs, gcc-3.3.6 - 4.2.4 and 4.6.0, made for RHL9 target on CentOS
5.6 and no problems... In a 'build' subdirectory in the main src dir.
Before these more than 1000 GCC builds and never any problems...

Generally forcing people to make "directory bloat" - separate build dir
for each source package - or maybe using some amount of common ones,
for instance 5 for max 5 parallel builds for different sources, would
sound nuisance for the builders... Building in a separate originally
empty build directory inside the source package is much, much clearer...

For curiosity I will install RHL9 into an unused P-III 733MHz/512MB PC
and see if there really can be some problem with this build platform
and the gcc-4.6.0 sources... As $host and $target RHL9 hadn't anything,
neither the only-C or C with C++ made any difference... Sad that people
cannot do any "> BuildLog 2>&1" redirections or see the right
'config.log's nowadays in order to tell where the smoke was rising... :(

The habit to build in an subdirectory of the GCC sources is quite common
among the RedHat-derived distros, like CentOS :

[root@localhost ~]# gcc -v
Reading specs from /usr/lib/gcc/i386-redhat-linux/4.1.2/specs
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--enable-checking=release --with-system-zlib --enable-__cxa_atexit 
--disable-libunwind-exceptions --enable-libgcj-multifile 
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada 
--enable-java-awt=gtk --disable-dssi --disable-plugin 
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre 
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-50)

and was common already in 2003 in RHL9 :

[root@localhost ~]# cd /opt/host-RedHat9.0/usr/bin
[root@localhost bin]# ./gcc -v
Reading specs from ./../lib/gcc-lib/i386-redhat-linux/3.2.2/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man 
--infodir=/usr/share/info --enable-shared --enable-threads=posix 
--disable-checking --with-system-zlib --enable-__cxa_atexit 
--host=i386-redhat-linux
Thread model: posix
gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)

So maybe you guys should start to nag to the Red Hat, CentOS etc. people
about their way to build GCCs...

Re: gcc 4.6.0

[Jonathan Wakely]

On 6 June 2011 22:41, Kai Ruottu wrote:
>
> The habit to build in an subdirectory of the GCC sources is quite common
> among the RedHat-derived distros, like CentOS :

It's ok if the name of the sub-directory doesn't clash with on that
gets created as part of the build.

> So maybe you guys should start to nag to the Red Hat, CentOS etc. people
> about their way to build GCCs...

They don't ask for help with their builds.

Re: gcc 4.6.0

[Jonathan Wakely]

On 7 June 2011 08:46, Jonathan Wakely wrote:
> On 6 June 2011 22:41, Kai Ruottu wrote:
>>
>> The habit to build in an subdirectory of the GCC sources is quite common
>> among the RedHat-derived distros, like CentOS :
>
> It's ok if the name of the sub-directory doesn't clash with on that
> gets created as part of the build.
>
>> So maybe you guys should start to nag to the Red Hat, CentOS etc. people
>> about their way to build GCCs...
>
> They don't ask for help with their builds.

The point is that it's unsupported.  So when people come asking for
support they should do it the supported way.

Anyway, by far the biggest problem is the "cannot compute suffix of
object files" failure due to trying to install the prerequisite libs
by hand in arbitrary places unknown to the dynamic linker.  A more
useful configure check would be to test that early on and fail with a
meaningful message.

Re: gcc 4.6.0

[kevin diggs]

Hi,

On Tue, Jun 7, 2011 at 2:50 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> Anyway, by far the biggest problem is the "cannot compute suffix of
> object files" failure due to trying to install the prerequisite libs
> by hand in arbitrary places unknown to the dynamic linker.  A more
> useful configure check would be to test that early on and fail with a
> meaningful message.
>

I hope to avoid getting flamed for this, but ...

If I give gcc a --with-gmp=<path>, I do NOT understand why that is not
enough. Though I admit I do not understand all of the dynamic library
location machinery. From what little I understand, If gcc built itself
with -rpath then all would be cool??? Maybe a new configure option:
--enable-self-rpath?

I don't know what else gmp *might* be used for on this system (in this
case a Toshiba A75 (3.2 GHz p4)). Debian 5.x did install a gmp
(library is libgmp.so.3.4.2). But I installed a specific version for
gcc to use. ... just cauz buildin stuff is a hoot.

kevin

P.S.:  why is the lib for gmp-4.3.2 called libgmp.so.3.5.2????????

Re: gcc 4.6.0

[Jonathan Wakely]

On 7 June 2011 20:20, kevin diggs wrote:
> Hi,
>
> On Tue, Jun 7, 2011 at 2:50 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>
>> Anyway, by far the biggest problem is the "cannot compute suffix of
>> object files" failure due to trying to install the prerequisite libs
>> by hand in arbitrary places unknown to the dynamic linker.  A more
>> useful configure check would be to test that early on and fail with a
>> meaningful message.
>>
>
> I hope to avoid getting flamed for this, but ...
>
> If I give gcc a --with-gmp=<path>, I do NOT understand why that is not
> enough. Though I admit I do not understand all of the dynamic library
> location machinery. From what little I understand, If gcc built itself
> with -rpath then all would be cool??? Maybe a new configure option:
> --enable-self-rpath?

If by "self rpath" you mean setting rpath to the directory where gcc
is installed that won't help when people have installed gmp, mpfr and
mpc elsewhere (which they often do)

See http://gcc.gnu.org/faq.html#rpath for why GCC doesn't set rpath
automatically, unlike some other compilers.

If you want it to have an rpath you have that option, using
appropriate linker flags or the LD_RUN_PATH environment variable.

Or if you want to build statically you have that option, or if you
don't want to fix it to work with a specific version in a specific
location and let the dynami linker find it in its usual path, you have
that option.

> I don't know what else gmp *might* be used for on this system (in this
> case a Toshiba A75 (3.2 GHz p4)). Debian 5.x did install a gmp
> (library is libgmp.so.3.4.2). But I installed a specific version for
> gcc to use. ... just cauz buildin stuff is a hoot.
>
> kevin
>
> P.S.:  why is the lib for gmp-4.3.2 called libgmp.so.3.5.2????????

A shared library's soname is not the same as the release number of the
project, so they don't have to be the same.

The C++ runtime library for GCC 4.6 is libstdc++.so.6.0.16

Re: gcc 4.6.0

[Jonathan Wakely]

On 7 June 2011 23:53, Jonathan Wakely wrote:
>>
>> P.S.:  why is the lib for gmp-4.3.2 called libgmp.so.3.5.2????????
>
> A shared library's soname is not the same as the release number of the
> project, so they don't have to be the same.

See http://sourceware.org/autobook/autobook/autobook_91.html for more
on that subject, as well as
http://www.gnu.org/software/libtool/manual/html_node/Updating-version-info.html
which says "*Never* try to set the interface numbers so that they
correspond to the release number of your package."

Re: gcc 4.6.0

[Andrew Haley]

On 07/06/11 23:53, Jonathan Wakely wrote:
> On 7 June 2011 20:20, kevin diggs wrote:
>> Hi,
>>
>> On Tue, Jun 7, 2011 at 2:50 AM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>>
>>> Anyway, by far the biggest problem is the "cannot compute suffix of
>>> object files" failure due to trying to install the prerequisite libs
>>> by hand in arbitrary places unknown to the dynamic linker.  A more
>>> useful configure check would be to test that early on and fail with a
>>> meaningful message.
>>
>> I hope to avoid getting flamed for this, but ...
>>
>> If I give gcc a --with-gmp=<path>, I do NOT understand why that is not
>> enough. Though I admit I do not understand all of the dynamic library
>> location machinery. From what little I understand, If gcc built itself
>> with -rpath then all would be cool??? Maybe a new configure option:
>> --enable-self-rpath?
> 
> If by "self rpath" you mean setting rpath to the directory where gcc
> is installed that won't help when people have installed gmp, mpfr and
> mpc elsewhere (which they often do)

This subject never seems to end.  Every month we go around it again.
I really don't understand why people go through so much pain for GMP.

If everyone just ran ./contrib/download_prerequisites first, the
problem would go away.  Maybe we need to revise the build instructions.

Andrew.

Re: gcc 4.6.0

[Jonathan Wakely]

On 8 June 2011 10:04, Andrew Haley wrote:
>
> This subject never seems to end.  Every month we go around it again.
> I really don't understand why people go through so much pain for GMP.

I think it's because they stop reading after the second sentence of
"Necessary to build GCC. If you do not have it installed in your
library search path, you will have to configure with the --with-gmp
configure option. See also --with-gmp-lib and --with-gmp-include.
Alternatively, if a GMP source distribution is found in a subdirectory
of your GCC sources named gmp, it will be built together with GCC. "

> If everyone just ran ./contrib/download_prerequisites first, the
> problem would go away.  Maybe we need to revise the build instructions.

Yes, I think there should be a very strong recommendation to put the
prereq sources in the gcc tree (as download_prerequisites does) and
that recommendation should appear before (or instead of) any mention
of --with-gmp etc. so that people who just skim the docs won't find
--with-gmp etc.

If you know what you're doing and are prepared to spend more than 30
seconds R'ing TFM you'll find the --with-xxx options.

There should also be big hint that for most Linux distros the prereqs
are available via your usual package manager, which makes it a
complete non-issue as everything is installed where ldconfig will find
it.

I'm sick of pointing people to the relevant FAQs several times a week
and already started some improvements to the installation docs on
Monday, I'll try to get that finished in the next day or two.

Re: gcc 4.6.0

[kevin diggs]

Hi,

On Tue, Jun 7, 2011 at 5:53 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>
> If by "self rpath" you mean setting rpath to the directory where gcc
> is installed that won't help when people have installed gmp, mpfr and
> mpc elsewhere (which they often do)
>
No, I mean adding an rpath with the path for these trouble makers into
"whatever" in gcc needs to find them. A specific rpath isn't tied to a
particular library, is it? For example if I build gcc using particular
revision of gmp in a particular spot (hacked to include an rpath to
find it). And then download and build a minor rev to gmp in a
different place and remove the original. If I tell the dynamic linker
about the new gmp will gcc still run?

> See http://gcc.gnu.org/faq.html#rpath for why GCC doesn't set rpath
> automatically, unlike some other compilers.
>
Thanks for the link. I'll take a look.

> If you want it to have an rpath you have that option, using
> appropriate linker flags or the LD_RUN_PATH environment variable.
>
Is this env in the install manual? I'll take a peek. Might give it a try.

kevin

Re: gcc 4.6.0

[Jonathan Wakely]

On 8 June 2011 18:52, kevin diggs wrote:
> Hi,
>
> On Tue, Jun 7, 2011 at 5:53 PM, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>
>> If by "self rpath" you mean setting rpath to the directory where gcc
>> is installed that won't help when people have installed gmp, mpfr and
>> mpc elsewhere (which they often do)
>>
> No, I mean adding an rpath with the path for these trouble makers into
> "whatever" in gcc needs to find them. A specific rpath isn't tied to a
> particular library, is it? For example if I build gcc using particular
> revision of gmp in a particular spot (hacked to include an rpath to
> find it). And then download and build a minor rev to gmp in a
> different place and remove the original. If I tell the dynamic linker
> about the new gmp will gcc still run?

Yes

>> See http://gcc.gnu.org/faq.html#rpath for why GCC doesn't set rpath
>> automatically, unlike some other compilers.
>>
> Thanks for the link. I'll take a look.
>
>> If you want it to have an rpath you have that option, using
>> appropriate linker flags or the LD_RUN_PATH environment variable.
>>
> Is this env in the install manual? I'll take a peek. Might give it a try.

Try "man ld"

Re: gcc 4.6.0

[David Kirkby]

On 4 June 2011 18:56, Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
> On 4 June 2011 18:43, Bill Cunningham wrote:
>>   The compilation I just did of gcc 4.6.0 seems to have worked. I did two
>> things differently. I used a build directory outside of the source
>> directory. And secondly I compiled with c++ support. I used the
>> --enable-languages=c,c++ switch also.
>>
>>   I would rather have compiled without the c++ support. I don't use c++ much
>> and it took a very long time to compile. Does anyone know which two of these
>> things may have really made the difference?
>
> http://gcc.gnu.org/ml/gcc-help/2011-06/msg00066.html
>
> Do you not believe all the documentation saying that configuring
> inside the source tree might fail?
> Even when doing so causes your build to fail, and not doing so causes
> it to succeed?
>

To  be honest, gcc should do what ATLAS linear algebra library does -
just refuses to build if one attempts to build in the source
directory.

Dave