It is just an assembler, a newer version of the one that's already used,
there's not really much that's likely to go wrong, it's more likely to fix
than introduce problems.
If you have some cycles to spare, building gcc with Brad's diff and
checking that a selection of the existing ports (pcbasic, vmm-firmware,
Fortran things) still build with it would be useful.
--
Sent from a phone, apologies for poor formatting.
On 1 November 2020 14:03:28 Aisha Tammy <openbsd.ports@aisha.cc> wrote:
> On 11/1/20 8:49 AM, Stuart Henderson wrote:
>> On 2020/10/31 23:33, Aisha Tammy wrote:
>>>> But that's not an option for something that is to be commited to the tree.
>>>>
>>>
>>> Well damn...
>>> Is there any other method to fix the compiler to cc instead of
>>> this?
>>> I tried adding the lang/clang module before the fortran module
>>> MODULES = lang/clang fortran
>>> but that fixes the compiler to /usr/local/bin/clang instead of the
>>> /usr/bin/clang.
>>> I am not sure what else to try right now :(
>>
>> The correct fix IMHO is the diff that Brad sent for ports/lang/gcc as
>> this not only fixes this, but fixes some other problems we run into
>> from time to time.
>>
>> If there is some other idea of using a different C compiler for ports
>> which mix fortran+C then that should be handled in fortran ports modules
>> or other infrastructure rather than individual ports.
>>
>
> That sounds good to me!
> I assume there is going to be testing needed for getting
> gas+egcc in the tree first.
> In that case, I will pause my work on OpenBLAS until it
> is incorporated. There is just way too much assembly in
> OpenBLAS to do any considerable testing and switching it
> to a different compiler later on.
>
> Current port (with half-assed patching copied from gentoo)
> link for anyone who wants to keep trying -
> https://github.com/epsilon-0/openbsd-ports/tree/openblas/math/openblas
>
> Best,
> Aisha
No comments:
Post a Comment