tbb: use stdenv to fix building. #22837

Closed
wants to merge 1 commit into
from

Projects

None yet

3 participants

@manphiz
Contributor
manphiz commented Sep 26, 2013
  • Under superenv tbb FTBFS with undeclared identifier.

Closes #22545.

@manphiz manphiz tbb: use stdenv to fix building.
* Under superenv tbb FTBFS with undeclared identifier.

Closes #22545.
307ec3b
Contributor
adamv commented Sep 26, 2013

We don't want to add more env :std to formulae, we want to figure out why superenv is broken and fix it.

Contributor
manphiz commented Sep 27, 2013

@adamv OK. Will try to figure out what part of superenv may cause this. Though I'll take a while longer.

Contributor
manphiz commented Sep 27, 2013

So after some digging, I kind of know the cause of the problem. It turns out tbb will generate version string during the process using the following command:

sh ../../build/version_info_macos.sh clang++ -g -O0 -DTBB_USE_DEBUG -DUSE_PTHREAD -m64 -fPIC -D__TBB_BUILD=1 -Wall -Wno-non-virtual-dtor -w -pipe -I../../src -I../../src/rml/include -I../../include >version_string.ver

Under stdenv it will generate

#define __TBB_VERSION_STRINGS(N) \
#N": BUILD_HOST     Xiyues-MBP (i386)" ENDL \
#N": BUILD_OS       Mac OS X version 10.8.5" ENDL \
#N": BUILD_KERNEL   Darwin Kernel Version 12.5.0: Mon Jul 29 16:33:49 PDT 2013; root:xnu-2050.48.11~1/RELEASE_X86_64" ENDL \
#N": BUILD_GCC      Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)" ENDL \
#N": BUILD_TARGET   intel64 on cc4.2.1_os10.8.5" ENDL \
#N": BUILD_COMMAND  clang++ -g -O0 -DTBB_USE_DEBUG -DUSE_PTHREAD -m64 -fPIC -D__TBB_BUILD=1 -Wall -Wno-non-virtual-dtor -w -pipe -I../../src -I../../src/rml/include -I../../include" ENDL \

#define __TBB_DATETIME "Fri Sep 27 10:32:54 UTC 2013"

And under superenv, the content becomes:

$ cat version_string.ver 
#define __TBB_VERSION_STRINGS(N) \
#N": BUILD_HOST     Xiyues-MBP (i386)" ENDL \
#N": BUILD_OS       Mac OS X version 10.8.5" ENDL \
#N": BUILD_KERNEL   Darwin Kernel Version 12.5.0: Mon Jul 29 16:33:49 PDT 2013; root:xnu-2050.48.11~1/RELEASE_X86_64" ENDL \
#N": BUILD_GCC      Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn) "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.8.0 -w -o a.out -L/usr/local/lib -L/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries -headerpad_max_install_names -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/lib/darwin/libclang_rt.osx.a" ENDL \
#N": BUILD_TARGET   intel64 on cc4.2.1_os10.8.5" ENDL \
#N": BUILD_COMMAND  clang++ -g -O0 -DTBB_USE_DEBUG -DUSE_PTHREAD -m64 -fPIC -D__TBB_BUILD=1 -Wall -Wno-non-virtual-dtor -I../../src -I../../src/rml/include -I../../include" ENDL \

#define __TBB_DATETIME "Fri Sep 27 10:30:45 UTC 2013"

Notice the BUILD_GCC line, the double quote around the ld command confuses the process. I checked the gcc -v under superenv and got:

$ gcc -v
Apple LLVM version 5.0 (clang-500.2.76) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.8.0 -o a.out -L/usr/local/lib -L/System/Library/Frameworks/OpenGL.framework/Versions/Current/Libraries -headerpad_max_install_names -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/5.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
  "_main", referenced from:
     implicit entry/start for main executable
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Looks like the gcc wrapper under superenv is borked. Not sure what could cause this though.

Contributor
manphiz commented Sep 27, 2013
Contributor

I'll look at this when I get home.

Contributor

It's also possible this is from the xcrun wrapper, which was spewing nonsense in the past as well.

Contributor

Appears to have been introduced in 585d7c6.

Contributor

OK, figured it out. This is actually normal behaviour for clang and gcc, and it not really our fault.

-v is the verbose flag for clang and gcc, not the version flag as tbb appears to think it is. (That's --version.) It does incidentally print the version information, and if the compiler just compiling and not running ld that's all it will do. Starting in 585d7c6, we began passing -Wl,-headerpad_max_install_names to all compiler invocations; as a result, gcc and clang are always invoking the linker. Since -v was passed, clang/gcc are displaying the verbose information for the linker, which includes the actual command being executed. And, since no compilation was being done, the linker issues an error about not being able to find main().

In other words, tbb is actually using the wrong option and should be fixed.

Contributor
manphiz commented Sep 28, 2013

Well, it can be controversial that whether passing all those options that
results in error messages is correct behavior. I'm not sure this is
something that a package manager is supposed to do. IMHO if
install_tool_name is needed, then this is upstream issue.

On Fri, Sep 27, 2013 at 6:35 PM, Misty De Meo notifications@github.comwrote:

OK, figured it out. This is actually normal behaviour for clang and gcc,
and it not really our fault.

-v is the verbose flag for clang and gcc, not the version flag as tbb
appears to think it is. (That's --version.) It does incidentally print
the version information, and if the compiler just compiling and not running
ld that's all it will do. Starting in 585d7c6585d7c6,
we began passing -Wl,-headerpad_max_install_names to all compiler
invocations; as a result, gcc and clang are always invoking the linker.
Since -v was passed, clang/gcc are displaying the verbose information for
the linker, which includes the actual command being executed. And, since no
compilation was being done, the linker issues an error about not being able
to find main().

In other words, tbb is actually using the wrong option and should be fixed.


Reply to this email directly or view it on GitHubhttps://github.com/mxcl/homebrew/pull/22837#issuecomment-25288139
.

Contributor

The error messages don't actually affect the compiler's behaviour. The real problem is that Intel is requesting verbose output from the compiler when that's not really what they want.

Contributor

Though I agree it's kinda weird we're invoking the linker in a ton more places than we used to, which is the source of the extra ld errors.

@mistydemeo mistydemeo added a commit that closed this pull request Sep 28, 2013
@mistydemeo mistydemeo tbb: patch for compiler verison parsing
Fixes #22837.
9618a34
Contributor

Fixed and submitted a patch upstream.

@handyman5 handyman5 pushed a commit to handyman5/homebrew that referenced this pull request Oct 7, 2013
@mistydemeo mistydemeo tbb: patch for compiler verison parsing
Fixes #22837.
2728af8
@xu-cheng xu-cheng locked and limited conversation to collaborators Feb 17, 2016
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.