Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

macvim: Fix compilation on Mac OS X 10.9 #20473

Closed
wants to merge 1 commit into from
@felixbuenemann

Fixes several issues on Mavericks:

  • Missing AvailabilityMacros.h include (fixes sigaltstack compile error)
  • Ruby.framework detection
  • Compile against Ruby.framework matching ruby-command

Works with stable, for head it disables the patches and forces the current Ruby.framework's ruby command to allow compilation.

@adamv
Owner

Does this still work on older versions of OS X?

@felixbuenemann

It should because that's the standard header for those defines, but I would need to install a VM to verify for sure. The macros header file has been around since at least 2001.

I also have some fixes to properly detect the python and ruby frameworks in the works. Should I push them to this PR?

@felixbuenemann

The python fix is rather simple (replace config.c with config.c.in in configure), but for ruby they moved the headers out of the frameworks and into Xcode.app without updating the RbConfig locations, so even /usr/bin/ruby -r mkmf -e "" fails.

@felixbuenemann

OK, I've fixed the Python.framework detection and updated the formula so it should build against Ruby.framework 1.8 on older OS X and against 2.0 on Mavericks.

I'll have to push another fix for python cause it's still looking for /usr/include/python2.7/pyconfig.h at runtime which has also been moved into Xcode. (Was caused by old python modules compiled on Mountain Lion.)

@felixbuenemann

Ok, both python and ruby support working fine now.

I'll setup a 10.8 x64 and 10.7 x86 VM to verify backwards compatibility.

@felixbuenemann

Working fine on 10.8.4-x86_64 and 10.7.5-i386.

I'll squash to single commit if it's good to merge.

@mikemcquaid mikemcquaid commented on the diff
Library/Formula/macvim.rb
@@ -36,7 +38,7 @@ def install
--enable-perlinterp
--enable-rubyinterp
--enable-tclinterp
- --with-ruby-command=#{RUBY_PATH}
@mikemcquaid Owner

Why does this need changed?

Because the brew binary still uses ruby 1.8 which RUBY_PATH is derived from, so configure would detect ruby version 1.8 while compiling against the Ruby 2.0 framework, which would fail. This is because it uses -framework Rubyto compile, which will choose the Current version, which will be 1.8 on older OS X and 2.0 on 10.9. So using the Current ruby binary just matches the version detection to the Current framework.

Another approach would be to adjust configure to compile against the Ruby framework matching the ruby-command but I don't see the value of using an outdated framework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@mikemcquaid
Owner

Have you submitted this upstream? I suspect this is a fix that's needed in superenv/our CFLAGs rather than patching things.

@felixbuenemann

What specifically are you talking about? I'm planing on submitting fixes to MacVim, but I guess it'll take some time for a new release, so I think this is a good interim approach.

@mikemcquaid
Owner

Just generally if you're fixing the build of MacVim on 10.9 that seems like something that should go upstream to them. As said though, the more I think about this the more I think it's a symptom of a bigger problem we should fix another way.

@felixbuenemann

I do agree that setting RUBY_PATH based on the brew binary is not such a good idea, it would be better if that was configurable, because eg. a user might want to use his rbenv or rvm ruby.

Another problem is that Apple is packaging stuff into Frameworks that was never meant to be packaged that way, which comes with it's own set of problems.

@felixbuenemann

Revised the ruby framework detection code to leverage what's already there instead of overriding in framework case.

It no longer checks for the physical presence of the archdir, because that's located inside Xcode.app, so the compiler will pick it up but configure would not find it. I think this is better than the previous version, because it will rely on the values returned by RbConfig.

@samueljohn

Thanks for reporting to Apple. I think that is important!

@mikemcquaid
Owner

@samueljohn @jacknagel @adamv @mxcl @Sharpie @mistydemeo See this commit for how brew-test-bot will automatically build pull requests from now on.

@samueljohn

THIS IS AWESOME, @mikemcquaid!! :beers:

@felixbuenemann

Yeah, automated CI for Hombrew. Great stuff!

@samueljohn

will save us hours of hours of hours of ... work

@felixbuenemann

And I can trash those mountain lion and lion vms! Oh well, probably not yet, cause it only tests if the app can be compiled properly, but not if it's working as expected. Anyways, it's a big step forward.

@Gaelan

Installs perfectly and starts up. Haven't tested anything else. Any blockers for a merge?

@felixbuenemann

I think the only thing still open for discussion is overriding RUBY_PATH to the current ruby, which means we're using 2.0 on 10.9. Given however that 2.0 is in most respects a superset of ruby 1.8 functionality, I wouldn't expect much trouble from that change.

Btw. I've worked a bit on the upstream patches for this. While submitting a PR to MacVim on github should be easy, most of the fixes also apply to vim and I couldn't really find any info on how to contribute fixes on vim.org.

@adamv
Owner

Given however that 2.0 is in most respects a superset of ruby 1.8 functionality, I wouldn't expect much trouble from that change.

I question that very much.

@felixbuenemann

@adamv Could you be more specific? I could adjust the configure code to link to the specific framework matching the RUBY_PATH, so it would link against 1.8.

Still I don't think it's a good idea to stay on an old slow ruby implementation that hasn't gotten any fixes or security updates in a long time, but that's not for me to decide.

Maybe it would be better to not have RUBY_PATH as a constant and instead be able to choose what ruby homebrew should use? Of course that's a change that applies to many formulas then.

@mikemcquaid
Owner

Let's stay on 1.8 for now unless @jacknagel disagrees.

@jacknagel
Owner

I think there are two issues here: the first is which Ruby Homebrew itself is running on, and the second is which Ruby other software links against.

The former will always be the system Ruby: 1.8 on 10.5, 10.6, 10.7, and 10.8, and 2.0 on 10.9. This is not going to change. We do this because it provides a consistent environment: we know exactly what features and libraries are available. Time and time again people trying to run Homebrew on other rubies has caused nothing but trouble.

The latter is in most cases up the user, however we had issues with macvim previously that resulted in hardcoding the system Ruby.

@mistydemeo
Owner

2.0 on 10.9

We actually hardcode the 1.8 framework right now. 10.9 comes with both. Presumably 10.9 has the same 1.8.7 that 10.8 does.

@jacknagel
Owner

Interesting. We should leave it as-is at least until 10.9 is out.

@clemensg

2.0 is not a superset of 1.8.. Many things changed from 1.8 to 1.9 and there were also some (fewer) changes from 1.9 to 2.0. So you definitely could have 1.8 code which does not run on 1.9 and 2.0.

Maintainers, what do you think about creating a wrapper script ruby.sh and instead of the #!/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -W0 line in brew.rb we use #!/usr/local/Library/ruby.sh?
Then we could still per default use the system ruby, but maybe if a specific environment-variable and/or Homebrew install flag was set, we could just call /usr/bin/env ruby and therefore let the user choose his favorite flavor (e.g. Rubinius)

Btw. this line above is from my 10.9 machine, shouldn't it be #!/System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby ?
(Current is a symlink to 2.0 on 10.9 and to 1.8 on all OSX versions before)

@jacknagel
Owner

Sorry, but no, and we're not going to budge on this. We've been through it many, many times before.

Homebrew is built to run on the system Ruby for consistency. By doing this we ensure we know exactly what features and libraries are available; there have been many, many tickets filed that wouldn't have even been issues in the first place if people would just leave well enough alone. The reason the very specific exists is to ensure the system Ruby is always used. There isn't any reason anyone needs to run Homebrew on other Ruby implementations.

Anyway, I'm fairly certain that Homebrew runs fine on 1.8, 1.9, and 2.0, but that is beside the point. We always use the system Ruby.

@felixbuenemann

I don't like the whole idea that all formulas depend on the ruby binary that is running homebrew (because RUBY_PATH is a constant extracted from the brew.rb hashbang).

It's fine that homebrew chooses to run on 1.8 and it ensures that all formulas work on older systems, so I think it's a good idead to stay on 1.8 for brew. But for software installed through homebrew I should be able to choose whichever ruby installation I like, be it a different framework ruby or one installed through rvm, rbenv or brew.

@jacknagel
Owner

@felixbuenemann nobody is arguing otherwise, RUBY_PATH is internal to Homebrew and was only used in the macvim formula because of previous issues with other rubies.

@felixbuenemann

@jacknagel Sorry, I wrote this comment in parallel to yours in response to the idea with ruby.sh.

Btw. I would be interested in known issues with using other rubies with MacVim, do you have any links?

@jacknagel
Owner

e.g. the vanilla vim formula doesn't hardcode a ruby path. I don't remember the exact circumstances of why this was added to macvim but probably there is an old issue that has more information.

@felixbuenemann

@jacknagel Adjusted to use 1.8.

I've tested on 10.9 with Ruby.framework 1.8, 2.0 aswell as rvm rubies 1.9.3p429 and 2.0.0p195 and on 10.8 with Ruby.framework 1.9. The patches were created against HEAD but also work fine with 7.3-66.

I'm pretty sure that before this patch it would've only worked with ruby framework builds due to how ruby.h was included in the gui codepath.

@jzelinskie

I get the same error with the vim formula as the macvim formula on Mac OS X 10.9 / Xcode5-DP2, also.
These may be related.

~ ❯❯❯ xcode-select -p                                                                                                                ⏎
/Applications/Xcode5-DP.app/Contents/Developer
~ ❯❯❯ brew install vim
==> Downloading http://ftp.de.debian.org/debian/pool/main/v/vim/vim_7.3.923.orig.tar.gz
Already downloaded: /Library/Caches/Homebrew/vim-7.3.923.tar.gz
==> ./configure --prefix=/usr/local --mandir=/usr/local/Cellar/vim/7.3.923/share/man --enable-gui=no --without-x --enable-multibyte --w
==> make
        ^
1 error generated.
make[1]: *** [objects/os_unix.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [first] Error 2
~ ❯❯❯ brew install macvim                                                                                                            ⏎
==> Downloading https://github.com/b4winckler/macvim/archive/snapshot-66.tar.gz
Already downloaded: /Library/Caches/Homebrew/macvim-7.3-66.tar.gz
==> ./configure --with-features=huge --enable-multibyte --with-macarchs=x86_64 --enable-perlinterp --enable-rubyinterp --enable-tclinte
==> make
        ^
1 error generated.
make[1]: *** [objects/os_unix.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [first] Error 2
@mistydemeo
Owner

@jzelinskie We need your build logs to see if these are actually the same issues. They might not be.

@felixbuenemann

Yep, that's the missing AvailabilityMacros.h include.

@felixbuenemann

Btw. the configure patches no longer apply cleanly to --HEAD. I'll need to check what happened upstream.

@jzelinskie I'll make a PR for vim. I've already successfully build it locally.

@kokoroai

But I got this:Error: uninitialized constant Macvim::DATA
Please report this bug:
https://github.com/mxcl/homebrew/wiki/troubleshooting
/usr/local/Library/Formula/macvim.rb:21:in patches'
/usr/local/Library/Homebrew/formula.rb:600:in
patch'
/usr/local/Library/Homebrew/formula.rb:236:in brew'
/usr/local/Library/Homebrew/formula.rb:594:in
stage'
/usr/local/Library/Homebrew/extend/fileutils.rb:21:in mktemp'
/usr/local/Library/Homebrew/formula.rb:590:in
stage'
/usr/local/Library/Homebrew/formula.rb:234:in brew'
/usr/local/Library/Homebrew/build.rb:149:in
install'
/usr/local/Library/Homebrew/build.rb:43:in `main'
/usr/local/Library/Homebrew/build.rb:12
/usr/local/Library/Formula/macvim.rb:103
I used your version of macvim.rb .

@felixbuenemann

@moedennis Probably your formula is broken. If DATA is not defined then the patch at the end of the formula (after __END__) is missing.

@kokoroai

Yes, you're right. My formula was broken.
Now it works.
Thanks.

@felixbuenemann

Rebased and updated to fix Tcl detection and remove Python config.c hack, that's no longer required on recent 10.9 build. Inline patches split out to gist to handle version differences (stable vs. devel/head).

@felixbuenemann

CI build failure seems to be unrelated to the patches:

error: can't exec '/Developer/Library/Xcode/Plug-ins/GCC 4.2.xcplugin/Contents/Resources/cc' (No such file or directory)

Compiling fine here on 10.9 13A524d and 10.5.8.
I can reproduce the build failure with stable on 10.6.8, even with the patches disabled. It can be fixed by unsetting CC or setting to full path like CC=/usr/bin/cc.

@pavelbrylov

Hi! Can't get macvim working on two different Mavericks DP4 machines, even with applied patch from @felixbuenemann
Here are the gists:

These are from clean machine, it's only Xcode and brew installed (and ruby installed using brew).
Hope this helps.

@felixbuenemann

@pavelbrylov That's strange, it builds fine for me on both my systems running 13A524d (which is DP4 I believe).

Could you post the output of:

ls /Applications/Xcode5-DP3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Ruby.framework/Versions/1.8/Headers
@adamv
Owner

@BrewTestBot test this please

Library/Formula/macvim.rb
@@ -24,6 +24,14 @@ class Macvim < Formula
depends_on :python => :recommended
# Help us! :python3 in MacVim makes the window disappear, so only 2.x bindings!
+ def patches
@adamv Owner
adamv added a note

Please add a comment here documenting what these patches do.

Thanks, addresses in commit 8769c1f.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@adamv
Owner

Build bot is seeing a Snow Leopard build error; will test locally.

@felixbuenemann

@adamv: I tried it in a vm, it's also failing without the patches, see my comment about CC above. The error is:

error: can't exec '/Developer/Library/Xcode/PrivatePlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/LLVM GCC 4.2.xcplugin/Contents/Resources/cc' (No such file or directory)

It is caused by CC=cc instead of full path. Maybe it's caused by a recent change to superenv?

If you break into a shell and do make CC=/usr/bin/ccthen the build will succeed.

Library/Formula/macvim.rb
@@ -24,6 +24,19 @@ class Macvim < Formula
depends_on :python => :recommended
# Help us! :python3 in MacVim makes the window disappear, so only 2.x bindings!
+ # Mavericks Patches:
+ # * Fix Ruby.framework detection on OS X 10.9
+ # * Allow building against specific Ruby.framework version matcing ruby-command
@adamv Owner
adamv added a note

Is this specific change 10.9 specific or not?

Well given that all older OS X versions ship only with Ruby.framework 1.8 but 10.9 ships with 1.8 and 2.0 it is specific to Mavericks, but it doesn't break on older versions of OS X. Alternatively we could keep the code as is and compile against 2.0 framework event if the ruby-command passed is ruby 1.8 as in the case of homebrew. Alternatively I could look into the differences between the vim and macvim configure script, because the vim one already works fine with different framework rubies without patching.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@pavelbrylov

@felixbuenemann

$  ls /Applications/Xcode5-DP3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Ruby.framework/Versions/1.8/Headers
config.h   digest.h   dlconfig.h dtrace.h   intern.h   node.h     regex.h    rubyio.h   st.h       version.h
defines.h  dl.h       dln.h      env.h      missing.h  re.h       ruby.h     rubysig.h  util.h
@felixbuenemann

@pavelbrylov The headers are fine, but according to log output superenv removed -isysroot /Applications/Xcode5-DP3.app/Contents/Developer/Platforms/MacOSX.platform/Developer//SDKs/MacOSX10.9.sdk from the build flags, which seems wrong to me. Could you check brew doctor and wether xcode-select -p points to the proper Xcode Developer directory?

@felixbuenemann

@adamv Apple released a new version of the CLI tools package that brings back all the system headers in /System/Library/Frameworks, which will make Mavericks behave a lot more like older OS X versions. I'll update the patches accordingly in the next days. This will definitely fix a lot of stuff that was broken on 10.9.

Update: Unfortunately the new CLI pkg is broken and is missing Python.framework headers. I opened a bug report for that, so it'll hopefully be fixed in the next release.

@jzelinskie

Good find @felixbuenemann. I'm surprised Apple has been so indecisive.

@mxcl
Collaborator

@pavelbrylov The headers are fine, but according to log output superenv removed -isysroot /Applications/Xcode5-DP3.app/Contents/Developer/Platforms/MacOSX.platform/Developer//SDKs/MacOSX10.9.sdk from the build flags, which seems wrong to me. Could you check brew doctor and wether xcode-select -p points to the proper Xcode Developer directory?

superenv will remove anything like that as it manages such arguments itself. Here superenv adds that line back in itself (or something like it).

@felixbuenemann

Revised to remove Tcl detection fixes that are no longer needed on 10.9 13A538g (DP5) / Xcode5-DP5.

On a side note: Python Headers in /System/Library/Frameworks are back.

@mikker

@felixbuenemann So, what do I have to do to get the python headers into Xcode and make macvim build?

@felixbuenemann

@mikker If you build macvim from this PR, being on 10.9 DP5 and running xcode-select --install to install the command line tools should be enough. If you already have the cli tools, you should be able to update the through software update.

@pavelbrylov

@felixbuenemann I can confirm it works now. Thank you so much!

@stephencelis

MacVim stable is at 7.4 now, so only the "unstable" patch should be referenced.

@felixbuenemann

@stephencelis Thanks for the update, rebased the formula and inlined the patch.

@sheerun

Works like a charm on 10.9 DP5 with XCode and CLT.

@nitinverma

Not able to upgrade MacVIM, getting the floowing error

==> ./configure --with-features=huge --enable-multibyte --with-macarchs=x86_64 --enable-perlinterp --enable-rubyinterp --enable-tclinterp --with-ruby-command=/System/Library/Frameworks/Ruby.framework/Versions/1.
==> make
1 error generated.
make[1]: *** [objects/if_python.o] Error 1
make[1]: *** Waiting for unfinished jobs....
brew: superenv removed: -Wall -Wno-unknown-pragmas -g -O2
make: *** [first] Error 2

READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting

These open issues may also help:
#20473

@adamv
Owner

@nitinverma

READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting

Please provide the troubleshooting information requested; if you are not running 10.9, please open a new issue.

@xironix

@felixbuenemann Thank you for the fix. =D

@felixbuenemann

Rebased on master. Will review the ruby detection patches soon, to see if they can be simplified.

@ELLIOTTCABLE

Tried this patch with Snapshot 71 (see ELLIOTTCABLE@285a6c3 on top of ELLIOTTCABLE@8a85841 from #22377), works fine.

Since it's mentioned absolutely nowhere that I can find … against all the lore I could find Out And About, you don't xcode-select to the CLT to install this. You install the Xcode 5 DP6, and then run the following, before building this formula:

sudo xcode-select -switch /Applications/Xcode5-DP6.app/Contents/Developer
@felixbuenemann

@ELLIOTTCABLE I've got both Xcode and CLT installed. What problems did you have with CLT only?

@ELLIOTTCABLE

@felixbuenemann

xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory
   '/Library/Developer/CommandLineTools' is a command line tools instance

xcode-select -s /Library/Developer/CommandLineTools: http://ell.io/g6487080
xcode-select -s /Applications/Xcode5-DP6.app/Contents/Developer: http://ell.io/g6487165

@felixbuenemann

The formula has depends_on :xcode, so maybe the xcode detection isn't working properly on Mavericks.

@sethbc

@ELLIOTTCABLE the steps in your post above (xcode-selecting DP6) and @felixbuenemann patch (see ELLIOTTCABLE@285a6c3 on top of ELLIOTTCABLE@8a85841 from #22377) fixed compilation for me.

@ELLIOTTCABLE

@sethbc yes, it works with Xcode, that's known. The problem is that the formula's xcode-detection doesn't seem to be working; i.e. instead of a warning, if you try to compile it without Xcode (which many people are doing; as much in Homebrew works with just the CLT installed), there's no warning … just a failure, which you have to re-run the install with -v to discover the reason for.

@felixbuenemann

Rebased to 7.4-71, minimized patches.

@esebastian

Hi,

I'm not able to upgrade macvim to 7.4-71 on 10.9-DP8 with Xcode 5. I have also installed the apple-gcc422 package, but I get the same error every time:

checking uint32_t is 32 bits... configure: error: WRONG! uint32_t not defined correctly.

Here's the output of my brew --config:

HOMEBREW_VERSION: 0.9.5
ORIGIN: https://github.com/mxcl/homebrew.git
HEAD: 57272977eaa0ec0509a29be6c8e90b5f4b338f65
HOMEBREW_PREFIX: /usr/local
HOMEBREW_CELLAR: /usr/local/Cellar
CPU: dual-core 64-bit penryn
OS X: 10.9-x86_64
Xcode: 5.0 => /Applications/Xcode.app/Contents/Developer
GCC-4.2: build 5666
LLVM-GCC: N/A
Clang: 5.0 build 500
X11: N/A
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /usr/local/bin/python => /usr/local/Cellar/python/2.7.5/Frameworks/Python.framework/Versions/2.7/bin/python2.7
Ruby: /usr/local/bin/ruby => /usr/local/Cellar/ruby/2.0.0-p247/bin/ruby
@felixbuenemann

Make sure you have Xcode5 DP6 not GM, GM does not have the 10.9 SDK.

@esebastian

My bad, my Xcode5 it's actually GM. I'll try with DP6. Thank you.

@jensraaby

This isn't working in the GM seed of Mavericks and Xcode 5.0.1 (5A2034a)

@felixbuenemann

@jensraaby You probably upgraded Xcode Command Line Tools to 5.0.1 before installing 10.9 GM, so you need to reinstall the CLI Tools, because they were removed by the Mavericks installer.

@pwnall

FWIW, this worked for me on a clean install of 10.9 GM with the Xcode 5.0.1 GM.

@mistydemeo
Owner

@wsantos We need your full build logs to diagnose.

@jensraaby

Here's what I got (note I am using boxen, but the homebrew installed has the latest commit)
https://gist.github.com/jensraaby/6859569

@felixbuenemann

@jensraaby Are you sure you're using the right version of the formula? It looks like your os_mac.h wasn't patched. You didn't include all output in your gist so I can't see if it applied the patches before running configure.

@wsantos

Yeap wrong formula, thnkx all

@jensraaby

Thanks. I manually updated the Formula to check. Now It's cscope that is causing problems. Hopefully I'll track this down somehow. I have tried uninstalling cscope and reinstalling but it didn't make a difference.

Error: macvim dependency cscope was built with the following
C++ standard library: libstdc++ (from clang)

This is incompatible with the standard library being used
to build macvim: libc++ (from clang)
@mistydemeo
Owner

That's an unrelated error, currently being tracked in #23089.

@jensraaby

Now the other issue is fixed for me... back to macvim

==> ./configure --with-features=huge --enable-multibyte --with-macarchs=x86_64 -
==> make
brew: superenv removed: -Wall -Wno-unknown-pragmas -g -O2
1 error generated.
make[1]: *** [objects/os_unix.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [first] Error 2
@tomfarm

On my machine (10.9, Xcode 5.0.1 + command line tools) I get this error when I compile the homebrew macvim manually

HOMEBREW_VERSION: 0.9.5
ORIGIN: https://github.com/mxcl/homebrew
HEAD: f40af36f909a1ab0a6c409254f5944fe477392ae
HOMEBREW_PREFIX: /opt/boxen/homebrew
HOMEBREW_CELLAR: /opt/boxen/homebrew/Cellar
CPU: 8-core 64-bit ivybridge
OS X: 10.9-x86_64
Xcode: 5.0.1
GCC-4.2: build 5666
LLVM-GCC: N/A
Clang: 5.0 build 500
X11: 2.7.4 => /opt/X11
System Ruby: 1.8.7-358
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /opt/boxen/rbenv/shims/ruby
==> ./configure --with-features=huge --enable-multibyte --with-macarchs=x86_64 --enable-perlinterp --enable-rubyinterp --enable-tclinterp --with-ruby-command=/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby --with-tlib=ncurses --with-compiledby=Homebrew --with-local-dir=/opt/boxen/homebrew --enable-cscope --enable-pythoninterp=yes
make
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp -I/opt/boxen/homebrew/include  -I/opt/boxen/homebrew/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1   -o objects/misc1.o misc1.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp -I/opt/boxen/homebrew/include  -I/opt/boxen/homebrew/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1   -o objects/misc2.o misc2.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp -I/opt/boxen/homebrew/include  -I/opt/boxen/homebrew/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1   -o objects/move.o move.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp -I/opt/boxen/homebrew/include  -I/opt/boxen/homebrew/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1   -o objects/mbyte.o mbyte.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp -I/opt/boxen/homebrew/include  -I/opt/boxen/homebrew/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1   -o objects/normal.o normal.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp -I/opt/boxen/homebrew/include  -I/opt/boxen/homebrew/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1   -o objects/ops.o ops.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp -I/opt/boxen/homebrew/include  -I/opt/boxen/homebrew/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1   -o objects/option.o option.c
gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_MACVIM -Wall -Wno-unknown-pragmas -pipe  -DMACOS_X_UNIX -no-cpp-precomp -I/opt/boxen/homebrew/include  -I/opt/boxen/homebrew/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1     -I/System/Library/Frameworks/Tcl.framework/Headers  -D_REENTRANT=1  -D_THREAD_SAFE=1  -D_DARWIN_C_SOURCE=1   -o objects/os_unix.o os_unix.c
os_unix.c:830:46: warning: declaration of 'struct sigaltstack' will not be visible outside of this function [-Wvisibility]
        extern int sigaltstack __ARGS((const struct sigaltstack *ss, struct sigaltstack *oss));
                                                    ^
./os_unix.h:88:21: note: expanded from macro '__ARGS'
#  define __ARGS(x) x
                    ^
os_unix.c:830:13: error: conflicting types for 'sigaltstack'
        extern int sigaltstack __ARGS((const struct sigaltstack *ss, struct sigaltstack *oss));
                   ^
/usr/include/signal.h:85:5: note: previous declaration is here
int     sigaltstack(const stack_t * __restrict, stack_t * __restrict)  __DARWIN_ALIAS(sigaltstack);
        ^
1 warning and 1 error generated.
make[1]: *** [objects/os_unix.o] Error 1
make: *** [first] Error 2
@felixbuenemann

@tomfarm You're not using the macvim Formula from this pullrequest.

@tomfarm

Ok :) sorry. Using your pull request macvim builds correctly

@fousa

Hi Felix,

I use the formula from the pull request, but for some reason the Ruby/Python support isn't enabled. Any idea why? The ARGS are passed by default, no?

@felixbuenemann

AvailabilityMacros.h/signaltstack fix merged in macvim master: b4winckler/macvim@df7b6fb

@felixbuenemann

@fousa Please install/reinstall Xcode Command Line Tools 5.0.1 and recompile macvim.

@fousa

@felixbuenemann Perfect! Thanks!

@lukaszb

FYI:

This worked for me:

  • Updated to 10.9 GM
  • installed Command Line Tools (invoked by typing make in the terminal)
  • installed Xcode 5 (from App Store)
  • updated to Xcode 5.0.1 GM

This however did NOT work:

  • Fresh install of 10.9 GM
  • Installed Xcode 5.0.1 GM (without previously installing older Xcode or CLTools)

Log:

brew install https://raw.github.com/felixbuenemann/homebrew/81824e31564538e9df4d0552cf5063691f17c688/Library/Formula/macvim.rb --override-system-vim
######################################################################## 100.0%
==> Downloading https://github.com/b4winckler/macvim/archive/snapshot-71.tar.gz
Already downloaded: /Library/Caches/Homebrew/macvim-7.4-71.tar.gz
==> Patching
patching file src/auto/configure
Hunk #1 succeeded at 7211 (offset 3 lines).
patching file src/if_ruby.c
patching file src/os_mac.h
==> ./configure --with-features=huge --enable-multibyte --with-macarchs=x86_64 --enable-perlinterp --enable-rubyinterp --enable-tclinterp --with-ruby-command=
==> make
brew: superenv removed: -Wall -Wno-unknown-pragmas -g -O2 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer//SDKs/MacOSX10.9.sdk
1 error generated.
make[1]: *** [objects/if_python.o] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [first] Error 2

READ THIS: https://github.com/mxcl/homebrew/wiki/troubleshooting

These open issues may also help:
    https://github.com/mxcl/homebrew/pull/20473
    https://github.com/mxcl/homebrew/issues/22515
@jensraaby

Confirmed it now all works with this PR.

This is a fresh install of 10.9, with Xcode 5.0.1 seed, and the manually downloaded Command Line tools.

@hunterwei
  1. Upgrade from 10.8 to 10.9
  2. Upgrade Xcode 5.0 to 5.0.1
  3. Run following works flawless brew install https://raw.github.com/felixbuenemann/homebrew/81824e31564538e9df4d0552cf5063691f17c688/Library/Formula/macvim.rb --override-system-vim
@xironix

@hunterwei perfectly splendid!

@pencilcheck

@hunterwei that works for me as well!

@bothra90

I get the following:
Username for 'https://github.com':
Password for 'https://github.com':
remote: Repository not found.
fatal: Authentication failed for 'https://github.com/com/homebrew-felixbuenemann/'

Will be great if somebody can help.

@KevinSjoberg

I guess this can be merged now?

@felixbuenemann felixbuenemann macvim: Fix compilation on Mac OS X 10.9
On Mavericks we need to explicitly include AvailabilityMacros.h to have
the version detection macros defined.

Fix 10.9 ruby framework detection and compilation

Mavericks ships with version 1.8 and 2.0 of the Ruby.framework, so we
must directly link the framework version matching the ruby-command.

This also means that ruby.h must no longer included via the framework
name, which has the nice side effect of allowing you to compile with
non-framework rubies, if you remove the formula's hardcoded RUBY_PATH.

For macvim-HEAD we use the curren framework's ruby command because it
only works with that and is incompatible with our patches.
4d4fe3c
@felixbuenemann

@bothra90 The repository url you used is completely wrong, it should be https://github.com/felixbuenemann/homebrew although you could also just use this formula directly:

brew install https://raw.github.com/felixbuenemann/homebrew/macvim-fix-mavericks-compile/Library/Formula/macvim.rb

To maintainers:
Note that there already is a fix in macvim head, so if a new snapshot is released this wouldn't be required. However, the patches in MacVim HEAD only allow compiling against the current Ruby.framework, so we cannot use homebrew's RUBY_PATH, which still points to ruby 1.8.7.

I've updated the formula to allow building of macvim-HEAD in 4d4fe3c.

@mikemcquaid mikemcquaid closed this pull request from a commit
@felixbuenemann felixbuenemann macvim: fix compilation on 10.9.
On Mavericks we need to explicitly include AvailabilityMacros.h to have
the version detection macros defined.

Fix 10.9 ruby framework detection and compilation

Mavericks ships with version 1.8 and 2.0 of the Ruby.framework, so we
must directly link the framework version matching the ruby-command.

This also means that ruby.h must no longer included via the framework
name, which has the nice side effect of allowing you to compile with
non-framework rubies, if you remove the formula's hardcoded RUBY_PATH.

For macvim-HEAD we use the current framework's ruby command because it
only works with that and is incompatible with our patches.

Closes #20473.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
41d80fb
@lsdr lsdr referenced this pull request in lsdr/homebrew-stan
Open

Possible problems building melee-vim in OS 10.9 #1

@jokeyrhyme

I've never installed the CLI tools, just the Xcode.app itself. This is working perfectly for me today. :) Just an FYI and a thanks. :)

@trynity trynity referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@SaveTheRbtz SaveTheRbtz referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@kjedamzik kjedamzik referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@sunliwen sunliwen referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@pborzenkov pborzenkov referenced this pull request from a commit
Commit has since been removed from the repository and is no longer available.
@ehershey ehershey referenced this pull request from a commit in ehershey/homebrew
@felixbuenemann felixbuenemann macvim: fix compilation on 10.9.
On Mavericks we need to explicitly include AvailabilityMacros.h to have
the version detection macros defined.

Fix 10.9 ruby framework detection and compilation

Mavericks ships with version 1.8 and 2.0 of the Ruby.framework, so we
must directly link the framework version matching the ruby-command.

This also means that ruby.h must no longer included via the framework
name, which has the nice side effect of allowing you to compile with
non-framework rubies, if you remove the formula's hardcoded RUBY_PATH.

For macvim-HEAD we use the current framework's ruby command because it
only works with that and is incompatible with our patches.

Closes #20473.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
f3ae367
@shelhamer shelhamer referenced this pull request from a commit
@felixbuenemann felixbuenemann macvim: fix compilation on 10.9.
On Mavericks we need to explicitly include AvailabilityMacros.h to have
the version detection macros defined.

Fix 10.9 ruby framework detection and compilation

Mavericks ships with version 1.8 and 2.0 of the Ruby.framework, so we
must directly link the framework version matching the ruby-command.

This also means that ruby.h must no longer included via the framework
name, which has the nice side effect of allowing you to compile with
non-framework rubies, if you remove the formula's hardcoded RUBY_PATH.

For macvim-HEAD we use the current framework's ruby command because it
only works with that and is incompatible with our patches.

Closes #20473.

Signed-off-by: Mike McQuaid <mike@mikemcquaid.com>
94185c2
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Commits on Oct 23, 2013
  1. @felixbuenemann

    macvim: Fix compilation on Mac OS X 10.9

    felixbuenemann authored
    On Mavericks we need to explicitly include AvailabilityMacros.h to have
    the version detection macros defined.
    
    Fix 10.9 ruby framework detection and compilation
    
    Mavericks ships with version 1.8 and 2.0 of the Ruby.framework, so we
    must directly link the framework version matching the ruby-command.
    
    This also means that ruby.h must no longer included via the framework
    name, which has the nice side effect of allowing you to compile with
    non-framework rubies, if you remove the formula's hardcoded RUBY_PATH.
    
    For macvim-HEAD we use the curren framework's ruby command because it
    only works with that and is incompatible with our patches.
This page is out of date. Refresh to see the latest.
Showing with 61 additions and 1 deletion.
  1. +61 −1 Library/Formula/macvim.rb
View
62 Library/Formula/macvim.rb
@@ -22,6 +22,14 @@ class Macvim < Formula
env :std if MacOS.version <= :snow_leopard
# Help us! We'd like to use superenv in these environments too
+ # Mavericks Patches:
+ # * Fix Ruby.framework detection on OS X 10.9
+ # * Allow building against specific Ruby.framework version matcing ruby-command
+ # * Add missing version macros include for 10.9
+ def patches
+ DATA unless build.head?
+ end
+
def install
# Set ARCHFLAGS so the Python app (with C extension) that is
# used to create the custom icons will not try to compile in
@@ -31,6 +39,9 @@ def install
# If building for 10.7 or up, make sure that CC is set to "clang".
ENV.clang if MacOS.version >= :lion
+ # macvim HEAD only works with the current Ruby.framework because it builds with -framework Ruby
+ system_ruby = build.head? ? "/System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/ruby" : RUBY_PATH
+
args = %W[
--with-features=huge
--enable-multibyte
@@ -38,7 +49,7 @@ def install
--enable-perlinterp
--enable-rubyinterp
--enable-tclinterp
- --with-ruby-command=#{RUBY_PATH}
@mikemcquaid Owner

Why does this need changed?

Because the brew binary still uses ruby 1.8 which RUBY_PATH is derived from, so configure would detect ruby version 1.8 while compiling against the Ruby 2.0 framework, which would fail. This is because it uses -framework Rubyto compile, which will choose the Current version, which will be 1.8 on older OS X and 2.0 on 10.9. So using the Current ruby binary just matches the version detection to the Current framework.

Another approach would be to adjust configure to compile against the Ruby framework matching the ruby-command but I don't see the value of using an outdated framework.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
+ --with-ruby-command=#{system_ruby}
--with-tlib=ncurses
--with-compiledby=Homebrew
--with-local-dir=#{HOMEBREW_PREFIX}
@@ -116,3 +127,52 @@ def caveats; <<-EOS.undent
EOS
end
end
+
+__END__
+diff --git a/src/auto/configure b/src/auto/configure
+index 4fd7b82..08af7f3 100755
+--- a/src/auto/configure
++++ b/src/auto/configure
+@@ -7206,8 +7208,9 @@ echo "${ECHO_T}$rubyhdrdir" >&6; }
+ librubyarg="$librubyarg"
+ RUBY_LIBS="$RUBY_LIBS -L$rubylibdir"
+ elif test -d "/System/Library/Frameworks/Ruby.framework"; then
+- RUBY_LIBS="-framework Ruby"
+- RUBY_CFLAGS=
++ ruby_fw_ver=`$vi_cv_path_ruby -r rbconfig -e "print $ruby_rbconfig::CONFIG['ruby_version'][0,3]"`
++ RUBY_LIBS="/System/Library/Frameworks/Ruby.framework/Versions/$ruby_fw_ver/Ruby"
++ RUBY_CFLAGS="-I/System/Library/Frameworks/Ruby.framework/Versions/$ruby_fw_ver/Headers -DRUBY_VERSION=$rubyversion"
+ librubyarg=
+ fi
+
+diff --git a/src/if_ruby.c b/src/if_ruby.c
+index 4436e06..44fd5ee 100644
+--- a/src/if_ruby.c
++++ b/src/if_ruby.c
+@@ -96,11 +96,7 @@
+ # define rb_num2int rb_num2int_stub
+ #endif
+
+-#ifdef FEAT_GUI_MACVIM
+-# include <Ruby/ruby.h>
+-#else
+-# include <ruby.h>
+-#endif
++#include <ruby.h>
+ #ifdef RUBY19_OR_LATER
+ # include <ruby/encoding.h>
+ #endif
+diff --git a/src/os_mac.h b/src/os_mac.h
+index 78b79c2..54009ab 100644
+--- a/src/os_mac.h
++++ b/src/os_mac.h
+@@ -16,6 +16,9 @@
+ # define OPAQUE_TOOLBOX_STRUCTS 0
+ #endif
+
++/* Include MAC_OS_X_VERSION_* macros */
++#include <AvailabilityMacros.h>
++
+ /*
+ * Macintosh machine-dependent things.
+ *
Something went wrong with that request. Please try again.