Need to upgrade macos_version_min linker param in llvm configure command shown in README.md instructions

Steps causing the bug to occur

  1. Follow instructions in vuo-0.5.1 README.md up to “LLVM and Clang 3.2”
  2. cd /tmp
  3. curl -OL http://llvm.org/releases/3.2/llvm-3.2.src.tar.gz
  4. curl -OL http://llvm.org/releases/3.2/clang-3.2.src.tar.gz
  5. tar zxf llvm-3.2.src.tar.gz
  6. cd llvm-3.2.src/tools
  7. tar zxf …/…/clang-3.2.src.tar.gz
  8. mv clang-3.2.src clang
  9. cd …
  10. CC=gcc CXX=g++ CFLAGS=“-march=x86-64” CXXFLAGS=“-march=x86-64” LDFLAGS=“-Wl,|checking for mmap of files… yes
    -macosx_version_min,10.6” ./configure --prefix=/usr/local/Cellar/llvm/3.2 --enab|checking if /dev/zero is needed for mmap… no
    le-optimized --disable-bindings --enable-targets=host

checking for C compiler default output file name… configure: error: C compiler cannot create executables
See `config.log’ for more details.

-----------

Core tests.

-----------

configure:2088: checking for C compiler version
configure:2095: gcc --version >&5
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
configure:2098: $? = 0
configure:2105: gcc -v >&5
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix
configure:2108: $? = 0
configure:2115: gcc -V >&5
clang: error: argument to ‘-V’ is missing (expected 1 value)
clang: error: no input files
configure:2118: $? = 1
configure:2141: checking for C compiler default output file name
configure:2168: gcc -march=x86-64 -Wl,-macosx_version_min,10.6 conftest.c >&5
Undefined symbols for architecture x86_64:
“start”, 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)
configure:2171: $? = 1
configure: failed program was:
| /* confdefs.h. /
| #define PACKAGE_NAME “LLVM”
| #define PACKAGE_TARNAME “llvm”
| #define PACKAGE_VERSION “3.2svn”
| #define PACKAGE_STRING “LLVM 3.2svn”
| #define PACKAGE_BUGREPORT “http://llvm.org/bugs/
| #define LLVM_VERSION_MAJOR 3
| #define LLVM_VERSION_MINOR 2
| /
end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2210: error: C compiler cannot create executables
See `config.log’ for more details.

Tried simpler case:

cat > foo.c

#include <stdio.h>
int main()
{
printf(“Moi maailma!\n”);
}
^D

gcc -march=x86-64 -v -Wl,-macosx_version_min,10.6 foo.c

Apple LLVM version 5.0 (clang-500.2.79) (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/clang” -cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disabl
e-free -disable-llvm-verifier -main-file-name foo.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu x86-64 -target-l
inker-version 224.1 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/…/lib/clang/5.0 -fdebug-compilation-dir
/Users/a2deh/Vuo/Source/llvm-3.2.src -ferror-limit 19 -fmessage-length 225 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-
method=mixed -fobjc-default-synthesize-properties -fencode-extended-block-signature -fdiagnostics-show-option -o /var/folders/_5/stlctlyj07qcpzjy22qfpdxm0000gn/T/fo
o-RBoLPF.o -x c foo.c
clang -cc1 version 5.0 based upon LLVM 3.3svn default target x86_64-apple-darwin12.5.0
#include “…” search starts here:
#include <…> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/…/lib/clang/5.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
“/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 -ma
cosx_version_min 10.6 /var/folders/_5/stlctlyj07qcpzjy22qfpdxm0000gn/T/foo-RBoLPF.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xcto
olchain/usr/bin/…/lib/clang/5.0/lib/darwin/libclang_rt.osx.a
Undefined symbols for architecture x86_64:
“start”, 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)

Solution:

gcc -march=x86-64 -v -Wl,-macosx_version_min,10.6 foo.c

Apple LLVM version 5.0 (clang-500.2.79) (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/clang” -cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disabl
e-free -disable-llvm-verifier -main-file-name foo.c -mrelocation-model pic -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu x86-64 -target-l
inker-version 224.1 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/…/lib/clang/5.0 -fdebug-compilation-dir
/Users/a2deh/Vuo/Source/llvm-3.2.src -ferror-limit 19 -fmessage-length 225 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-
method=mixed -fobjc-default-synthesize-properties -fencode-extended-block-signature -fdiagnostics-show-option -o /var/folders/_5/stlctlyj07qcpzjy22qfpdxm0000gn/T/fo
o-7AdnAv.o -x c foo.c
clang -cc1 version 5.0 based upon LLVM 3.3svn default target x86_64-apple-darwin12.5.0
#include “…” search starts here:
#include <…> search starts here:
/usr/local/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/…/lib/clang/5.0/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
“/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 -ma
cosx_version_min 10.8 /var/folders/_5/stlctlyj07qcpzjy22qfpdxm0000gn/T/foo-7AdnAv.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xcto
olchain/usr/bin/…/lib/clang/5.0/lib/darwin/libclang_rt.osx.a

./a.out
Moi maailma!

IT WORKED!!!

How did the result differ from what you expected?

It didn’t work, as shown above.

When did you first notice this bug?

When trying to compile sources.

Have you found a workaround?

Yes, a fix, shown above.

Use:
LDFLAGS=“-Wl,-macosx_version_min,10.8”
instead of:
LDFLAGS=“-Wl,-macosx_version_min,10.6”

Change line 53 of README.md to:

CC=gcc CXX=g++ CFLAGS="-march=x86-64" CXXFLAGS="-march=x86-64" LDFLAGS="-Wl,-macosx_version_min,10.8" ./configure --prefix=/usr/local/Cellar/llvm/3.2 --enable-optimized --disable-bindings --enable-targets=host

Other notes

  • Vuo version: 0.5.1
  • macOS version: OS X 10.8

Yay! Now I’ll go through the rest of the instructions and see if I can compile my own extension!

Oops, I pasted the wrong command into my test case solution. The command that worked was:

gcc -march=x86-64 -v -Wl,-macosx_version_min,10.8 foo.c

@SimHacker: Thanks for the report; we’ll look into it.

By the way:

see if I can compile my own extension

You don’t need to build Vuo from source in order to compile extensions (e.g., new nodes and types). Just download the SDK and use the vuo-compile binary in there. See Vuo: Developing a Node Class for more info.

I found the actual cause of the problem: I am running OS/X 10.8.5, but I had the 10.9 SDK installed, and it was insisting on using that, even if I passed --sdk osx10.8 (or whatever the syntax was) to ./configure. I was also getting warnings from the compiler in one of the .h files that it was not compatible with that os release. I had to rename the 10.9 sdk directory so the compiler could not find it, and then rebuild everything from a clean start to avoid cached make configuration files, and I was able to get it all to compile with only a few tweaks!

qtmacextras gave me a link error because resolvePlatformFunction was defined as an inline in a .h file but not getting compiled into the library, so I un-inlinified it and got it to work.

json-c was giving an error on some comparison of an unsigned to < 0 that was always false (the return value of open??! but that is SUPPOSED to be a signed int, so I don’t understand why it was complaining) – so I removed the -Werror flag from the makefile and it compiled.

freeimage was barfing about memset not being defined in some template. So I added #include <string.h> to ImfHuf.h and got it to compile.

assimp–3.0.1270-source-only was more problematic: some of the patches did not work, because of ^M’s at the end of the lines. I was able to edit them out and get most of them to patch but I had to apply the code/STEPFile.h patch by hand for some reason.

But now I have it all compiled!

Well that’s great I can compile extensions without going through all that, but at least I hope this feedback may help you shake out problems you might have in the future. Are you compiling it on osx 10.8 or 10.9?

I’m interested in looking at the sources to the editing tool and helping to develop it, especially the user interface and the JavaScript integration. Are there any conditions under which it’s available?

The extension I’m interested in working on would be integrating WebView and its JS interpreter, making a polymorphic JSON data type as I described before, and modules to access and manipulate JSON, like an input editor with a JSON outline editor, and using the web browser to do user interface stuff.

I see you’ve got JavaScript integration via Mono set for “some time later” in the roadmap, but I think that integrating WebView is a lower hanging fruit with lots of benefits thanks to the web browser that it’s coupled with, which would be extremely useful in and of itself. And with a polymorphic JSON data type, which could represent JSON in various formats like text, c-json, pointers to native JS vm data, and convert it lazily on demand, you could plug components written in different languages together with the native c-json components as well as the future Mono JavaScript interpreter, and also Objective C components that liked to take NSDictionarys and NSArrays, or even Python components, since JSON is such a great universal data type!

@SimHacker: Thanks for the detailed analysis. We’re currently building Vuo on 10.6 and 10.8, and testing it on 10.6, 10.8, and 10.9.

Vuo currently uses Qt 5.1.1, which doesn’t build on 10.9 (hence the warnings when building on 10.8 using the 10.9 SDK).

Qt 5.2 was released a few weeks ago, which solves that problem. We plan to upgrade Vuo to Qt 5.2 soon, and, along with it, upgrade the whole build process for 10.9.

(I’ll reply to your emails regarding WebView and JavaScript integration. Sorry for my long delay in responding — been unbelievably busy.)  

SimHacker,

We upgraded to Qt 5.2 in release 0.6.0. Please let us know if you still experience problems.

Hi, @simhacker. We’ve upgraded to Qt 5.3.1, which builds cleanly on Mac OS 10.9. So this issue is finally fixed — our latest release, Vuo 0.8.0, builds cleanly on Mac OS 10.9.4. Let us know if you have further issues building it.