Bug 64940 - Question: is it possible to build a single gcc/g++ that will work on mult. OS versions?
Summary: Question: is it possible to build a single gcc/g++ that will work on mult. O...
Status: RESOLVED WONTFIX
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-04 22:46 UTC by Bill Torpey
Modified: 2015-02-05 13:50 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Bill Torpey 2015-02-04 22:46:28 UTC
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!
Comment 1 Andrew Pinski 2015-02-04 22:52:06 UTC
You can call fix-includes after installing the toolchain if needed.
Comment 2 Bill Torpey 2015-02-04 23:33:01 UTC
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).
Comment 3 Andrew Pinski 2015-02-05 00:03:10 UTC
(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.
Comment 4 Bill Torpey 2015-02-05 13:50:26 UTC
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.