There are weird mscv64 failure logs in the CI, and I don't know if they are a fluke (a bug in the mscv64 CI in trunk at the time, that was fixed since) or related to the PR. @shindere, could you rebase the PR on top of the current trunk, so that the CI reruns in a known-good configuration?

I will rebase yes, and intend to go through the PR again because I think there is still room for improvemnet. In particular, I think it's important to pass the TSan flags at link time because, as I understood it, some platforms do require that.

All platforms do - TSan-enabled binaries need to be linked against the TSan runtime library.

I just pushed an updated version of the PR that passes CI.

(I know it does because it did and I just squashed a tentative fix in the
commit it was actually fixing.)

Basically, the problem was that there were some flags missing in those
ocamlopt must pass to the C files it compiles to be linked with native code.

This is, in turn, the consequence of two things. On the one hand, it is
currently true that the C flags used for native code are a superset of those
used for bytecode. On the other hand, this assumption, which is true
currently but may not always be true, is expressed at several places in the
build system, namely everytime we say that the native flags are the bytecode
flags plus something else.

I think this should be fixed and the build system shoudl not compute the
native code flags in terms of the bytecode ones. It should rather use the
native code flags, whatever they are, and those should be computed
once and for all during the configure stage, where we can compute
them in connection with the bytecode flags as appropriate.
But that's quite a bit of work and quite orthogonal to the current
PR so I would like to leave it for a dedicated PR which I intend to
submit soon.

So we use bytecode_cflags rather than ocamlc_cflags, etc., for the day when ocamlc and ocamlopt will have a unified compiler driver. ;)

Could someone provide a stronger argument for breaking every single user of ocamlc -config starting in 5.3 other than the hand-wavy "look, guys, it'll be better when the compiler driver is unified"?

I think that you are reporting an unintended regression, but there is too much sarcasm and not enough information to know what the regression is and how to fix it. Could you try again with a gentler explanation of the issue?

No sarcasm intended, this is a pretty serious regression. On OCaml 5.2:

$ ocamlc.opt -config
...
ocamlc_cflags:  -O2 -fno-strict-aliasing -fwrapv -pthread   -pthread
ocamlc_cppflags:  -D_FILE_OFFSET_BITS=64
ocamlopt_cflags:  -O2 -fno-strict-aliasing -fwrapv -pthread   -pthread
ocamlopt_cppflags:  -D_FILE_OFFSET_BITS=64
...

On OCaml trunk (what will be 5.3):

$ ocamlc.opt -config
...
bytecode_cflags:  -O2 -fno-strict-aliasing -fwrapv -pthread   -pthread
bytecode_cppflags:  -D_FILE_OFFSET_BITS=64
native_cflags:  -O2 -fno-strict-aliasing -fwrapv -pthread   -pthread
native_cppflags:  -D_FILE_OFFSET_BITS=64  -DNATIVE_CODE -DTARGET_arm64 -DMODEL_default -DSYS_macosx
...

Tooling such as dune relies on those variables being present.

Thanks! This sounds easy to fix by undoing the renaming from ocamlc, ocamlopt to bytecode, native, which is pleasant but not worth any userland breakage.

(I'm not planning to work on this myself right away as I suppose that @shindere or @OlivierNicole will probably do it, but of course anyone else is welcome to propose a PR.)

If there's a strong desire to rename theses variables, you can still introduce the new variables alongside the current ones and establish some kind of deprecation strategy.

That's what puzzled me so much, given the OCaml compiler's track record of not introducing breaking changes like these.

I think that we should just go back to the old names. ocamlc and ocamlopt are clear enough and the new names are marginally nicer, but not worth the work of deprecating and communicating about it and asking our users to change their practices and and... This is a standard "perfect is the enemy of good" situation.

unless people feel there is a need for a dedicated PR

The renaming would be a very small change that can easily be reviewed and merged, and un-break trunk for our downstream users. I would be in favor of doing this now instead of tying it to something bigger.

In my opinion the priority is to un-break the various CI systems that are following trunk to make the ecosystem better ahead of time, with the minimal change that achieves it. I can either (1) just let you do whatever you want, even if I don't like the result, because other approaches lead to potential conflicts, or (2) do the minimal thing myself. I guess that a last option is to (3) revert the present PR from trunk for the time being. What do you think is best?

Just opened #13244 to fix ocamlc -config