Fix #13012 properly (recursion stack overfl.) #13037

samueljohn · 2012-06-26T13:03:10Z

Fix #13012 properly and don't set the SDK if CLT

Undoing parts of the hot fix 78b9e85.

The only thing missing was to check for system "/usr/bin/xcrun -find make 1>/dev/null 2>&1"
and then it's safe to call locate.

This commit restores the original functionality but without the risk for recursion
and improves the logic of MacOS.locate. See below.

To important changes in this commit:

For Xcode and CLT: don't add the SDK and leave things as before.
So if MacOS.clt_installed?, then no SDKROOT and -L and -I
directories are set in ENV.macosxsdk.
Improved the logic for MacOS.locate for Xcode-only situations
by assuring that the xcode-select path is correct. This is done
by checking that bin/make exists and is executable. Otherwise it
was possible to set xcode-select to an empty dir.
This check is done in MacOS.sdk_path too.
We are now able to use Xcode wherever it is and can work even, if
xcode-select is set to invalid values. (Remember some users don't
have sudo access and that is needed to fix xcode-select).

Some minor whitespace fixes.
Minor backtick fix in doctor.rb's printout.

samueljohn · 2012-06-26T14:23:00Z

Library/Homebrew/utils.rb

@@ -423,7 +428,7 @@ def xcode_prefix
    @xcode_prefix ||= begin
      path = `/usr/bin/xcode-select -print-path 2>/dev/null`.chomp
      path = Pathname.new path
-      if $?.success? and path.directory? and path.absolute?
+      if $?.success? and path.directory? and path.absolute? and !xctools_fucked?


... we cannot trust xcode-select, so check additionally if xctools_fucked.

samueljohn · 2012-06-26T14:24:33Z

I incorporated @MikeMcQuaid suggestions from the first version of this patch.
The functionality is as initially intended but without the possibility of a recursion.

ping @mistydemeo.

samueljohn · 2012-06-26T16:16:49Z

commit message updated. @MikeMcQuaid, alright?

MikeMcQuaid · 2012-06-26T17:02:01Z

That's cool, thanks.

jacknagel · 2012-06-27T00:09:55Z

Library/Homebrew/utils.rb

@@ -299,28 +299,28 @@ def locate tool

    if File.executable? "/usr/bin/#{tool}"
      path = Pathname.new "/usr/bin/#{tool}"
-    elsif not MacOS.xctools_fucked? and system "/usr/bin/xcrun -find #{tool} 1>/dev/null 2>&1"
+    elsif not MacOS.xctools_fucked? and system "/usr/bin/xcrun -find #{tool} &>/dev/null"


&> is a bashism, and while bash is the standard shell on OS X for now, it may not always be, so we should try to use portable constructs.

If they change the default from Bash it will be to ZSH which also supports this.

Perhaps, but there's really no reason to avoid the portable idiom here.

Ok, @jacknagel what is the suggested portable idiom?
(we should think of the guys trying to port homebrew to linux and such)

1>/dev/null 2>&1 (as it was before) is fine.

samueljohn · 2012-06-27T11:50:18Z

Library/Homebrew/cmd/doctor.rb

@@ -210,7 +210,7 @@ def check_for_broken_symlinks
    end
  end
  unless broken_symlinks.empty? then <<-EOS.undent
-    Broken symlinks were found. Remove them with `brew prune':
+    Broken symlinks were found. Remove them with `brew prune`:


this is just a small thing but to be consistent with other places and with the github markdown style.

samueljohn · 2012-06-27T12:24:31Z

@mistydemeo @jacknagel @MikeMcQuaid and @adamv I urge you to please, please let this into homebrew ASAP. Feel free to change minor issues yourself. We have some reports about postgresql, graphviz, valgrind and some other fail if the SDK from Xcode is in the "-L" path. This commit fixes that, too.

Undoing parts of the hot fix 78b9e85. The only thing missing was to check for `system "/usr/bin/xcrun -find make 1>/dev/null 2>&1"` and then it's safe to call locate. This commit restores the original functionality but without the risk for recursion and improves the logic of `MacOS.locate`. See below. To important changes in this commit: - For Xcode _and_ CLT: don't add the SDK and leave things as before. So if `MacOS.clt_installed?`, then no `SDKROOT` and `-L` and `-I` directories are set in `ENV.macosxsdk`. - Improved the logic for `MacOS.locate` for Xcode-only situations by assuring that the xcode-select path is correct. This is done by checking that `bin/make` exists and is executable. Otherwise it was possible to set xcode-select to an empty dir. This check is done in `MacOS.sdk_path` too. We are now able to use Xcode wherever it is and can work even, if xcode-select is set to invalid values. (Remember some users don't have sudo access and that is needed to fix xcode-select). Some minor whitespace fixes. Minor backtick fix in doctor.rb's printout.

adamv · 2012-06-27T18:52:50Z

I'm going to pull this. Shit is broken.

mistydemeo · 2012-06-27T18:54:59Z

@adamv Go ahead, it looks like @samueljohn just updated this to fix the remaining issue.

adamv · 2012-06-27T18:56:48Z

Pulled.

mistydemeo · 2012-06-27T18:57:30Z

Library/Homebrew/utils.rb

+      # Since we are pretty unrelenting in finding Xcode no matter where
+      # it hides, we can now throw in the towel.
+      opoo "You really should consult the `brew doctor`!"
+      ""


This doesn't cause a problem now because we only use dev_tools_path as a string, but returning a different type of object in this case could theoretically cause problems in the future.

If we're not returning a path at all, maybe this should be a showstopper that raises an exception, rather than returning an empty string.

True. I wanted brew list and other still to function even if no compiler/Xcode or whatever is found since raising an exception may be too harsh.

We could add a DevToolsMissingError exception and just ignore it in the appropriate places.

That sounds like a clean solution. I am not the best person to
implement that, however. I am still new to homebrew after all.

Dipl.-Inform. Samuel John

PhD student,
Neuroinformatics Group, Faculty
of Technology, D33594 Bielefeld

+49 (0)1577 573 0 572
[email protected]
[email protected]
jabber: [email protected]

Am 28.06.2012 um 07:21 schrieb Jack Nagel
[email protected]:

elsif File.exist? "#{xcode_prefix}/usr/bin/make" # cc stopped existing with Xcode 4.3, there are c89 and c99 options though Pathname.new "#{xcode_prefix}/usr/bin" else

# yes this seems dumb, but we can't throw because the existance of

# dev tools is not mandatory for installing formula. Eventually we

# should make formula specify if they need dev tools or not.

Pathname.new "/usr/bin"

# Since we are pretty unrelenting in finding Xcode no matter where

# it hides, we can now throw in the towel.

opoo "You really should consult the `brew doctor`!"

""

We could add an DevToolsMissingError exception and just ignore it in the appropriate places.

Reply to this email directly or view it on GitHub:
https://github.com/mxcl/homebrew/pull/13037/files#r1065757

I'll look into it.

We could actually call the appropriate doctor check directly and print that as part of the exception message.

Looks like the best bet here would be to return nil, and then do this where necessary:

raise DeveloperToolsNotFoundError if MacOS.dev_tools_path.nil?

and have DeveloperToolsNotFoundError call the right doctor check and print the output. I'll work up a patch today or tomorrow.

samueljohn mentioned this pull request Jun 26, 2012

Stack overflow error #13012

Closed

samueljohn reviewed Jun 26, 2012
View reviewed changes

This was referenced Jun 26, 2012

install of graphviz fails #13025

Closed

Postgresql fails to install #13022

Closed

samueljohn mentioned this pull request Jun 26, 2012

Valgrind fails to build on Lion (While linking, fails to find __bzero) #13042

Closed

2bits mentioned this pull request Jun 26, 2012

Python fails to install on MacOS 10.8 #13035

Closed

samueljohn mentioned this pull request Jun 26, 2012

brew install postgresql fails during link step in Mac OS (10.7.4) with XCode 4.3.3 #13044

Closed

jacknagel reviewed Jun 27, 2012
View reviewed changes

2bits mentioned this pull request Jun 27, 2012

xpdf fails after clean install of homebrew #13040

Closed

samueljohn reviewed Jun 27, 2012
View reviewed changes

This was referenced Jun 27, 2012

use XQuartz when present #12607

Closed

brew install ruby fails on readline.c #13046

Closed

adamv closed this Jun 27, 2012

mistydemeo reviewed Jun 27, 2012
View reviewed changes

adamv mentioned this pull request Jun 27, 2012

Fix rlwrap on 10.7.4 #13016

Closed

jeffstyr mentioned this pull request Jul 6, 2012

brew install ruby failure #13225

Closed

Homebrew locked and limited conversation to collaborators Feb 16, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix #13012 properly (recursion stack overfl.) #13037

Fix #13012 properly (recursion stack overfl.) #13037

samueljohn commented Jun 26, 2012

samueljohn Jun 26, 2012

samueljohn commented Jun 26, 2012

samueljohn commented Jun 26, 2012

MikeMcQuaid commented Jun 26, 2012

jacknagel Jun 27, 2012

MikeMcQuaid Jun 27, 2012

jacknagel Jun 27, 2012

samueljohn Jun 27, 2012

jacknagel Jun 27, 2012

samueljohn Jun 27, 2012

samueljohn commented Jun 27, 2012

adamv commented Jun 27, 2012

mistydemeo commented Jun 27, 2012

adamv commented Jun 27, 2012

mistydemeo Jun 27, 2012

samueljohn Jun 27, 2012

jacknagel Jun 28, 2012

samueljohn Jun 28, 2012

jacknagel Jun 28, 2012

jacknagel Jun 28, 2012

Fix #13012 properly (recursion stack overfl.) #13037

Fix #13012 properly (recursion stack overfl.) #13037

Conversation

samueljohn commented Jun 26, 2012

Choose a reason for hiding this comment

samueljohn commented Jun 26, 2012

samueljohn commented Jun 26, 2012

MikeMcQuaid commented Jun 26, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

samueljohn commented Jun 27, 2012

adamv commented Jun 27, 2012

mistydemeo commented Jun 27, 2012

adamv commented Jun 27, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment