Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006346OCamlOCaml internal build/install (Makefiles, configure)public2014-03-14 13:472014-07-04 12:20
Reporterdim 
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusresolvedResolutionfixed 
PlatformOSOS Version
Product Version4.01.0 
Target VersionFixed in Version4.02.0+dev 
Summary0006346: Build failure with latest version of xcode on OSX
DescriptionIt seems that the latest version of clang does not accept the `-fno-defer-pop` argument on OSX. See these tickets on github:

  https://github.com/ocaml/opam/issues/1236 [^]
  https://github.com/ocaml/opam/issues/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.
TagsNo tags attached.
Attached Filesdiff file icon fix-clang-build-on-osx.diff [^] (755 bytes) 2014-03-14 13:47 [Show Content]

- Relationships
has duplicate 0006347closed Clang 5.1 does not accept '-fno-defer-pop' anymore 

-  Notes
(0011041)
xleroy (administrator)
2014-03-14 13:52

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.
(0011044)
dim (developer)
2014-03-14 15:40
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.

(0011045)
avsm (reporter)
2014-03-17 11:36

Homebrew pull request for MacOS X for OCaml 4.01 submitted at: https://github.com/Homebrew/homebrew/pull/27611 [^]
(0011047)
dim (developer)
2014-03-17 11:53

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?
(0011213)
ybarnoy (reporter)
2014-04-03 16:27

Since trunk doesn't build on OSX right now, it'd be really nice to have this resolved asap.
(0011218)
garrigue (manager)
2014-04-04 05:07

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.
(0011786)
sylvestre (reporter)
2014-07-04 12:20

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

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker