[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[scott at smedleyfamily dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

--- Comment #1 from scott at smedleyfamily dot net 2012-04-10 05:41:18 UTC ---
Created attachment 27122
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27122
config.log

[Bug c++/52922] New: failed to build gcc 4.7 on SL6.1

[scott at smedleyfamily dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

             Bug #: 52922
           Summary: failed to build gcc 4.7 on SL6.1
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: scott@smedleyfamily.net


I am trying to build gcc 4.7.0 on a Scientific Linux 6.1 system, but keep
getting the following compilation error:

gcc -c -DHAVE_CONFIG_H -g -O2  -I. -I../../../libiberty/../include  -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic 
../../../libiberty/fnmatch.c -o fnmatch.o
In file included from ../../../libiberty/floatformat.c:31:0:
/usr/include/string.h:548:5: error: unknown type name '__locale_t'
/usr/include/string.h:552:18: error: unknown type name '__locale_t'

No errors were detected during the configure phase, only during the build
phase.

../configure --prefix=/usr/local/gcc-4.7.0 --enable-cloog-backend --enable-lto
--enable-languages=c,c++ --enable-locale=generic

Also tried without --enable-locale & got same result.

Any help would be muchly appreciated.

Scott. :)

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[pinskia at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2012-04-10
     Ever Confirmed|0                           |1

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> 2012-04-10 06:10:28 UTC ---
Can you try the following simple program with your current compiler:
#include "string.h"
#include "stdio.h"

int main(void)
{
  printf ("Hello world.\n");
}

--- CUT ---
And compile it with -pedantic ?

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[scott at smedleyfamily dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

--- Comment #3 from scott at smedleyfamily dot net 2012-04-10 07:45:58 UTC ---
Hi Andrew,

Works fine - see below.

Let me know if there's anything I can do to help.

Scott. :)


lcas-el6build1>> cat >! test.cc
#include "string.h"
#include "stdio.h"

int main(void)
{
 printf ("Hello world.\n");
}
lcas-el6build1>> g++ -pedantic test.cc
lcas-el6build1>> g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/gcc-4.6.2/libexec/gcc/x86_64-unknown-linux-gnu/4.6.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.6.2/configure --prefix=/usr/local/gcc-4.6.2
--enable-cloog-backend --enable-lto
Thread model: posix
gcc version 4.6.2 (GCC)

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-10 07:52:39 UTC ---
This implies the /usr/local/bin/gcc compiler you're using was not built on
SL6.1, or was built against an older glibc

I've had exactly this error when trying to use a compiler built on CentOS5 on
CentOS6 - the fixincluded headers assume an older glibc

Try installing gcc from SL RPMs via yum and ensuring that is earlier in your
path than /usr/local/bin/gcc

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[scott at smedleyfamily dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

--- Comment #5 from scott at smedleyfamily dot net 2012-04-10 08:13:44 UTC ---
Hmmmm, you are right. I was compiling gcc with a version of gcc built on Centos
5.6. (though I compiled Andrew's test program with a different "native"
version)

I would like to build gcc on an "old" system (Centos 5.6) & then install the
binaries on other "newer" Linux systems - is it possible? We want to have the
exact same compiler running on dozens of Linux systems running either Centos >=
5.6 or SL6.x.

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-10 09:11:03 UTC ---
No, in general you can't use GCC built for one target on a different target.

What I do is just build the same version of GCC with the exact same
configuration on each OS I need to target.

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[scott at smedleyfamily dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

--- Comment #7 from scott at smedleyfamily dot net 2012-04-10 23:19:58 UTC ---
Thanks Jonathan,

> No, in general you can't use GCC built for one target on a different target.

I realise this is off-topic but I would love to know: what is causing this
limitation?

I thought by building gcc on the "oldest" architecture I could expect ABI
backward-compatibility on the "newer" architectures.

Thanks for your help.

Scott.

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-11 00:49:39 UTC ---
(In reply to comment #7)
> I realise this is off-topic but I would love to know: what is causing this
> limitation?

GCC's "fixincludes" mechanism, which installs modified versions of system
headers alongside GCC's own headers, earlier in the include path.  The
installed "fixed" features.h header is based on a copy of that header from
glibc 2.5 (or whatever old version it is that SL5 uses) and that is
incompatible with glibc 2.12 (or whatever it is SL6 uses).

IIRC in glibc 2.5 the xlocale features were GNU extensions, so only enabled by
_GNU_SOURCE.  The xlocale features were later added to POSIX 2008, so glibc
2.12 doesn't consider them to be GNU extensions and enables them when
_XOPEN_SOURCE >= 700.  The glibc 2.5 features.h defines _XOPEN_SOURCE=600 (i.e.
POSIX 2001) when _GNU_SOURCE is defined, because that's the latest POSIX spec
that existed when glibc 2.5 was released.  So the "fixed" features.h installed
with the old GCC doesn't know about POSIX 2008 and doesn't set the required
_XOPEN_SOURCE=700 value, so the __locale_t type is not declared by
/usr/include/xlocale.h.  (That's all from memory, you should be able to diff
SL6's /usr/include/features.h with the header found under the GCC installation
dir to confirm it.)


> I thought by building gcc on the "oldest" architecture I could expect ABI
> backward-compatibility on the "newer" architectures.

If you use that GCC and actually build *on* the oldest system, yes, the
binaries produced will run on the newer system too. But you cannot move that
GCC you built to the newer system and expect it to still work.  You can't
expect the compiler to even work, let alone produce binaries that will run on
the old systems.  Building on the newer arch will create dependencies on the
newer glibc and other system libs.  There is far more to ABI compatibility than
just the compiler used.

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[scott at smedleyfamily dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

--- Comment #9 from scott at smedleyfamily dot net 2012-04-11 01:36:13 UTC ---
Thanks for the explanation. Makes sense.

[Bug c++/52922] failed to build gcc 4.7 on SL6.1

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |RESOLVED
         Resolution|                            |INVALID

--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-04-11 07:28:14 UTC ---
I think we can close this as invalid then