configure: use cc as assembler with clang and for all FreeBSD platforms#9437
configure: use cc as assembler with clang and for all FreeBSD platforms#9437xavierleroy merged 2 commits intoocaml:trunkfrom
Conversation
In recent FreeBSD, `cc` is Clang and `ld` is LLD, the LLVM linker, but `as` is still GNU binutils. Moreover, Clang contains its own assembler and does not call `as`. Consequently, object files produced by invoking `as` directly are slightly different from those produced by `cc`. This can cause obscure errors such as issue ocaml#9068: `ld -r` fails when combining objects produced by `as` and objects produced by `cc`. The workaround is to use `cc` as the assembler. We already did that for the ARM and ARM64 targets, but ocaml#9068 shows that it is necessary for AMD64 too. Just use `cc` as assembler for all FreeBSD targets. Similar issues were reported under Linux when clang and LLD are used instead of GCC and binutils. We already used clang as the preprocessed assembler in this case. Also use clang as the assembler in this case. Closes: ocaml#9068
|
Sure, this makes a lot of sense and on top of that simplifies the code
so, thanks a lot.
@xavierleroy do you think we should somehow factorize the logic that
decides whether we need `-Wno-trigraphs` ?
|
|
I went to have a look at what the opam-repository configures (override the (The build file for older compilers is also similar.) In other words, opam forces {open,free}bsd and macos to use If I understand correctly, the defaults proposed in this PR are identical to the opam overrides for FreeBSD, so the explicit override for freebsd could be dropped on the opam side (in 4.11 and later). I don't understand what is the configure semantics for macos (it depends on the configure-guessed If I read the patch correct, there is no CC/ASPP logic for openbsd in the current configure. Isn't that an omission? (openbsd is dealt with in some other parts of the configure script.) Given the fact that they are configured in the same way in the opam-repository, I think that we could extend the |
No, because OPAM doesn't override Also, OPAM's choice for
I have no idea where OpenBSD stands now in the GCC + binutils versus Clang + LLVM fight. The present PR is an incremental fix to un-break FreeBSD. The whole AS/ASPP configure logic can certainly be simplified and made more regular. But before attempting this we need to have a testing infrastructure, which means upgrading the FreeBSD and OpenBSD machines on Inria's CI, which means un-breaking FreeBSD 12.1 first things first. |
|
I'll take care of the FreeBSD and OpenBSD update part.
Not sure when, but will do.
|
|
I'm merging this PR in the interest of unblocking FreeBSD and enabling further simplifications later. |
…ms (#9437) In recent FreeBSD, `cc` is Clang and `ld` is LLD, the LLVM linker, but `as` is still GNU binutils. Moreover, Clang contains its own assembler and does not call `as`. Consequently, object files produced by invoking `as` directly are slightly different from those produced by `cc`. This can cause obscure errors such as issue #9068: `ld -r` fails when combining objects produced by `as` and objects produced by `cc`. The workaround is to use `cc` as the assembler. We already did that for the ARM and ARM64 targets, but #9068 shows that it is necessary for AMD64 too. Just use `cc` as assembler for all FreeBSD targets. Similar issues were reported under Linux when clang and LLD are used instead of GCC and binutils. We already used clang as the preprocessed assembler in this case. Also use clang as the assembler in this case. Closes: #9068 (cherry picked from commit 88a1bce)
|
I've pushed this PR to 4.10 so that the FreeBSD worker on Inria's CI can now build it |
… FreeBSD As done earlier (in ocaml#16575) and mentioned in ocaml#16568 (comment) this is no longer necessary since ocaml/ocaml#9437 - which was part of 4.11.0. NB: I'm not a big fan of modifying existing packages, but imho this is sane and safe in this case, and looking at ocaml#16575 it seemed to be fine with maintainers back then. I did not touch: - 32bit - flambda+musl - flambda+musl+static Since I don't understand how they are supposed to work in the first place. Eventually it'd make sense to restrict them to supported platforms via (available = [ os = "linux" & os-distribution = ... ])?
In recent FreeBSD,
ccis Clang andldis LLD, the LLVM linker, butasis still GNU binutils. Moreover, Clang contains its ownassembler and does not call
as. Consequently, object files producedby invoking
asdirectly are slightly different from those producedby
cc.This can cause obscure errors such as issue #9068:
ld -rfails whencombining objects produced by
asand objects produced bycc.The workaround is to use
ccas the assembler. We already did thatfor the ARM and ARM64 targets, but #9068 shows that it is necessary
for AMD64 too. Just use
ccas assembler for all FreeBSD targets.Similar issues were reported under Linux when clang and LLD are used
instead of GCC and binutils. We already used clang as the preprocessed
assembler in this case. Also use clang as the assembler in this case.