|Anonymous | Login | Signup for a new account||2014-10-25 16:44 CEST|
|Main | My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006346||OCaml||OCaml internal build/install (Makefiles, configure)||public||2014-03-14 13:47||2014-07-04 12:20|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version||4.02.0+dev|
|Summary||0006346: Build failure with latest version of xcode on OSX|
|Description||It seems that the latest version of clang does not accept the `-fno-defer-pop` argument on OSX. See these tickets on github:|
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.
|Tags||No tags attached.|
|Attached Files||fix-clang-build-on-osx.diff [^] (755 bytes) 2014-03-14 13:47 [Show Content]|
|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.|
edited on: 2014-03-14 16:57
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.
|Homebrew pull request for MacOS X for OCaml 4.01 submitted at: https://github.com/Homebrew/homebrew/pull/27611 [^]|
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?
|Since trunk doesn't build on OSX right now, it'd be really nice to have this resolved asap.|
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.
FYI, future versions of clang will silently ignore this argument:
|2014-03-14 13:47||dim||New Issue|
|2014-03-14 13:47||dim||Status||new => assigned|
|2014-03-14 13:47||dim||Assigned To||=> dim|
|2014-03-14 13:47||dim||File Added: fix-clang-build-on-osx.diff|
|2014-03-14 13:52||xleroy||Note Added: 0011041|
|2014-03-14 15:06||gasche||Relationship added||has duplicate 0006347|
|2014-03-14 15:40||dim||Note Added: 0011044|
|2014-03-14 16:57||dim||Note Edited: 0011044||View Revisions|
|2014-03-17 11:36||avsm||Note Added: 0011045|
|2014-03-17 11:53||dim||Note Added: 0011047|
|2014-04-03 16:27||ybarnoy||Note Added: 0011213|
|2014-04-04 05:07||garrigue||Note Added: 0011218|
|2014-04-04 05:07||garrigue||Status||assigned => resolved|
|2014-04-04 05:07||garrigue||Fixed in Version||=> 4.02.0+dev|
|2014-04-04 05:07||garrigue||Resolution||open => fixed|
|2014-04-04 05:07||garrigue||Assigned To||dim => garrigue|
|2014-07-04 12:20||sylvestre||Note Added: 0011786|
|Copyright © 2000 - 2011 MantisBT Group|