svn commit: r325954 - in head: . share/mk sys/conf usr.sbin/config

[Mark Millard]

[Continuing the gcc 4.2.1 side issue a bit.]

On 2017-Nov-19, at 5:40 PM, Pedro Giffuni <pfg at FreeBSD.org> wrote:

>> On Nov 19, 2017, at 19:11, Mark Millard <markmi at dsl-only.net> wrote:
>> 
>> [As long as things do not go the direction of
>> eliminating gcc 4.2.1 being able to do buildworld
>> and buildkernel for certain architectures, I
>> agree that this would stay an off-topic subject.]
>> 
>> On 2017-Nov-19, at 3:43 PM, Pedro Giffuni <pfg at FreeBSD.org> wrote:
>> 
>>> ....
>>> On 19/11/2017 17:38, Mark Millard wrote:
>>>> Pedro Giffuni pfg at FreeBSD.org wrote on
>>>> Sun Nov 19 15:29:33 UTC 2017 :
>>>> 
>>>>> Yes, we should
>>>>> avoid breaking existing stuff (however old) in ports but no one is
>>>>> expecting to build modern FreeBSD with gcc 3.4 or even gcc 4.1. We did
>>>>> what we could with gcc 4.2.1 but it's time is also over.
>>>> Unfortunately for powerpc64 no alternative
>>>> works fully. For example:
>>>> 
>>>> A) With a buildworld by clang and C++ programs linked against
>>>>  the system libraries, any C++ exception thrown causes the
>>>>  program to crash: clang generates bad code in the library.
>>>> 
>>>> B) Modern gcc's build a lib32 based on generating a messed up
>>>>  crtbeginS.o content (bad register usage) and so 32-bit
>>>>  programs crash.
>>>> 
>>>> As far as I know gcc 4.2.1 is still the only environment that
>>>> generally works for powerpc64.
>>> Hmm ...
>>> At some point some of the newer GCC was generating good code.
>>> I have had reports of openoffice-devel working on FreeBSD powerpc64 and,
>>> even on x86, openoffice stopped building with our base gcc.
>> 
>> openoffice likely does not depend on lib32 (support of 32-bit
>> code under a powerpc64 environment) even being present, much
>> less working?
>> 
> 
> Yes, right: it’s pretty native: either all 64 bit or all 32 bit..
> The port had endianness issues but once Curtis Hamilton fixed those the port worked.
> For the record: AOO generally needs two things: working java and a low-level "bridges" code.
> I don’t have access to the platform but patches to build the arch-dependent “bridges” code with clang would be very welcome.
> 
>> As far as I know, for powerpc64 WITHOUT_LIB32= buildworld,
>> devel/powerpc64-gcc is sufficient. It is WITH_LIB32= coverage
>> that makes it insufficient overall. Anything that does not
>> depend on lib32 likely works as well as on other architectures.
>> 
>>>> [There is no devel/powerpc-gcc like there is a devel/powerpc64-gcc
>>>> and I've never managed to to make a working powerpc build from a
>>>> gcc other than 4.2.1 . (A) prevents clang from counting as working
>>>> overall. So powerpc may be in the same boat as powerpc64 as far as
>>>> having a known way to build without gcc 4.2.1 goes.]
>>> At least PPC64 is alive, I am afraid that I don't see a solution for sparc64.
>> 
>> I do not have direct experience for sparc*'s but I'd
>> not be surprised.
>> 
>>> But this is very off-topic to lint issue :).
>> 
>> As long as things do not go the direction of
>> eliminating gcc 4.2.1 being able to do buildworld
>> and buildkernel for certain architectures, I
>> agree that this would stay an off-topic subject.
>> 
> 
> I have no interest in killing any platform but we are reaching a point where, other than being unmaintained, gcc-4.2.1 won’t be able to build newer clang or gcc.

gcc 4.2.1 has not been able to build the system clang
for a long time. Getting from a gcc 4.2.1 powerpc64 or
powerpc to a clang-based one is a pain when self hosting.
Cross building with clang in use is handier when one
has a supporting context for such.

gcc* tends to have a bootstrapping stage available
that builds xgcc (as I remember the name), avoiding
modern stuff to get xgcc built. xgcc builds the full
gcc* build, avoiding the original host compiler.
This may still work with gcc 4.2.1 . I've not tried
in a long time.

Avoiding a full-bootstrap for a gcc* requires something
more modern than gcc 4.2.1 .


===
Mark Millard
markmi at dsl-only.net