tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Selecting a C++ compiler



Edgar Fuß <ef%math.uni-bonn.de@localhost> writes:

>>   1) Is the C ABI/runtime stable enough that we can reasonably build C
>>   programs with the base system gcc, and use something else for C++?  Or
>>   do we have to move to one version always?  Consider things like geos
>>   which are implemented in C++ but provide C libraries.
> If that's not the case, we can't use any library from base within a package 
> using C++, since it's certainly compiled with the base compiler, no?

If I followed Joerg, I think we can use base libraries, but have to have
a few rules (all for gcc/g++):

  the single C++ compiler version must be >= the base system gcc version

  the single C++ compiler version must be >= any gcc version used for C

  any executable that includes any code implemented in C++ must have
  final linking done with a version of gcc that matches the single
  chosen C++ compiler version.   (This is only tricky with libraries
  implemented in C++ that have C interfaces, like geos, I think.)

  Any C executable (no C++ involved) must be finally linked with a
  version of gcc that is >= all versions used to compile any subpart

Please let me know where I erred above; I think understanding the rules
for soundness is the most important thing for progress.

The last bit seems sufficient, but complicated.  So I think we ought to
have a single chosen version of gcc for C.  I think the only two
sensible choices are 1) the version used for C++ and 2) the base system
version, preferring base if that doesn't lead to trouble.

This has two consequences:

  C programs with GCC_REQD will also have to fail rather than upgrade,
  (unless maybe they don't install libraries, but that feels ugly).
  I wonder how much GCC_REQD there is for C, once we think of anything
  older than 4.1 as irrelevant (or maybe 4.4).    We can choose a floor
  and set the defaults to new (6, to match C++) on systems that have
  too-old base compilers (e.g., NetBSD 5).

  C++ libraries will have to set USE_LANGUAGES=c++ in their
  buildlink3.mk, to force the C compiler to be the chosen C++ one.
  Probably that's abuse and we need a new variable.

The other thing to consider is bootstrapping.   We need to build, e.g.
gcc6, and therefore everything in that dependency chain, and use the
base system compiler.  But then those programs need to follow the rules
above.  I am guessing some sort of BOOTSTRAP_GCC=yes flag to cause these
packages to skip the normal rules, and then we have to see if the rules
are violated and how badly and what we want to do about it.  But I would
say some fuzz in rule compliance as an intermediate step is much better
than what we have now.

If that isn't good enough, then I think we need to play games with
either

  alternate names of bootstrap packages built native rather than with
  the chosen compiler, or

  alternate prefix for bootstrap tools


Thoughts?

Attachment: signature.asc
Description: PGP signature



Home | Main Index | Thread Index | Old Index