Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build failure with latest version of xcode on OSX #6346

Closed
vicuna opened this Issue Mar 14, 2014 · 7 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

vicuna commented Mar 14, 2014

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

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Mar 14, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Mar 14, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Mar 17, 2014

Comment author: @avsm

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

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Mar 17, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 3, 2014

Comment author: ybarnoy

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

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Apr 4, 2014

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

This comment has been minimized.

Copy link
Collaborator Author

vicuna commented Jul 4, 2014

Comment author: sylvestre

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.