Build failure with latest version of xcode on OSX

[vicuna]

Original bug ID: 6346
Reporter: @diml
Assigned to: @garrigue
Status: closed (set by @xavierleroy on 2015-12-11T18:28:08Z)
Resolution: fixed
Priority: normal
Severity: minor
Version: 4.01.0
Fixed in version: 4.02.0+dev
Category: configure and build/install
Has duplicate: #6347

Bug description

It seems that the latest version of clang does not accept the -fno-defer-pop argument on OSX. See these tickets on github:

ocaml/opam#1236
ocaml/opam#1242

AFAIK, this flag was never supported by clang and now it makes clang to fail. So I think it is better to just remove it when using clang.

I did a small patch to fix this on OSX. As gcc is now a symlink to clang by default, the configure script looks at the output of "$bytecc --version" to check whether it is clang or not.

File attachments

• fix-clang-build-on-osx.diff

[vicuna]

Comment author: @xavierleroy

It is quite possible that -fno-defer-pop is not needed for GCC either. I put this flag a long time ago (in the 1990's) because some versions of GCC (1.xx) would otherwise miscompile the computed goto's in byterun/interp.c. So, with appropriate retesting on x86-32 bits (the platform where the defer-pop optimization matters), it might be possible to get rid of -fno-defer-pop entirely.

[vicuna]

Comment author: @diml

I tried on a 32bits with gcc 4.4.7 and it generates the same code for byterun/interp.c with and without -fno-defer-pop.

[vicuna]

Comment author: @avsm

Homebrew pull request for MacOS X for OCaml 4.01 submitted at: Homebrew/legacy-homebrew#27611

[vicuna]

Comment author: @diml

I also tested with an older version of gcc (3.4.0) and I also get the same result: same ocamlrun file produced with and without -fno-defer-pop.

Should we do more testing (with older versions of gcc) or should we consider that it is safe to remove -fno-defer-pop?

[vicuna]

Comment author: ybarnoy

Since trunk doesn't build on OSX right now, it'd be really nice to have this resolved asap.

[vicuna]

Comment author: @garrigue

I got tired of fixing it by hand every time I reconfigured, and just removed the no-defer-pop on entirely on Darwin.
I don't think any version of Darwin/x86 uses an old enough gcc that this would make a differ.
Remains the question of whether to remove it on other architectures or not.

[vicuna]

Comment author: sylvestre

FYI, future versions of clang will silently ignore this argument:
http://reviews.llvm.org/D4357