[Bug c++/64940] New: Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?

[Bug c++/64940] New: Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?

[bill.torpey at ullink dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64940

            Bug ID: 64940
           Summary: Question:  is it possible to build a single gcc/g++
                    that will work on mult. OS versions?
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bill.torpey at ullink dot com

We're trying to build a single gcc/g++ toolchain that can run from a
network-mounted filesystem, and be usable from multiple OS versions.

In our specific case, we need to support RH/CentOS 5 & 6.

Our approach has been to build on RH5 with the idea that glibc is
backward-compatible.  That mostly works, but with one major problem.

When building on RH5, the gcc build creates a features.h in include-fixed that
is specific to RH5.  (Specifically, __USE_XOPEN2K8 is not defined, which causes
compile errors when building on RH6).

Is there a way to build gcc/g++ in a generic fashion such that include-fixed
does not contain a features.h, but instead picks up the (OS-specific) version
from /usr/include?

FWIW, we've google'd ourselves silly trying to answer this question, and the
only solution appears to be to build a "cross" compiler, but it's not clear how
to do that.

In particular, the approach we've tried (specifying
--target=x86_64-unknown-linux-gnu to configure) doesn't seem to prevent the
creation of a system-specific features.h.

Any suggestions would be much appreciated!

[Bug c++/64940] Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64940

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You can call fix-includes after installing the toolchain if needed.

[Bug c++/64940] Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?

[bill.torpey at ullink dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64940

--- Comment #2 from Bill Torpey <bill.torpey at ullink dot com> ---
Thanks for the quick reply!

Unfortunately, the approach you suggest won't work for what we want to do,
which is to have a *single* network-mounted gcc that can be used from both.

That means we need a "generic" gcc, and it's not clear how to produce one (or
if that is even possible).

[Bug c++/64940] Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64940

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Bill Torpey from comment #2)
> Thanks for the quick reply!
> 
> Unfortunately, the approach you suggest won't work for what we want to do,
> which is to have a *single* network-mounted gcc that can be used from both.
> 
> That means we need a "generic" gcc, and it's not clear how to produce one
> (or if that is even possible).

You could try removing the include-fixed directory and try that.
But really there is no way otherwise.

[Bug c++/64940] Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?

[bill.torpey at ullink dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64940

--- Comment #4 from Bill Torpey <bill.torpey at ullink dot com> ---
That was the first thing I tried, but the system limits.h does an include_next
which fails, and the system features.h doesnt include compiler-specific
definitions, so that also fails.

So, there is absolutely no way to build a generic gcc that can run from a
network filesystem?  That seems hard to believe -- I imagine that is a fairly
common use case.