Build failure with latest version of xcode on OSX #6346
Comments
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. |
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. |
Comment author: @avsm Homebrew pull request for MacOS X for OCaml 4.01 submitted at: Homebrew/legacy-homebrew#27611 |
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? |
Comment author: ybarnoy Since trunk doesn't build on OSX right now, it'd be really nice to have this resolved asap. |
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. |
Comment author: sylvestre FYI, future versions of clang will silently ignore this argument: |
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
The text was updated successfully, but these errors were encountered: