Experimental support for non-Apple GCCs #20251

Closed
wants to merge 6 commits into
from

Projects

None yet
@mistydemeo
Contributor

This is really preliminary. I didn't change much except a few lines in superenv.

This adds support for building software using a Homebrew-installed, non-Apple GCC. I've tested so far using gcc48 from homebrew/versions, and was able to successfully build gource on Snow Leopard (which can't be built with any Apple-provided compilers on Xcode 3.2.6).

There are a few limitations:

  • Only superenv is supported. Not sure if it's worth adding support to stdenv.
  • No --use-foo switch is supported, only the HOMEBREW_CC environment variable. For instance, HOMEBREW_CC=gcc-4.8.

To test on < Lion, create a symlink in ENV to enable superenv. (It seems to be working reliably now.)

@samueljohn samueljohn commented on the diff Jun 4, 2013
Library/ENV/4.3/cc
@@ -67,10 +67,8 @@ class Cmd
'clang++'
when /llvm-gcc/
'g++'
- when /gcc(-4.2)?$/
- 'g++-4.2'
- when /gcc-4.0/
- 'g++-4.0'
+ when /gcc(-\d\.\d)?$/
@samueljohn
samueljohn Jun 4, 2013 Contributor

would this (wrongly) capture llvm-gcc-1.2, too?

@mistydemeo
mistydemeo Jun 4, 2013 Contributor

That's not a supported value for HOMEBREW_CC, which is already sanitized before cc is called.

@samueljohn
samueljohn Jun 4, 2013 Contributor

alright.

@samueljohn
Contributor

In principle I like this but we should still push clang. I think we had a discussion on the mailing list about this and I remember there was a tendency to do something like suggested here.

@mistydemeo
Contributor

Not arguing otherwise! However:

  • Some people need newer GCC for whatever reason, and we should support that. We've had numerous requests, and yeah, that mailing list discussion was the inspiration here.
  • We already provide formulae for newer GCC, which is obviously of more limited use if we make people then build software outside Homebrew just to make use of the compilers they just built with Homebrew.
  • A usable clang just straight up isn't available on Snow Leopard and earlier. I'm not yet ready to throw these users to the wolves where newer C++ stuff is concerned. We may also be able to build newer Apple or non-Apple clang for these platforms, which we could do in addition to supporting newer GCCs.
@samueljohn
Contributor

I wasn't arguing against this PR. I am +1 on this.

@cooljeanius

I am +1 on this.

Me too.

@mistydemeo
Contributor

I'll keep this rebased on master frequently. If you want to try it out:

git remote add mistydemeo https://github.com/mistydemeo/homebrew.git
git fetch mistydemeo
git checkout superenv_non_apple_compiler

You'll want to pull periodically for updates.

Any users interested in testing and seeing what does/doesn't work, feedback would be appreciated!

@jacknagel
Contributor

Just a note, I'd like to see integration with fails_with before this lands in core.

@jacknagel
Contributor

I wrote up some DSL ideas a while back: https://gist.github.com/jacknagel/5149739

@mistydemeo
Contributor

Oh, nice! I like that DSL.

Definitely shouldn't merge until the appropriate mechanisms are in place (and it's been tested more).

@MikeMcQuaid
Member

Looks good to me. Agreed with @jacknagel that fails_with integration wants in first. I also think given that 10.9 is on the horizon, LLVM-GCC is being dropped and we still have a bunch of things that fail with Clang we should just pull GCC keg-only into core and perhaps even never use LLVM-GCC regardless of if it's available.

@samueljohn
Contributor

Agree with Mike here but remember there is the bug that formulae removed from taps and put into core break brew update.

@adamv adamv referenced this pull request Jun 17, 2013
Closed

ghc Fails to Build on 10.9 #20546

@mistydemeo
Contributor

we should just pull GCC keg-only into core

Not sure this is a good idea, considering how many versions there are. Directing people to homebrew/versions might be the best bet - especially if stuff that requires GCC goes into a separate tap.

never use LLVM-GCC regardless of if it's available.

Agreed, we shouldn't use llvm-gcc anymore.

@dhess
Contributor
dhess commented Jun 17, 2013

The C++ ABI is complex enough that there will probably be occasional compatibility issues for some C++ libraries compiled with one compiler and linked from another, e.g., Boost is compiled with Clang for one project but needed by another that requires GCC. The Clang libc++ page (http://libcxx.llvm.org) states that:

ABI compatibility with gcc's libstdc++ for some low-level features such as exception objects, rtti and memory allocation.

Even different versions of GCC occasionally break compatibility (see http://gcc.gnu.org/gcc-4.7/changes.html, for example).

Whatever the solution that's adopted for supporting GCC(s), it should include a mechanism for compiling and linking against compiler-specific dependencies -- separate taps/kegs/whatever.

@sjackman
Member

+1

@mistydemeo
Contributor

This is just waiting on a fails_with` implementation, which I've been too busy to write.

@mistydemeo
Contributor

fails_with implementation in, needs review. A few notes:

  • Non-Apple GCCs are returned internally as strings, rather than symbols like Apple compilers.
  • I've swapped the compiler priority for llvm-gcc and gcc-4.2, but can drop llvm-gcc from the queue entirely.
  • Non-Apple GCCs slot in priority below clang and gcc-4.2, above llvm-gcc and gcc-4.0. Right now they all share the same priority, which isn't really ideal.
  • The fails_with code needs better tests. @jacknagel - I was checking the Mocha docs and didn't find anything at a glance, is there a way to return specific values for a stubbed method given a particular argument?
@MikeMcQuaid
Member

Sounds good to me.

@mistydemeo
Contributor

Updated with working tests. (Excuse the one paragraph of fails_with code that sneaked into the first commit.) Should be working well now, review/testing is appreciated.

I'll remove llvm-gcc from the compiler selection altogether once this is merged.

@mistydemeo
Contributor

Fixed GCC priority, which is now based on version number, with newest being preferred. e.g. 4.3 gets a priority of 1.3, 4.8 gets a priority of 1.8.

@mistydemeo mistydemeo referenced this pull request Jul 2, 2013
Closed

Boost: 1.54.0 #20947

@manphiz
Contributor
manphiz commented Jul 7, 2013

As much as I'd love to see GCC improvement on Darwin, it is supposed to cause problem as FSF libstdc++ uses a different ABI than the system shipped libstdc++. As the long discussion in macports (http://trac.macports.org/ticket/35770) pointed out, the ultimate solution is to port libstdc++ to use libc++abi on Darwin, which is also used by Clang. However there is an obstacle in license compatibility as libstdc++ is using GPLv3 while libc++abi is using MIT and UIUC dual licenses (which are all BSD-style licenses).

Besides the ABI issue, there is another problem with linking to multiple copies of libstdc++, as in homebrew/versions, multiple versions of GCC ship multiple versions of libstdc++. So if a library is built using gcc47, and then linked to a program built using gcc48, the program will link to two copies of libstdc++ and may end up in problems. Macport solves this problem by only installing one copy of libstdc++, which is either from the latest release or trunk, and let all GCC versions link to that. This generally works unless when ABI incompatible switches are used, such as "--enable-libstdcxx-time=yes". Besides this doesn't fix the first issue above, IMHO I'd suggest one stick to one version of GCC.

Maybe we should also look into providing a homebrew Clang, which supports libc++abi and compatible with system ABI.

@mistydemeo
Contributor

This is a tricky situation because there are disadvantages with every option we could go with. A disadvantage to Macports's solution is that platform-specific build errors in the most recent GCC version will wipe out the ability to use any homebrewed GCC on that platform. This isn't a hypothetical and is an unsolved issue over there right now, and is most likely to hurt the platforms that need homebrewed GCC the most - Snow Leopard and older.

An alternate solution would be to record the GCC family used to build a piece of software in its install receipt, and only allow linking dependencies against things built with a compatible stdlib. Might be the simplest solution, and I would imagine it's not too likely that a user will want to mix and match, say, GCC 4.3 and 4.8 in their homebrew installs.

@MikeMcQuaid
Member

Yeh, the latter seems like a good idea. Another one is just to only allow one version of GCC to be installed at once.

@GuillaumeDIDIER
Contributor

From someone who hacked his personal homebrew so that it uses usr/local/bin/clang on Snow Leopard, having homebrew deal with brewed compilers would be quite useful.
Good luck.

@mistydemeo
Contributor

Sorry about the delays, I've been too busy with the move to finish up the stdlib tracking. I'll try to get to it sometime.

@adamv
Contributor
adamv commented Jul 17, 2013

No worries, get settled in!

@aatxe aatxe referenced this pull request Jul 20, 2013
Closed

Add head for GHC #21343

@mistydemeo
Contributor

Implemented, though I'm extraordinarily tired so it's possible there are some stupid mistakes.

A couple notes:

  • Tab writing used to take place in the formula installer, which didn't have access to compiler selection. I moved the tab writing into the build process, which doesn't seem to have had adverse consequences so far.
  • Dependency checking is happening in the build process, which is suboptimal but again a side effect of the fact that that information isn't available in the main process. In the future changing the compiler selection code so it doesn't require explicit ENV modification would help make this cleaner.
  • The stdlib tracking is a bit zealous since it has no idea if any C++ code is actually in use, so it'll nag users about stuff written in other languages, noncompiled software, etc. This won't bother too many users since the Apple compiler configurations we currently support are intercompatible, but the situation could stand to improve.
  • Need to write a short explanatory guide for the wiki re: stdlibs and compilers so users understand what the failure means. (The nonexistent page is referenced in an error message.) @manphiz - up for that?
@manphiz
Contributor
manphiz commented Jul 27, 2013

I have my finger crossed.

@adamv adamv and 1 other commented on an outdated diff Jul 30, 2013
Library/Homebrew/exceptions.rb
@@ -115,6 +115,21 @@ def initialize formula, reqs
end
end
+class IncomatibleStdlibs < Homebrew::InstallationError
@adamv
adamv Jul 30, 2013 Contributor

Spelling error in class name here

@mistydemeo
mistydemeo Jul 31, 2013 Contributor

Good catch, fixed.

@adamv adamv commented on an outdated diff Jul 30, 2013
Library/Homebrew/build.rb
@@ -146,6 +147,19 @@ def install
end
end
+ # We only support libstdc++ right now
+ stdlib_in_use = Stdlib.new(:libstdcxx, ENV.compiler)
+
+ # This is a bad place for this check, but we don't have access to
+ # compiler selection within the formula installer, only inside the
+ # build instance.
+ deps.each do |dependent|
+ dep_stdlib = Stdlib.for_tab(Tab.for_formula(dependent.to_formula))
+ if !stdlib_in_use.compatible_with? dep_stdlib
+ raise IncomatibleStdlibs.new(f, dependent, dep_stdlib, stdlib_in_use)
@adamv
adamv Jul 30, 2013 Contributor

Spelling error in class name (though it matches the class name as declared)

@adamv adamv and 1 other commented on an outdated diff Jul 30, 2013
Library/Homebrew/stdlib.rb
@@ -0,0 +1,47 @@
+class Stdlib
@adamv
adamv Jul 30, 2013 Contributor

Do we have other classes like this that pull data from the tab? Or is this the first?

@mistydemeo
mistydemeo Jul 31, 2013 Contributor

I think this is the first.

@mistydemeo
Contributor

Ping - think this is ready for additional review.

@mikemcquaid @adamv @jacknagel @manphiz

@manphiz
Contributor
manphiz commented Aug 12, 2013

Will give it a test run soon. Also about time to write up https://github.com/mxcl/homebrew/wiki/C++-Standard-Libraries I suppose.

Some minor notes: it looks like all compiler versions are hard-coded, like 4.[3-9] as well as 4.8.1. Is getting those information by introspecting homebrew-versions feasible? So that the system will keep working once gcc 4.8.2 or gcc 4.10 is out. Or maybe put all version variables into a separate module for easier maintenance.

@mistydemeo
Contributor

Yes, I thought that hardcoding might be bad practice there. Do you have any other recommendations?

We can count on homebrew-versions being tapped, because superenv depends on being able to instantiate a Formula object for the requested compiler: https://github.com/mistydemeo/homebrew/blob/67807721aa8fda15ced87a2bdf654d0d71e48e5e/Library/Homebrew/superenv.rb#L90-L108

@MikeMcQuaid
Member

Looks good to me.

@manphiz
Contributor
manphiz commented Aug 12, 2013

On a second thought, there are benefits to maintain control of supported
GCC versions, so for the time being this looks fine.

I would still suggest to have the version numbers parameterized, for
instance, at the beginning of class, so that we don't need to consult
grep/sed when GCC upgrades. Just my 2 cents.

On Aug 11, 2013 9:47 PM, "Misty De Meo" notifications@github.com wrote:

Yes, I thought that hardcoding might be bad practice there. Do you have
any other recommendations?

We can count on homebrew-versions being tapped, because superenv depends
on being able to instantiate a Formula object for the requested compiler:
https://github.com/mistydemeo/homebrew/blob/67807721aa8fda15ced87a2bdf654d0d71e48e5e/Library/Homebrew/superenv.rb#L90-L108


Reply to this email directly or view it on GitHub.

@jacknagel jacknagel and 1 other commented on an outdated diff Aug 12, 2013
Library/Homebrew/build.rb
@@ -146,6 +147,19 @@ def install
end
end
+ # We only support libstdc++ right now
+ stdlib_in_use = Stdlib.new(:libstdcxx, ENV.compiler)
+
+ # This is a bad place for this check, but we don't have access to
+ # compiler selection within the formula installer, only inside the
+ # build instance.
+ deps.each do |dependent|
+ dep_stdlib = Stdlib.for_tab(Tab.for_formula(dependent.to_formula))
@jacknagel
jacknagel Aug 12, 2013 Contributor

I don't think "dependent" is the right term, how about just "dep"?

@mistydemeo
mistydemeo Aug 16, 2013 Contributor

Changed.

@jacknagel jacknagel and 1 other commented on an outdated diff Aug 12, 2013
Library/Homebrew/stdlib.rb
@@ -0,0 +1,47 @@
+class Stdlib
+ attr_accessor :type, :compiler
+
+ def self.for_tab(tab)
+ # legacy tabs won't include values for these
+ tab.stdlib ||= :libstdcxx
+ tab.compiler ||= :clang
+
+ new(tab.stdlib.to_sym, tab.compiler.to_sym)
+ end
@jacknagel
jacknagel Aug 12, 2013 Contributor

I think having Tab know about Stdlib and Stdlib know about Tab is awkward. I suggest making the caller responsible for passing stdlib and compiler rather than passing a Tab.

@mistydemeo
mistydemeo Aug 12, 2013 Contributor

I was anticipating future places where we'd be instantiating these objects from formulae (e.g. #for_formula below) where the logic would be consolidated in one place, but since we're currently only doing it in one place I guess it's not really a big deal to move this logic into the formula installer.

@jacknagel
jacknagel Aug 12, 2013 Contributor

Alternatively, Tab could have an instance method that returns a Stdlib object.

@mistydemeo
mistydemeo Aug 16, 2013 Contributor

That's a good idea - removed the extra constructors on Stdlib and gave Tab a to_cxxstdlib method.

@jacknagel jacknagel and 1 other commented on an outdated diff Aug 12, 2013
Library/Homebrew/stdlib.rb
@@ -0,0 +1,47 @@
+class Stdlib
+ attr_accessor :type, :compiler
+
+ def self.for_tab(tab)
+ # legacy tabs won't include values for these
+ tab.stdlib ||= :libstdcxx
+ tab.compiler ||= :clang
+
+ new(tab.stdlib.to_sym, tab.compiler.to_sym)
+ end
+
+ def self.for_formula(f)
+ self.for_tab(Tab.for_formula(f))
+ end
@jacknagel
jacknagel Aug 12, 2013 Contributor

Is this used anywhere (besides tests)?

@mistydemeo
mistydemeo Aug 12, 2013 Contributor

I'd meant to do it when building Stdlib objects form formulae, but hadn't changed it over.

@mistydemeo
Contributor

Made a few changes, and also renamed the Stdlib class to CxxStdlib for accuracy's sake.

@mistydemeo
Contributor

git did quite a heroic job of rebasing this on top of the latest ENV changes.

@mistydemeo
Contributor

@manphiz Provided reusable constants in 37099f098668ec5f20e534d7302a94be9041da84, and used in later commits. Tucked them into the shared ENV extension because that seemed vaguely germane, but I'm happy to move elsewhere.

@mikemcquaid @adamv @jacknagel @samueljohn etc. - Going to push tomorrow or this weekend unless there are other comments.

@mistydemeo
Contributor

I realize in retrospect that I defined methods in stdenv for GNU GCC that are currently never used. I originally thought it would take more work to add GNU GCC support to stdenv but actually it probably wouldn't be that big a deal.

@mistydemeo
Contributor

Apparently it took next to no code so I did it anyway. As a bonus, this enables the HOMEBREW_CC environment variables in stdenv.

@manphiz
Contributor
manphiz commented Aug 23, 2013

Can't wait :)

@MikeMcQuaid
Member

Sounds good.

@samueljohn
Contributor

To the possible values of HOMEBREW_CC, I still think it is unfortunate that llvm means llvm-gcc here. Misty, I Know this is not your fault. If we introduce this variable now to stdenv (and perhaps update the manual, too?) would this be the chance to replace llvm and use the qualified name llvm-gcc?

@samueljohn samueljohn and 2 others commented on an outdated diff Aug 23, 2013
Library/Homebrew/extend/ENV/std.rb
@@ -354,6 +368,17 @@ def compiler
:llvm
elsif self['HOMEBREW_USE_GCC']
:gcc
+ elsif self['HOMEBREW_CC']
+ case self['HOMEBREW_CC']
+ when 'clang' then :clang
+ # depending on Xcode version plain 'gcc' could actually be
+ # gcc-4.0 or llvm-gcc
+ when 'gcc', 'gcc-4.2' then :gcc
+ when 'llvm', 'llvm-gcc' then :llvm
@samueljohn
samueljohn Aug 23, 2013 Contributor

Now I see that 'llvm-gcc' is actually accepted as a value for HOMEBREW_CC. I only read when 'llvm' at first.
So I'd vote to document llvm-gcc in the man page and not mention llvm. But leaving this in for compatibility.

@mistydemeo
mistydemeo Aug 23, 2013 Contributor

I kinda feel like the horse has left the barn on that one (we've been using llvm instead of llvm-gcc internally since forever, even though the latter's more accurate), but I don't mind documenting only the latter.

@samueljohn
Contributor
$ gcc-4.8 --version
gcc-4.8 (GCC) 4.8.1

$ brew pull 20251
[...]

$ export HOMEBREW_CC='gcc-4.8'
$ brew install python                                                                                                                               
Warning: Experimental support for non-Apple GCC enabled. Some builds may fail!
Error: undefined method `delete' for nil:NilClass
Please report this bug:
    https://github.com/mxcl/homebrew/wiki/troubleshooting
/homebrew/Library/Homebrew/extend/ENV/shared.rb:125:in `warn_about_non_apple_gcc'
/homebrew/Library/Homebrew/extend/ENV/super.rb:103:in `setup_build_environment'
/homebrew/Library/Homebrew/build.rb:123:in `install'
/homebrew/Library/Homebrew/build.rb:45:in `main'
/homebrew/Library/Homebrew/build.rb:12
/homebrew/Library/Formula/python.rb:250

What am I doing wrong?

@MikeMcQuaid
Member

As an aside: did we allow setting the compiler from the environment like this previously? It seems a bit dangerous...

@samueljohn
Contributor

@mikemcquaid we have HOMEBREW_USE_LLVM=1 and similar (but I don't like them and would love to deprecate them in favor of HOMEBREW_CC). Also setting HOMEBREW_CC should IMO always print a warning as Misty implemented for gcc here.
I very much prefer the args: --use-clang etc. (though there again we have that misleading --use-llvm but still args seems preferable)

@MikeMcQuaid
Member

Yeh, I'd rather the args were used too (and aren't sticky). I'm just forseeing blog posts when Mavericks is released telling people to set HOMEBREW_CC globally to GCC or LLVM.

@mistydemeo
Contributor

Theoretically this is the "new" way to do things since superenv landed last year, but yeah, I hadn't considered that. Honestly kind of surprised we haven't seen that yet - maybe just because they're poorly documented.

As an alternative, how about not supporting GNU GCC by setting HOMEBREW_CC, and instead using the (non-sticky) option: --use-gnu-gcc=foo I really don't want to overload --use-gcc, which is vague enough as is.

@mistydemeo
Contributor

(but I don't like them and would love to deprecate them in favor of HOMEBREW_CC)

They're already deprecated, and using them in superenv will print a warning.

BTW, @samueljohn - fixed the bug you encountered. Accidentally forgot to fix a variable reference when extracting the GNU GCC warning into the shared env extension.

@adamv
Contributor
adamv commented Aug 23, 2013

I think we want to move away from --use-[gcc/llvm/clang] altogether, just --cc=<something>.

@jacknagel
Contributor

FWIW, I've been setting HOMEBREW_CC=gcc-4.2 on Snow Leopard/Xcode 4.2 (I think we normally choose llvm-gcc, but I was seeing some compilation issues).

@samueljohn
Contributor

I think we want to move away from --use-[gcc/llvm/clang] altogether, just --cc=.

Yes --cc="gcc" sounds best, and I am fine with doing that in another PR. Can we already handle command line args with values?

@mistydemeo thanks. Fantastic work here. A lot of people will like this.

@mistydemeo
Contributor

@jacknagel I think our next step after this should be to simply remove llvm-gcc from the list of available compilers. There will be enough choices now it shouldn't be necessary, even on platforms where it's the default / an available fallback.

@mistydemeo
Contributor

@adamv How about: https://github.com/mistydemeo/homebrew/compare/cc Can push that first, then switch over the GNU GCC to use that and not support HOMEBREW_CC.

When we do that, I'd like to remove the HOMEBREW_USE_LLVM/etc. environment variables, then unify the compiler selection logic.

@mistydemeo
Contributor

Updated the branch a bit - added a second commit which unifies the compiler selection logic between superenv and stdenv, and removes the deprecared HOMEBREW_USE_LLVM/etc. variables.

The --cc= option accepts a restricted set of compilers based on their proper executable names, with no aliases: gcc-4.2 not gcc, llvm-gcc not llvm, etc. It's supported by both stdenv and superenv.

@mistydemeo
Contributor

If this looks good, I'll push the cc branch, then modify the GNU GCC branch to support --cc= as the only syntax for selecting a non-Apple compiler instead of HOMEBREW_CC=.

@mistydemeo
Contributor

Rebased on master with some cleanup to the --cc= code for GNU GCC selection. Seems to work well now!

@samueljohn
Contributor

Ok, don't hold this back because of me. Looks great.

@mistydemeo
Contributor

Just a heads up that I'm going to merge this this evening.

mistydemeo added some commits Jun 4, 2013
@mistydemeo mistydemeo Experimental support for non-Apple GCCs 2f26a66
@mistydemeo mistydemeo Implement fails_with for non-Apple compilers
This adds support for non-Apple GCC compilers in the fails_with code.
A fails_with block for a non-Apple compiler looks like:

fails_with :gcc => '4.8.1' do
  cause 'Foo'
end

Non-Apple compilers don't have build numbers, so compiler failures are
based on version strings instead.

Internally non-Apple compilers can be distinguished because they are
passed around as strings instead of symbols.

In addition, this alters the priority list for compilers, with the
following changes:

* Apple GCC 4.2 and LLVM-GCC swap positions, with GCC now taking
  priority. (Maybe LLVM-GCC should just go away.)
* Non-Apple GCC compilers are ranked below GCC 4.2 but above LLVM-GCC
  and Apple GCC 4.0.
5d1a959
@mistydemeo mistydemeo Move Tab creation into build process
The parent process doesn't have access to the selected compiler, which
will be important in the next commit.

Fortunately the child process already has a filtered and massaged
ARGV, so it has enough information to build the tab itself.
2773dfe
@mistydemeo mistydemeo Tab: track C++ stdlib in use
There are subtle incompatibilities between Apple's libstdc++ and the
libstdc++ used by the various GNU GCC formulae. In addition, we'll
likely also be supporting libc++ in the future, and that's also
incompatible with the other stdlibs.

Tracking it in the tab lets us make sure that dependencies are all
built against the same stdlib to avoid subtle breakage.
45d6df1
@mistydemeo mistydemeo Check dependencies for a compatible C++ stdlib
There are now a few possible C++ standard libraries a given build could
be using, with subtle incompatibilities and possibility of breakage
when mixed. This makes sure that the dependency chain was compiled in
a compatible manner.

Fortunately all of the Apple compilers use the same libstdc++, and we
don't yet support building with libc++, so this will primarily only
nag users trying to use GNU gcc who already have software installed
with Apple compilers.

Future TODOs:

* Add general support for building with libc++ (compatibility checking
  already handled here)
* Possibly track formulae which actually build C++ bindings, so that
  users aren't bothered by spurious nagging re: interpreted languages,
  pure-C software, etc.
f7d7af3
@mistydemeo mistydemeo Provide reusable GNU GCC constants in ENV 68396a8
@mistydemeo
Contributor

Merged!

@manphiz Can you take a look at the stub wiki page for C++ stdlibs and make any improvements it needs?

@mikemcquaid Can you take a look at the bottle check in 500d40d? Not sure how we want to handle C++ stdlibs in bottles going forward.

@mistydemeo mistydemeo closed this Sep 1, 2013
@mistydemeo mistydemeo deleted the mistydemeo:superenv_non_apple_compiler branch Sep 1, 2013
@seanjensengrey

Love the change, couple things:

I am seeing a compilation failure (segfault) in gnu-prolog unless I compile with --env=std

Fatal Error: Segmentation Violation (bad address: 0x10041aada)
compilation failed
make[1]: *** [fd2c.o] Error 1
make: *** [all] Error 1
  • Is there a way to just turn off this feature?
  • It would be nice if the banner "Warning: Experimental support .." told me the compiler version is picked up
  • I cannot --cc=gcc to switch back to my platform gcc, why is that? I can switch to other gcc versions
@mistydemeo
Contributor

I am seeing a compilation failure (segfault) in gnu-prolog unless I compile with --env=std

Can you file a separate issue for this, please?

It would be nice if the banner "Warning: Experimental support .." told me the compiler version is picked up

That's a good idea.

I cannot --cc=gcc to switch back to my platform gcc, why is that? I can switch to other gcc versions

--cc= requires a specific compiler version. You can specify --cc=gcc-4.2.

@ohhorob
ohhorob commented Jan 4, 2014

I had to use gcc-4.7 to compile protobuf240a on Mavericks.

First step was installing gcc-4.7 (see http://stackoverflow.com/a/19719840/178831)
And then protobuf240a with the cc option:

$ export HOMEBREW_CC=gcc-4.7; export CXX=g++-4.7; ~/homebrew/bin/brew install -v --cc=gcc-4.7 protobuf240a

This was to get the CDH4.5.0 hadoop distro maven target 'idea:idea' to build.. so I had to get the protobuf240a/bin/protoc in the path, and try the maven goal again.

$ mvn idea:idea
@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 16, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.