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

[Pedro Giffuni]

> 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.

Pedro.