Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0006346OCamlconfigure and build/installpublic2014-03-14 13:472015-12-11 19:28
Assigned Togarrigue 
PrioritynormalSeverityminorReproducibilityhave not tried
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: [^] [^]

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
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.
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.

avsm (developer)
2014-03-17 11:36

Homebrew pull request for MacOS X for OCaml 4.01 submitted at: [^]
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?
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.
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.
sylvestre (reporter)
2014-07-04 12:20

FYI, future versions of clang will silently ignore this argument: [^]

- 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
2015-12-11 19:28 xleroy Status resolved => closed
2017-02-23 16:38 doligez Category OCaml internal build/install (Makefiles, configure) => configure and build/install

Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker