root6: make it work on 10.6

[mojca (Mojca Miklavec)]

I'm isolating this issue from #43917.

The build log is here:

• ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/27095

-- The C compiler identification is Clang 3.4.0
-- The CXX compiler identification is Clang 3.4.0
-- Check for working C compiler: /opt/local/bin/clang-mp-3.4
-- Check for working C compiler: /opt/local/bin/clang-mp-3.4 -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /opt/local/bin/clang++-mp-3.4
-- Check for working CXX compiler: /opt/local/bin/clang++-mp-3.4 -- broken
CMake Error at /opt/local/share/cmake-2.8/Modules/CMakeTestCXXCompiler.cmake:54 (message):
  The C++ compiler "/opt/local/bin/clang++-mp-3.4" is not able to compile a
  simple test program.

  It fails with the following output:

   Change Dir: /opt/local/var/macports/build/_opt_mports_dports_science_root6/root6/work/build/CMakeFiles/CMakeTmp

  

  Run Build Command:/usr/bin/make "cmTryCompileExec828241131/fast"

  /usr/bin/make -f CMakeFiles/cmTryCompileExec828241131.dir/build.make
  CMakeFiles/cmTryCompileExec828241131.dir/build

  /opt/local/bin/cmake -E cmake_progress_report
  /opt/local/var/macports/build/_opt_mports_dports_science_root6/root6/work/build/CMakeFiles/CMakeTmp/CMakeFiles
  1

  Building CXX object
  CMakeFiles/cmTryCompileExec828241131.dir/testCXXCompiler.cxx.o

  /opt/local/bin/clang++-mp-3.4 -pipe -Os -arch x86_64 -stdlib=libc++
  -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -o
  CMakeFiles/cmTryCompileExec828241131.dir/testCXXCompiler.cxx.o -c
  /opt/local/var/macports/build/_opt_mports_dports_science_root6/root6/work/build/CMakeFiles/CMakeTmp/testCXXCompiler.cxx


  Linking CXX executable cmTryCompileExec828241131

  /opt/local/bin/cmake -E cmake_link_script
  CMakeFiles/cmTryCompileExec828241131.dir/link.txt --verbose=1

  /opt/local/bin/clang++-mp-3.4 -pipe -Os -arch x86_64 -stdlib=libc++
  -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6
  -Wl,-search_paths_first -Wl,-headerpad_max_install_names -L/opt/local/lib
  -Wl,-headerpad_max_install_names -arch x86_64
  CMakeFiles/cmTryCompileExec828241131.dir/testCXXCompiler.cxx.o -o
  cmTryCompileExec828241131

  ld: library not found for -lc++

  clang: error: linker command failed with exit code 1 (use -v to see
  invocation)

  make[1]: *** [cmTryCompileExec828241131] Error 1

  make: *** [cmTryCompileExec828241131/fast] Error 2

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  CMakeLists.txt:5 (project)


-- Configuring incomplete, errors occurred!

The problem seems to be

ld: library not found for -lc++

[jeremyhu (Jeremy Huddleston Sequoia)]

ld: library not found for -lc++

Is the libcxx port installed? It provides /usr/lib/libc++.dylib

[cjones051073 (Chris Jones)]

I asked the same in another ticket. According to Mojca, I believe yes, it should be installed.

[mojca (Mojca Miklavec)]

Yes, it is. You may check the log:

--->  Activating libcxx @183506_1
DEBUG: Using /usr/bin/tar
DEBUG: Using /usr/bin/bzip2
x ./
x ./+COMMENT
x ./+CONTENTS
x ./+DESC
x ./+PORTFILE
x ./+STATE
x ./opt/
x ./opt/local/
x ./opt/local/var/
x ./opt/local/var/host/
x ./opt/local/var/host/libcxx-183506-1/
x ./opt/local/var/host/libcxx-183506-1/usr/
x ./opt/local/var/host/libcxx-183506-1/usr/lib/
x ./opt/local/var/host/libcxx-183506-1/usr/lib/libc++.1.dylib
x ./opt/local/var/host/libcxx-183506-1/usr/lib/libc++.dylib
DEBUG: activating directory: /
DEBUG: activating directory: /opt
DEBUG: activating directory: /opt/local
DEBUG: activating directory: /opt/local/var
DEBUG: activating directory: /opt/local/var/host
DEBUG: activating directory: /opt/local/var/host/libcxx-183506-1
DEBUG: activating directory: /opt/local/var/host/libcxx-183506-1/usr
DEBUG: activating directory: /opt/local/var/host/libcxx-183506-1/usr/lib
DEBUG: activating file: /opt/local/var/host/libcxx-183506-1/usr/lib/libc++.1.dylib
DEBUG: activating file: /opt/local/var/host/libcxx-183506-1/usr/lib/libc++.dylib
DEBUG: Executing proc-post-org.macports.activate-activate-0
DEBUG: Executing portactivate::activate_finish
DEBUG: Executing org.macports.main (libcxx)
DEBUG: clean phase started at Wed Jun 18 00:08:26 PDT 2014
DEBUG: Executing org.macports.clean (libcxx)
--->  Cleaning libcxx

[cjones051073 (Chris Jones)]

The log above shows /opt/local/var/host/libcxx-183506-1/usr/lib/libc++.dylib being created, but does not mention /usr/lib/libc++.dylib, which I am guessing should be a sym link or something ?

[mojca (Mojca Miklavec)]

OK, I think I have found the culprit, but I probably need assistance to solve this.

This works:

$ clang++-mp-3.4 test.cpp -o test -stdlib=libc++

but the following doesn't:

$ clang++-mp-3.4 test.cpp -o test -stdlib=libc++ -isysroot /Developer/SDKs/MacOSX10.6.sdk
ld: library not found for -lc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)

The problem is that the cmake PortGroup adds

-DCMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.6.sdk" \
-DCMAKE_OSX_DEPLOYMENT_TARGET="10.6"

and so the build fails to find libc++.dylib in /usr/lib.

[mojca (Mojca Miklavec)]

The quick-and-dirty workaround that worked was to set

-DCMAKE_OSX_SYSROOT="/" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=""

inside cmake-1.0.tcl. (I could probably have done the same in the root6 Portfile.)

The variables really need to be "set to empty", else CMake adds SDK flags automatically.

Now ... the problem is that this starts building, but then fails again later on. I believe that ROOT tries to configure CLING as part of the process:

[  0%] Performing configure step for 'LLVM'
cd /path/to/rot6/work/build/LLVM/src/LLVM-build && /opt/local/bin/cmake -DLLVM_INCLUDE_TESTS=OFF /.../ /path/to/root6/work/root-aaf9b65rinterpreter/llvm/src
Re-run cmake no build system arguments
-- The CXX compiler indentification is Clang 3.4.0
-- Check for working CXX compiler: /opt/local/bin/clang++-mp-3.4
-- Check for working CXX compiler: /opt/local/bin/clang++-mp-3.4 -- broken

... same error ...

The quick-and-dirty workaround was to manually run that cmake command by adding -DCMAKE_OSX_SYSROOT="/" -DCMAKE_OSX_DEPLOYMENT_TARGET="" and then the build happily continued.

One has to repeat the exercise in build/CLING/src/CLING-build.

Now give it a few hours (or less in case it crashes earlier).

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

The log above shows /opt/local/var/host/libcxx-183506-1/usr/lib/libc++.dylib being created, but does not mention /usr/lib/libc++.dylib, which I am guessing should be a sym link or something ?

As already explained in the other thread, libcxx uses

    post-activate {
        system "ditto ${root_path} /"
    }

in the post-activate phase. And that isn't shown in the log. I believe it should be, but I don't know if that part of logging is easy to implement.

So yes, the libc++.dylib is present in /usr/lib. The problem is that it is missing in /Developer/SDKs/MacOSX10.6.sdk/usr/lib which CMake is apparently using by default.

[cjones051073 (Chris Jones)]

What happens if instead of removing the -isysroot option, you append '-L/usr/lib' to the command line ? I'm not so familiar with -isysroot, but with the -L option you can append as many as you want...

Chris

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

What happens if instead of removing the -isysroot option, you append '-L/usr/lib' to the command line?

It still breaks. Independent of whether I add it in front or at the end.

[mojca (Mojca Miklavec)]

So, here's where the fun begins (somewhere at the very end of the build):

cd /path/to/root6/work/build/montecarlo/vmc && ../../bin/rootcling -rootbuild -f G__VMC.cxx -s /path/to/root6/work/build/lib/libVMC.so -rml libVMC.so -rmf /path/to/root6/work/build/lib/libVMC.rootmap -c -I/path/to/root6/work/root-aaf9b65 -I/path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc -I/path/to/root6/work/root-aaf9b65/io/io/inc -I/path/to/root6/work/build/include -I/path/to/root6/work/root-aaf9b65/montecarlo/eg/inc -I/path/to/root6/work/root-aaf9b65/graf2d/gpad/inc -I/path/to/root6/work/root-aaf9b65/graf2d/graf/inc -I/path/to/root6/work/root-aaf9b65/core/base/inc -I/path/to/root6/work/root-aaf9b65/core/clib/inc -I/path/to/root6/work/root-aaf9b65/core/cont/inc -I/path/to/root6/work/root-aaf9b65/core/meta/inc -I/path/to/root6/work/root-aaf9b65/core/metautils/inc -I/path/to/root6/work/root-aaf9b65/core/textinput/inc -I/path/to/root6/work/root-aaf9b65/core/unix/inc -I/path/to/root6/work/root-aaf9b65/core/winnt/inc -I/path/to/root6/work/root-aaf9b65/core/macosx/inc -I/path/to/root6/work/root-aaf9b65/core/zip/inc -I/path/to/root6/work/root-aaf9b65/core/lzma/inc -I/path/to/root6/work/root-aaf9b65/math/matrix/inc -I/path/to/root6/work/root-aaf9b65/math/mathcore/inc -I/path/to/root6/work/root-aaf9b65/io/io/inc -I/path/to/root6/work/root-aaf9b65/core/thread/inc -I/path/to/root6/work/root-aaf9b65/graf2d/mathtext/inc -I/path/to/root6/work/root-aaf9b65/graf3d/g3d/inc -I/path/to/root6/work/root-aaf9b65/hist/hist/inc -I/path/to/root6/work/root-aaf9b65/math/physics/inc -I/path/to/root6/work/root-aaf9b65/geom/geom/inc TGeoMCGeometry.h TMCOptical.h TMCParticleType.h TMCProcess.h TMCtls.h TMCVerbose.h TPDGCode.h TVirtualMC.h TVirtualMCApplication.h TVirtualMCGeometry.h TVirtualMCStack.h /path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/LinkDef.h
In file included from input_line_11:1:
In file included from /path/to/root6/work/build/lib/libVMCff499ffe52_dictUmbrella.h:6:
In file included from /path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TGeoMCGeometry.h:23:
In file included from /path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TVirtualMCGeometry.h:22:
In file included from /path/to/root6/work/root-aaf9b65/core/base/inc/TNamed.h:29:
In file included from /path/to/root6/work/root-aaf9b65/core/base/inc/TString.h:36:
In file included from /path/to/root6/work/root-aaf9b65/core/base/inc/TMathBase.h:34:
/opt/local/libexec/llvm-3.4/bin/../include/c++/v1/cmath:318:8: warning: extra tokens at end of #endif directive [-Wextra-tokens]
#endif __APPLE__
       ^
       //
In file included from input_line_11:1:
In file included from /path/to/root6/work/build/lib/libVMCff499ffe52_dictUmbrella.h:13:
In file included from /path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TVirtualMC.h:28:
/path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TVirtualMCApplication.h:114:11: error: 
      thread-local storage is unsupported for the current target
   static TMCThreadLocal TVirtualMCApplication* fgInstance; // singleton instance
          ^
/path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TMCtls.h:53:30: note: 
      expanded from macro 'TMCThreadLocal'
      #define TMCThreadLocal __thread
                             ^
In file included from input_line_11:1:
In file included from /path/to/root6/work/build/lib/libVMCff499ffe52_dictUmbrella.h:13:
/path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TVirtualMC.h:867:11: error: 
      thread-local storage is unsupported for the current target
   static TMCThreadLocal TVirtualMC*  fgMC; // Monte Carlo singleton instance
          ^
/path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TMCtls.h:53:30: note: 
      expanded from macro 'TMCThreadLocal'
      #define TMCThreadLocal __thread
                             ^
In file included from input_line_11:1:
In file included from /path/to/root6/work/build/lib/libVMCff499ffe52_dictUmbrella.h:13:
/path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TVirtualMC.h:881:11: error: 
      thread-local storage is unsupported for the current target
R__EXTERN TMCThreadLocal TVirtualMC *gMC;
          ^
/path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/TMCtls.h:53:30: note: 
      expanded from macro 'TMCThreadLocal'
      #define TMCThreadLocal __thread
                             ^
Error: ../../bin/rootcling: compilation failure (/path/to/root6/work/build/lib/libVMCff499ffe52_dictUmbrella.h)
make[2]: *** [montecarlo/vmc/G__VMC.cxx] Error 1

[mojca (Mojca Miklavec)]

I fixed the first error by boldly editing /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/cmath and replacing:

- #endif __APPLE__
+ #endif // __APPLE__

(Jeremy, doesn't this look like a bug in clang-3.4?)

I don't know what the other error is. I tried to run the command manually, without success:

../../bin/rootcling -rootbuild -f G__VMC.cxx -s /path/to/root6/work/build/lib/libVMC.so -rml libVMC.so -rmf /path/to/root6/work/build/lib/libVMC.rootmap -c -I/path/to/root6/work/root-aaf9b65 -I/path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc -I/path/to/root6/work/root-aaf9b65/io/io/inc -I/path/to/root6/work/build/include -I/path/to/root6/work/root-aaf9b65/montecarlo/eg/inc -I/path/to/root6/work/root-aaf9b65/graf2d/gpad/inc -I/path/to/root6/work/root-aaf9b65/graf2d/graf/inc -I/path/to/root6/work/root-aaf9b65/core/base/inc -I/path/to/root6/work/root-aaf9b65/core/clib/inc -I/path/to/root6/work/root-aaf9b65/core/cont/inc -I/path/to/root6/work/root-aaf9b65/core/meta/inc -I/path/to/root6/work/root-aaf9b65/core/metautils/inc -I/path/to/root6/work/root-aaf9b65/core/textinput/inc -I/path/to/root6/work/root-aaf9b65/core/unix/inc -I/path/to/root6/work/root-aaf9b65/core/winnt/inc -I/path/to/root6/work/root-aaf9b65/core/macosx/inc -I/path/to/root6/work/root-aaf9b65/core/zip/inc -I/path/to/root6/work/root-aaf9b65/core/lzma/inc -I/path/to/root6/work/root-aaf9b65/math/matrix/inc -I/path/to/root6/work/root-aaf9b65/math/mathcore/inc -I/path/to/root6/work/root-aaf9b65/io/io/inc -I/path/to/root6/work/root-aaf9b65/core/thread/inc -I/path/to/root6/work/root-aaf9b65/graf2d/mathtext/inc -I/path/to/root6/work/root-aaf9b65/graf3d/g3d/inc -I/path/to/root6/work/root-aaf9b65/hist/hist/inc -I/path/to/root6/work/root-aaf9b65/math/physics/inc -I/path/to/root6/work/root-aaf9b65/geom/geom/inc TGeoMCGeometry.h TMCOptical.h TMCParticleType.h TMCProcess.h TMCtls.h TMCVerbose.h TPDGCode.h TVirtualMC.h TVirtualMCApplication.h TVirtualMCGeometry.h TVirtualMCStack.h /path/to/root6/work/root-aaf9b65/montecarlo/vmc/inc/LinkDef.h
ERROR in cling::CIFactory::createCI(): cannot extract standard library include paths!
Invoking:
    echo | LC_ALL=C clang++-mp-3.4 -pipe -Os -arch x86_64 -stdlib=libc++  -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -std=c++11 -stdlib=libc++ -DR__HAVE_CONFIG -fPIC -fvisibility-inlines-hidden -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -xc++ -E -v - 2>&1 >/dev/null | awk '/^#include </,/^End of search/{if (!/^#include </ && !/^End of search/){ print }}' | grep -E "(c|g)\+\+"
results in
with exit code 256
sh: clang++-mp-3.4: command not found
Warning in cling::CIFactory::createCI():
  Possible C++ standard library mismatch, compiled with _LIBCPP_VERSION v1101 but extraction of runtime standard library version failed.
Invoking:
    echo '#include <vector>' | clang++-mp-3.4 -pipe -Os -arch x86_64 -stdlib=libc++  -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -std=c++11 -stdlib=libc++ -DR__HAVE_CONFIG -fPIC -fvisibility-inlines-hidden -fno-common -Woverloaded-virtual -Wcast-qual -fno-strict-aliasing -pedantic -Wno-long-long -Wall -W -Wno-unused-parameter -Wwrite-strings  -xc++ -dM -E - | grep 'define _LIBCPP_VERSION' | awk '{print $3}'
results in
sh: clang++-mp-3.4: command not found
with exit code 0
input_line_2:2:10: fatal error: 'string' file not found
#include <string>
         ^
lookup.type.by.name.file:1:1: error: unknown type name 'Double32_t'
Double32_t
^
lookup.type.by.name.file:1:1: error: unknown type name 'Float16_t'
Float16_t
^
lookup.type.by.name.file:1:1: error: unknown type name 'Long64_t'
Long64_t
^
lookup.type.by.name.file:1:1: error: unknown type name 'ULong64_t'
ULong64_t
^
lookup.type.by.name.file:1:1: error: unknown type name 'string'
string
^
lookup.type.by.name.file:1:1: error: use of undeclared identifier 'std'
std::string
^
In file included from input_line_6:1:
In file included from /path/to/root6/work/root-aaf9b65/core/base/inc/Rtypes.h:30:
/path/to/root6/work/root-aaf9b65/core/base/inc/Rtypeinfo.h:32:10: fatal error: 
      'typeinfo' file not found
#include <typeinfo>
         ^
Error: Error loading the default header files.

EDIT: the reason for that was that I was trying to run it as admin without having MacPorts in path.

[mojca (Mojca Miklavec)]

Also, we are not the only ones running into that problem, see #38493.

[mojca (Mojca Miklavec)]

Another ROOT-specific ticket with exactly that problem:

• ​https://sft.its.cern.ch/jira/browse/ROOT-4173

[mojca (Mojca Miklavec)]

The solution mentioned in that ticket was ​this one:

core/thread/inc/ThreadLocalStorage.h

@@ -44 +44 @@
 #endif
 
 #if defined(R__MACOSX)
-#  if defined(__clang__)
+#  if defined(__clang__) && defined(MAC_OS_X_VERSION_10_7)
 #    define R__HAS___THREAD
 #  else
 #    define R__HAS_PTHREAD

Is it possible that MAC_OS_X_VERSION_10_7 is defined on 10.6? I believe that I need to rebuild everything in order to test. Simply running make after changing that file didn't really help.

[mojca (Mojca Miklavec)]

Or, a ​way more likely candidate montecarlo/vmc/inc/TMCtls.h:

#ifndef ROOT_TMCtls
#define ROOT_TMCtls

// Thread Local Storage typedefs
//
// According to Geant4 tls.hh and G4Threading.hh

// Always build with thread support but keep a possibility to introduce
// a build option
#define VMC_MULTITHREADED 1
 
#if ( defined (VMC_MULTITHREADED) ) 
  #if ( ( defined(__MACH__) && defined(__clang__) && defined(__x86_64__) ) || \
        ( defined(__MACH__) && defined(__GNUC__) && __GNUC__>=4 && __GNUC_MINOR__>=7 ) || \
        defined(__linux__) || defined(_AIX) ) && ( !defined(__CINT__) )
      //  Multi-threaded build: for POSIX systems 
      #include <pthread.h>
      #define TMCThreadLocal __thread
  #else
      //#  error "No Thread Local Storage (TLS) technology supported for this platform. Use sequential build !"
      #define TMCThreadLocal 
  #endif
#else
  #define TMCThreadLocal 
#endif

#endif //ROOT_TMCtls

[cjones051073 (Chris Jones)]

Maybe I am mis understanding the above, but is the issue just the build cannot be done in parallel ? If so, is another possible work around just to force a non-parallel build on OSX 10.6 ?

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

Maybe I am mis understanding the above, but is the issue just the build cannot be done in parallel?

No, it throws a compiler error (independent of the number of cores involved).

If so, is another possible work around just to force a non-parallel build on OSX 10.6 ?

I don't think so. I was running both "make" which uses a single process as well as manually executing single commands, one-by-one. I think that TMCtls.h really has a bug. One cannot draw conclusions that __thread is supported just because clang is being used.

But it might be related to #43989 for example.

So basically now we are at:

• a trivial bug in clang-3.4 header files (up to Jeremy to fix)
• a bug in montecarlo/vmc/inc/TMCtls.h (trivial to patch even if upstream ignores us)
• the issue with CMake automatically adding -isysroot flags (probably the most problematic one at the moment unless Pere can help us out)
  • alternatively libcxx could also install files into /Developer/SDKs/MacOSX10.6.sdk if that is acceptable
• -lX11 (or similar) flags missing in ASImage
• (other problems yet to surface)

Currently I'm stuck with X libraries not being found.

[mojca (Mojca Miklavec)]

Any clues?

Linking CXX shared library ../../lib/libASImage.so
cd /path/to/root6/work/build/graf2d/asimage && /opt/local/bin/cmake -E cmake_link_script CMakeFiles/ASImage.dir/link.txt --verbose=1
/opt/local/bin/clang++-mp-3.4  -pipe -Os -arch x86_64 -stdlib=libc++  -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Qunused-arguments -std=c++11 -stdlib=libc++ -DR__HAVE_CONFIG -O2 -arch x86_64 -dynamiclib -Wl,-headerpad_max_install_names -m64 -single_module -Wl,-dead_strip_dylibs  -L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 -compatibility_version 6.0.0 -current_version 6.0.0 -o ../../lib/libASImage.6.00.00.so -install_name /opt/local/libexec/root6/lib/root/libASImage.6.so CMakeFiles/ASImage.dir/G__ASImage.cxx.o CMakeFiles/ASImage.dir/src/TASImage.cxx.o CMakeFiles/ASImage.dir/src/TASPluginGS.cxx.o ../../lib/libCore.6.00.00.so ../../lib/libAfterImage.a ../../lib/libfreetype.a /opt/local/lib/libgif.dylib /opt/local/lib/libtiff.dylib /opt/local/lib/libpng.dylib /opt/local/lib/libz.dylib /opt/local/lib/libjpeg.dylib /opt/local/lib/libz.dylib ../../lib/libGraf.6.00.00.so /opt/local/lib/libjpeg.dylib ../../lib/libHist.6.00.00.so ../../lib/libMatrix.6.00.00.so ../../lib/libMathCore.6.00.00.so ../../lib/libRIO.6.00.00.so ../../lib/libThread.6.00.00.so ../../lib/libCore.6.00.00.so -Wl,-rpath,/opt/local/lib 
Undefined symbols for architecture x86_64:
  "_XAllocColor", referenced from:
      _query_screen_visual_id in libAfterImage.a(asvisual.o)
      _find_useable_visual in libAfterImage.a(asvisual.o)
      _setup_as_colormap in libAfterImage.a(asvisual.o)
  "_XCheckWindowEvent", referenced from:
      _cut_pixmap in libAfterImage.a(pixmap.o)
  "_XClearWindow", referenced from:
      _show_asimage in libAfterImage.a(asimagexml.o)
  "_XCopyArea", referenced from:
      _copyshade_drawable_area in libAfterImage.a(pixmap.o)
      _CopyAndShadeArea in libAfterImage.a(pixmap.o)
      _cut_pixmap in libAfterImage.a(pixmap.o)
  "_XCreateColormap", referenced from:
      _query_screen_visual_id in libAfterImage.a(asvisual.o)
      _find_useable_visual in libAfterImage.a(asvisual.o)
...

OK, adding -lX11 "somewhere" helped, but I'm not sure how to fix this properly:

• graf2d/asimage/CMakeFiles/ASImage.dir/link.txt
• graf2d/asimage/CMakeFiles/ASImageGui.dir/link.txt
• graf3d/gl/CMakeFiles/RGL.dir/link.txt

[cjones051073 (Chris Jones)]

I couple ideas...

• At a guess, an issue with a mis-match between X11/Native graphics between ROOT and some dependency.

• The root5 port has a patch to disable TIFF support in AfterImage when cocoa is enabled.... Maybe something the similar is needed...

Chris

[cjones051073 (Chris Jones)]

Replying to jonesc@…:

I couple ideas...

• At a guess, an issue with a mis-match between X11/Native graphics between ROOT and some dependency.

• The root5 port has a patch to disable TIFF support in AfterImage when cocoa is enabled.... Maybe something the similar is needed...

Chris

The port file makes X11 the default backend on 10.6. maybe try forcing the cocoa backend ?

[mojca (Mojca Miklavec)]

Replying to jonesc@…:

The port file makes X11 the default backend on 10.6. maybe try forcing the cocoa backend?

I manually fixed it at two places for now. This also counts as a bug in ROOT and should be fixed (they will probably find it easy to fix).

I already played with Cocoa. While I was able to fix compiler issues (I had to edit the sources at a bunch of places), but it didn't work properly at the end (because I simply commented out some functions that I didn't know how to fix). I suspect that the changes needed might be minimal for someone with some Cocoa background, but I'm not sure if the ROOT team is willing to spend any time on that. It was different if Cocoa support was written a few years earlier. The problem is that ROOT uses some functions that have first been introduced in 10.7. There are very very few of them (probably 4 functions at 10-20 locations), but enough to make unmodified software "useless".

[cjones051073 (Chris Jones)]

I guess the issue then is to ask upstream what the opinion is on supporting 10.6 or not.

[mojca (Mojca Miklavec)]

Citing myself for future reference:

The first (but trivial to solve) problem was that Xcode in 10.6 installs SDK to /Developer/SDKs/MacOSX10.6.sdk (it does that also in early versions for 10.7).

So the second line here (line 2597) fails to configure:

xcodepath=`/usr/bin/xcode-select -print-path`
osxsdk=$xcodepath/Platforms/MacOSX.platform/Developer/SDKs/MacOSX$macosxvers.sdk

I had to adjust the line to also check for

osxsdk=$xcodepath/SDKs/MacOSX$macosxvers.sdk

then the configure step succeeded. I would need to write a proper patch for that, but that's trivial.

But then there are four functions used that have only been introduced in 10.7:

• ​https://developer.apple.com/library/mac/documentation/Carbon/reference/CTFontRef/Reference/reference.html#//apple_ref/c/func/CTFontDrawGlyphs
• ​https://developer.apple.com/library/mac/documentation/cocoa/reference/applicationkit/classes/NSWindow_Class/Reference/Reference.html

1. convertRectToScreen (on < 10.7 convertBaseToScreen)
2. convertRectFromScreen (on < 10.7 convertScreenToBase)
3. backingScaleFactor (on < 10.7 userSpaceScaleFactor, but maybe combined with something else?)
4. CTFontDrawGlyphs (I don't know how to replace it, but I have found ​this thread)

Affected files:

• graf2d/cocoa/src/QuartzWindow.mm
• ROOTOpenGLView.mm
• TGCocoa.mm
• TGQuartz.mm
• graf2d/quartz/src/QuartzText.mm

I attempted to fix the first three, commented out the fourth and the build succeeded. It displays graphics, but then disappears (maybe a subject to my faulty fixes, maybe something else).

(This was probably for ROOT 5, but I don't think they made any radical changes since.)

[mojca (Mojca Miklavec)]

Cool, the build succeeded! Now I only need to figure out why I get

new TBrowser();
Error in <TUnixSystem::FindDynamicLibrary>: GX11[.so | .dll | .dylib | .sl | .dl | .a] does not exist in .:/opt/local/libexec/root6/lib/root::/usr/local/lib:/usr/X11R6/lib:/usr/lib:/lib:/lib/x86_64-linux-gnu:/usr/local/lib64:/usr/lib64:/lib64:

How lucky we are that they check for /lib/x86_64-linux-gnu ;)

Part of the problem might be that -Dcocoa=OFF apparently doesn't switch X11 on. In CMakeCache.txt I have x11:BOOL=OFF. I opened a ticket here:

• ​https://sft.its.cern.ch/jira/browse/ROOT-6393

[mojca (Mojca Miklavec)]

Chris, we definitely need to use -Dx11=ON. I would say that this should be fixed upstream, but it's trivial to add that flag to the port.

The problem is that CMake then finds a lot of libraries from /usr/. Are you willing to play with options like we did for all other variants to make sure that all libraries eventually come from ${prefix}? Maybe there is also some trick, a single -DCMAKE_SOMETHING that would give preference to all libraries from ${prefix} and we could explore that first. That is independent of 10.6 and I already spent waaaaaay too much time debugging 10.6.

• I hope that a few extra X11 flags could fix the issues with X11.
• The CMake issue can be fixed "globally" by passing the variables with a trivial patch as suggested by Pere, but we still need to pass empty flags to the port once (and remove the default ones – I'm not sure how to do the removal). Unless Jeremy thinks that the libs could also be installed inside the SDK (that would be even better from our perspective, but not sure if that's "allowed").
• The file montecarlo/vmc/inc/TMCtls.h can be trivially patched by removing #include <pthread.h> and by removing __thread in the next line.
• That apple from #endif __APPLE__ can be commented out in /opt/local/libexec/llvm-3.4/include/c++/v1/cmath by Jeremy.

And then we should be set. Unless ROOT will then keep crashing (which is not impossible).

[mojca (Mojca Miklavec)]

Preliminary patches in r121142 (partially addressing just the second point).

[mojca (Mojca Miklavec)]

In r121155:

# replace
#   -DCMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.6.sdk"
#   -DCMAKE_OSX_DEPLOYMENT_TARGET="10.6"
# with
#   -DCMAKE_OSX_SYSROOT="/"
#   -DCMAKE_OSX_DEPLOYMENT_TARGET=""
pre-configure {
    configure.args-strsed "s|CMAKE_OSX_SYSROOT=\[^\[:blank:\]\]*|CMAKE_OSX_SYSROOT=\"/\"|"
    configure.args-strsed "s|CMAKE_OSX_DEPLOYMENT_TARGET=\[^\[:blank:\]\]*|CMAKE_OSX_DEPLOYMENT_TARGET=\"\"|"
}

Another suggestion by Ionic:

foreach i [lsearch -regexp -all ${configure.args} {CMAKE_OSX_SYSROOT=.*}] {
    lreplace ${configure.args} ${i} ${i} [regsub {CMAKE_OSX_SYSROOT=.*} [lindex ${configure.args} ${i}] {CMAKE_OSX_SYSROOT="/"}]
}

[mojca (Mojca Miklavec)]

When including libs from /usr/X11R6 (which shouldn't happen anyway):

In file included from /usr/X11R6/include/X11/Xft/Xft.h:41:
/usr/X11R6/include/fontconfig/fontconfig.h:116:39: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
#define FC_CACHE_SUFFIX             ".cache-"FC_CACHE_VERSION
                                             ^
                                              
/usr/X11R6/include/fontconfig/fontconfig.h:117:45: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
#define FC_DIR_CACHE_FILE           "fonts.cache-"FC_CACHE_VERSION
                                                  ^
                                                   
/usr/X11R6/include/fontconfig/fontconfig.h:118:47: error: invalid suffix on literal; C++11 requires a space between literal and identifier [-Wreserved-user-defined-literal]
#define FC_USER_CACHE_FILE          ".fonts.cache-"FC_CACHE_VERSION
                                                   ^
                                                    
3 errors generated.

[mojca (Mojca Miklavec)]

Further (possibly ugly) patches r121156, r121157 (together with upgrade).

Now all we need is a patch to clang-3.4 (I expect a failure on the buildbot until then) + a great deal of luck.

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to mojca@…:

The problem is that the cmake PortGroup adds

-DCMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.6.sdk" \
-DCMAKE_OSX_DEPLOYMENT_TARGET="10.6"

That is a bug in the cmake PortGroup. It should use whatever base tells it is the SDK and deployment targets.

Replying to mojca@…:

I fixed the first error by boldly editing /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/cmath and replacing:

- #endif __APPLE__
+ #endif // __APPLE__

(Jeremy, doesn't this look like a bug in clang-3.4?)

Yes, but meh. Feel free to push a patch, but I wouldn't bother with a revbump for that.

Replying to mojca@…:

The solution mentioned in that ticket was ​this one:

core/thread/inc/ThreadLocalStorage.h

@@ -44 +44 @@
 #endif
 
 #if defined(R__MACOSX)
-#  if defined(__clang__)
+#  if defined(__clang__) && defined(MAC_OS_X_VERSION_10_7)
 #    define R__HAS___THREAD
 #  else
 #    define R__HAS_PTHREAD

Is it possible that MAC_OS_X_VERSION_10_7 is defined on 10.6? I believe that I need to rebuild everything in order to test. Simply running make after changing that file didn't really help.

Yes. Checking for the existence of the MAC_OS_X_VERSION_10_7 macro is certainly not the right thing to do. Shame on them. The compiler and deployment target determine if TLS is supported, not the existence of some macro.

[mojca (Mojca Miklavec)]

Replying to jeremyhu@…:

Replying to mojca@…:

The problem is that the cmake PortGroup adds

-DCMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.6.sdk" \
-DCMAKE_OSX_DEPLOYMENT_TARGET="10.6"

That is a bug in the cmake PortGroup. It should use whatever base tells it is the SDK and deployment targets.

The bigger problem is that specifying no value automatically assumes -DCMAKE_OSX_SYSROOT="/Developer/SDKs/MacOSX10.6.sdk". That's more like a problem in CMake.

We can certainly take a look in the portgroup, but CMake blindly adding -isysroot when nobody asked for it seems more annoying.

Replying to mojca@…:

I fixed the first error by boldly editing /opt/local/libexec/llvm-3.4/bin/../include/c++/v1/cmath and replacing:

- #endif __APPLE__
+ #endif // __APPLE__

(Jeremy, doesn't this look like a bug in clang-3.4?)

Yes, but meh. Feel free to push a patch, but I wouldn't bother with a revbump for that.

I'm sorry. I actually didn't realize that this was just a warning rather than an error.

Replying to mojca@…:

The solution mentioned in that ticket was ​this one:

core/thread/inc/ThreadLocalStorage.h

@@ -44 +44 @@
 #endif
 
 #if defined(R__MACOSX)
-#  if defined(__clang__)
+#  if defined(__clang__) && defined(MAC_OS_X_VERSION_10_7)
 #    define R__HAS___THREAD
 #  else
 #    define R__HAS_PTHREAD

Is it possible that MAC_OS_X_VERSION_10_7 is defined on 10.6? I believe that I need to rebuild everything in order to test. Simply running make after changing that file didn't really help.

Yes. Checking for the existence of the MAC_OS_X_VERSION_10_7 macro is certainly not the right thing to do. Shame on them. The compiler and deployment target determine if TLS is supported, not the existence of some macro.

However the code that fails is in comment:16. That one is even more wrong, but I don't know what the proper patch should be.

After applying a bunch of patches + manually patching a rule to add -lX11 the package seems to work (to the extent that ROOT can be said to work ... crashes are to be expected).

[mojca (Mojca Miklavec)]

I fixed the patches in r121169 without a revbump.

[cooljeanius (Eric Gallager)]

Cc Me!

[cjones051073 (Chris Jones)]

Hi,

As I now have a VM setup running OSX10.6 I am able to look into this.

The issue was actually support for building with X11, more than support for OSX10.6 per se. The issue is when using the X11 backend (default on 10.6) there is a conflict with OpenGL, due to dependent ports being installed with Cocoa as their default backend, instead of X11.

I have a patch (attached next to this report) that fixes (well, more a work around) this by disabling OpenGL support when X11 is used. This is just a workaround, as it reduces functionality, but as X11 is not default on OSX10.7 or newer, and fixes builds that previous did not work at all, it is reasonable. The issue is really not with ROOT pre se, but with having a consistent set of ports. If a user *really* wants root6 with X11 *and* OpenGL (I suspect a small minority), then they can by making sure all dependent ports are installed using an X11 backend instead of native Cocoa...

The real fix here would be to get OSX10.6 working with a cocoa backend, but that might require changes upstream are not willing to make, so I think the patch as is is a good alternative in the meantime.

Chris

[mojca (Mojca Miklavec)]

Oh, great, I'm not alone ;)

Are you willing to provide some feedback to the following ticket please?

• ​https://sft.its.cern.ch/jira/browse/ROOT-6393

(Please try to also remove all flags that are currently being set inside +x11, leaving just -Dcocoa=NO.)

Thank you.

[cjones051073 (Chris Jones)]

I will try and take a look, but might take some time. There is football on this evening that isn't going to watch itself ;)

[mojca (Mojca Miklavec)]

What about this for the first part of the patch?

Portfile

@@ -61 +61 @@
 
 patchfiles          patch-cmake-modules-SearchInstalledSoftware.cmake.diff
 
-# an ugly workaround for lack of __thread on 10.6
-platform darwin 10 {
-    patchfiles-append \
-                    patch-montecarlo-vmc-inc-TMCtls.h.diff
-}
-
 # Force a compatible compiler
 # (macports-clang-3.3 works; it's blacklisted only to give the preference to 3.4)
 compiler.blacklist-append *gcc* {clang < 500} macports-clang-2.9 macports-clang-3.0 macports-clang-3.1 macports-clang-3.2 macports-clang-3.3
@@ -128 +122 @@
 configure.post_args ${worksrcpath}
 
 platform darwin {
+
+    if {${os.major} < 10} {
+        pre-fetch {
+            ui_error "${name} requires Mac OS X 10.6 or later."
+            return -code error "incompatible Mac OS X version"
+        }
+    } elseif {${os.major} == 10} {
+        # an ugly workaround for lack of __thread on 10.6
+        patchfiles-append patch-montecarlo-vmc-inc-TMCtls.h.diff
+    }
+
     # Note that we are forcing this choice.  This means that anything linking
     # against root6 needs to also be using libc++.  This is possibly
     # problematic, but luckily there is just a limited set of such dependents.

[cjones051073 (Chris Jones)]

Replying to mojca@…:

What about this for the first part of the patch?

Portfile

@@ -61 +61 @@
 
 patchfiles          patch-cmake-modules-SearchInstalledSoftware.cmake.diff
 
-# an ugly workaround for lack of __thread on 10.6
-platform darwin 10 {
-    patchfiles-append \
-                    patch-montecarlo-vmc-inc-TMCtls.h.diff
-}
-
 # Force a compatible compiler
 # (macports-clang-3.3 works; it's blacklisted only to give the preference to 3.4)
 compiler.blacklist-append *gcc* {clang < 500} macports-clang-2.9 macports-clang-3.0 macports-clang-3.1 macports-clang-3.2 macports-clang-3.3
@@ -128 +122 @@
 configure.post_args ${worksrcpath}
 
 platform darwin {
+
+    if {${os.major} < 10} {
+        pre-fetch {
+            ui_error "${name} requires Mac OS X 10.6 or later."
+            return -code error "incompatible Mac OS X version"
+        }
+    } elseif {${os.major} == 10} {
+        # an ugly workaround for lack of __thread on 10.6
+        patchfiles-append patch-montecarlo-vmc-inc-TMCtls.h.diff
+    }
+
     # Note that we are forcing this choice.  This means that anything linking
     # against root6 needs to also be using libc++.  This is possibly
     # problematic, but luckily there is just a limited set of such dependents.

Seems reasonable enough, until one of us has a VM for <10.6 ;)

Chris

[mojca (Mojca Miklavec)]

I don't think that libc++ is supported on < 10.6.

One could in principle use gcc 4.8 though, but that means that other changes are needed. So maybe we could rewrite the error message ...

[cjones051073 (Chris Jones)]

Replying to mojca@…:

I don't think that libc++ is supported on < 10.6.

One could in principle use gcc 4.8 though, but that means that other changes are needed. So maybe we could rewrite the error message ...

Good point... I think the error message is fine. The user base for <10.6 is probably pretty minimal...

[mojca (Mojca Miklavec)]

I committed r121304 now. If you have any complaints about the wording, please let me know.

[cjones051073 (Chris Jones)]

I am not sure what happened, as I am sure I tested it, but the previous patch seems to have disabled OpenGL in places it should not have (i.e. with cocoa backend), looking at the build bot builds.

I have a new patch that fixes this, coming next....

Chris

[mojca (Mojca Miklavec)]

I thought it was a bit strange the way you did it – I would do it the way you did it in the last patch – but it worked for me as well. I didn't try to compile it, but the variant is being picked up:

> port info root6
root6 @6.00.01 (science)
Variants:             avahi, clang33, [+]clang34, clang35, [+]cocoa, debug,
                      fftw3, fitsio, gcc47, [+]gcc48, gcc49, [+]graphviz,
                      [+]gsl, ldap, mariadb, [+]minuit2, mysql, mysql51,
                      mysql55, odbc, [+]opengl, percona, pythia, python26,
                      python27, [+]roofit, [+]soversion, [+]ssl, [+]tmva, x11,
                      [+]xml, xrootd

Is there a way to investigate why exactly the option wasn't included on the buildbot?

[mojca (Mojca Miklavec)]

r121308

[cjones051073 (Chris Jones)]

Replying to mojca@…:

I thought it was a bit strange the way you did it – I would do it the way you did it in the last patch – but it worked for me as well. I didn't try to compile it, but the variant is being picked up:

> port info root6
root6 @6.00.01 (science)
Variants:             avahi, clang33, [+]clang34, clang35, [+]cocoa, debug,
                      fftw3, fitsio, gcc47, [+]gcc48, gcc49, [+]graphviz,
                      [+]gsl, ldap, mariadb, [+]minuit2, mysql, mysql51,
                      mysql55, odbc, [+]opengl, percona, pythia, python26,
                      python27, [+]roofit, [+]soversion, [+]ssl, [+]tmva, x11,
                      [+]xml, xrootd

Is there a way to investigate why exactly the option wasn't included on the buildbot?

I saw the same, which is why I thought my first patch was OK. I was though in th end able to reproduce what was happening on the buildbots by first completely uninstalling and cleaning root. So I suspect it was some residual knowledge of what I had installed that was confusing me. Anyway, the new patch seems better, so I'm not going to worry too deeply about it ....

[mojca (Mojca Miklavec)]

I'm closing the ticket since ROOT builds and works on 10.6.

Summary of other/upstream things that could be improved:

• ​https://sft.its.cern.ch/jira/browse/ROOT-6393 – no linking to X11 libraries
• ​https://sft.its.cern.ch/jira/browse/ROOT-6394 – Build failure due to missing __thread on Mac OS X 10.6
• ​https://sft.its.cern.ch/jira/browse/ROOT-6395 – Support for Cocoa on Mac OS X 10.6
• hoping that cmake/modules/SearchInstalledSoftware.cmake will be fixed upstream (I didn't open a ticket – yet)
• #44125 – cmake: default values of CMAKE_OSX_SYSROOT/DEPLOYMENT_TARGET
• automatic check for libc++/libstdc++ inconsistencies

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to mojca@…:

I don't think that libc++ is supported on < 10.6.

One could in principle use gcc 4.8 though, but that means that other changes are needed. So maybe we could rewrite the error message ...

If you use macports-gcc-4.8, that means that every C++ library root6 links against and ever C++ library/executatble that links against it will need to use macports-gcc-4.x as well. Please don't do that.

[mojca (Mojca Miklavec)]

Doesn't libc++ have exactly the same problem?

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Doesn't libc++ have exactly the same problem?

To some degree yes, although its not as bad as using libstdc++ from gcc.

For instance on <OSX10.9 the variants pythia and xrootd do not work, they fail to build, as those ports use the default c++ runtime, which on the older systems is the system libstdc++. You must understand forcing the use of libc++ was only ever a last resort solution, and only works because we are lucky enough that the core default port doesn't happen use any libraries that use another c++ runtime, otherwise it would not work... If a user really wants to be safe, and/or gets these variants to work, they need to rebuild their entire MacPorts stack using libc++ as the default runtime, with all the untested issues that would likely throw up ...

Chris

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

Replying to mojca@…:

Doesn't libc++ have exactly the same problem?

No, it doesn't

To some degree yes, although its not as bad as using libstdc++ from gcc.

No, it doesn't. MacPorts uses only /usr/lib/libc++.dylib as the libc++ runtime. MacPorts will use both /usr/lib/libstdc++.dylib or ${prefix}/lib/libstdc++.dylib as the libstdc++.dylib depending on your compiler choice (system compilers use the former, macports-gcc compilers the latter).

For instance on <OSX10.9 the variants pythia and xrootd do not work, they fail to build, as those ports use the default c++ runtime, which on the older systems is the system libstdc++. You must understand forcing the use of libc++ was only ever a last resort solution, and only works because we are lucky enough that the core default port doesn't happen use any libraries that use another c++ runtime, otherwise it would not work... If a user really wants to be safe, and/or gets these variants to work, they need to rebuild their entire MacPorts stack using libc++ as the default runtime, with all the untested issues that would likely throw up ...

All of my systems (Snow Leopard and later) have libc++ as the C++ runtime. I haven't run into any issues since the initial fix-fest about a year and a half ago. I doubt we'll continue supporting libstdc++ for much longer (I know I certainly won't spend much effort fixing things for libstdc++)

[mojca (Mojca Miklavec)]

Replying to jeremyhu@…:

All of my systems (Snow Leopard and later) have libc++ as the C++ runtime. I haven't run into any issues since the initial fix-fest about a year and a half ago. I doubt we'll continue supporting libstdc++ for much longer.

I was amazed yesterday. After setting libc++ on Lion basically everything I tested worked or was at least trivial to fix. I even got cmake to work, even though I had to manually run a bunch of commands (I hope that the upstream will fix the problem soon).

Given the increasing number of C++11 software (and the increasing pain that comes with the need to switch to gcc), would it be feasible to create a semi-official "use-at-your-own-risk" version of MacPorts using libc++ by default and set up a buildbot? Some people say that we don't have the manpower to keep two versions around and that just switching to libc++ for everyone can hardly be done.

[cjones051073 (Chris Jones)]

Replying to mojca@…:

Replying to jeremyhu@…:

All of my systems (Snow Leopard and later) have libc++ as the C++ runtime. I haven't run into any issues since the initial fix-fest about a year and a half ago. I doubt we'll continue supporting libstdc++ for much longer.

I was amazed yesterday. After setting libc++ on Lion basically everything I tested worked or was at least trivial to fix. I even got cmake to work, even though I had to manually run a bunch of commands (I hope that the upstream will fix the problem soon).

Given the increasing number of C++11 software (and the increasing pain that comes with the need to switch to gcc), would it be feasible to create a semi-official "use-at-your-own-risk" version of MacPorts using libc++ by default and set up a buildbot? Some people say that we don't have the manpower to keep two versions around and that just switching to libc++ for everyone can hardly be done.

I am not so convinced having parallel MacPorts versions, using different C++ runtimes, is really worth it. It would just confuse users who otherwise don't care about such things, as to which they should use etc.

Making the switch to build against libc++ by default is easy. The hard bit would be how to handle the transistion for users, as they would have to have a gull rebuild of their complete MacPorts stack. It would need to be done automatically I think. I do agree with you though it might be something to consider...

Chris

[mojca (Mojca Miklavec)]

Users shouldn't care what they use, until:

• their favourite package stops working (as is the case with C++11 utilities such as mkvtoolnix, FileZilla, potentially Root with more dependencies, ...)
• using libc++ means that users who manually compile different software and want to link against something in MacPorts would run into problem if they forget to set libc++: automatic switch would probably break things for a number of users (but such things also break when a library gets updated etc.)

The reason why I often don't like to go out of defaults is because I'm really not eager to have to recompile every Qt or gcc or clang upgrade. It's ok for a few packages and I'm willing to sacrifice some time for experimenting and fixing things, but using a non-default macports package is "a pain" compared to the default one since the introduction of buildbots.

[cjones051073 (Chris Jones)]

I just very much doubt there would be much enthusiasm from those that would be involved, to setup new build bots (and to do it properly it would be 3 new ones, for OSX 106, 10.7 and 10.8) just for this.

Yes, there are pros and cons. The pros for switching to libc++ are reduced problems as more and more projects rely on c++11 features. The downside is yes, users building privately against the MP libraries would have to be careful to make sure they also use the non-default libc++ runtime. To me, its really a matter of opinion as to which of those wins out. Personally, I am kinda in the middle on it. I think the current situation is a reasonable compromise. Users that want to can use libc++ by default, but they have to choose to do this themselves, and then have to build everything from source. A pain yes, but at least it works....

[cjones051073 (Chris Jones)]

p.s. Can you just remind me how to make the switch to libc++ by default on <OSX10.9 systems ? I know its mentioned somewhere, but I cannot find it right now ...

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to jonesc@…:

p.s. Can you just remind me how to make the switch to libc++ by default on <OSX10.9 systems ? I know its mentioned somewhere, but I cannot find it right now ...

Do the following:

delete_la_files    yes
cxx_stdlib         libc++
buildfromsource    always

cxx_stdlib is "the meat," but you need to force building from source because the buildbot packages are not valid if you change this config. delete_la_files is not needed, but since you're rebuilding everything anyways, you might as well do that as well.

[cjones051073 (Chris Jones)]

Thanks !

I have updated one of my pre-OSX10.9 VMs to force the use of libc++. I've already found one port that was not properly respecting the runtime settings, pythia.

​https://trac.macports.org/ticket/44145

cheers Chris

[cooljeanius (Eric Gallager)]

Replying to jeremyhu@…:

Replying to mojca@…:

The solution mentioned in that ticket was ​this one:

core/thread/inc/ThreadLocalStorage.h

@@ -44 +44 @@
 #endif
 
 #if defined(R__MACOSX)
-#  if defined(__clang__)
+#  if defined(__clang__) && defined(MAC_OS_X_VERSION_10_7)
 #    define R__HAS___THREAD
 #  else
 #    define R__HAS_PTHREAD

Is it possible that MAC_OS_X_VERSION_10_7 is defined on 10.6? I believe that I need to rebuild everything in order to test. Simply running make after changing that file didn't really help.

Yes. Checking for the existence of the MAC_OS_X_VERSION_10_7 macro is certainly not the right thing to do. Shame on them. The compiler and deployment target determine if TLS is supported, not the existence of some macro.

So now I am getting kind of confused as to how exactly TLS support works... You say compiler and deployment target both matter, but how exactly do they interact? Is one of the two more important? The other tickets I found (#36172, #38493) all seemed to be unsure as to whether it was the compiler or deployment target that was more important, as well... This is getting kind of off-topic, but I was actually working on porting another package that uses TLS (libbabeltrace, for use with the recent update to gdb), and I found that versions of clang that were supposed to have TLS support (clang-3.3 here) failed to compile code containing __thread, so I am assuming that the deployment target must have been what made it fail there, but on the other hand, gcc apparently does not actually have TLS support on darwin yet (​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 is still open), and yet I was still able to compile code containing __thread with the gcc48 port (it passed the autoconf conftest from xorg-tls.m4, too), so I am assuming that gcc48 must have just ignored the deployment target or something?

[jeremyhu (Jeremy Huddleston Sequoia)]

Replying to egall@…:

Yes. Checking for the existence of the MAC_OS_X_VERSION_10_7 macro is certainly not the right thing to do. Shame on them. The compiler and deployment target determine if TLS is supported, not the existence of some macro.

So now I am getting kind of confused as to how exactly TLS support works... You say compiler and deployment target both matter, but how exactly do they interact?

Yes. The compiler needs to know about the thread keyword and what the author of the code means by that keyword. In order for the compiler to emit code, the runtime being targeted needs to have some mechanism to implement thread local storage.

Is one of the two more important?

No. If the compiler doesn't understand thread, it doesn't matter if the runtime supports it or not. Similarly, if the runtime doesn't have TLS support, there's no way that the compiler can translate thread into something meaningful.

The other tickets I found (#36172, #38493) all seemed to be unsure as to whether it was the compiler or deployment target that was more important, as well...

Well, both matter.

This is getting kind of off-topic, but I was actually working on porting another package that uses TLS (libbabeltrace, for use with the recent update to gdb), and I found that versions of clang that were supposed to have TLS support (clang-3.3 here) failed to compile code containing __thread, so I am assuming that the deployment target must have been what made it fail there, but on the other hand, gcc apparently does not actually have TLS support on darwin yet (​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 is still open), and yet I was still able to compile code containing __thread with the gcc48 port (it passed the autoconf conftest from xorg-tls.m4, too), so I am assuming that gcc48 must have just ignored the deployment target or something?

What do you mean "passed the autoconf test from xorg-tls.m4? I wrote that macro in order to "deal with" different notations for TLS markup. It doesn't actually cause an abort if it can't find anything. It just leaves TLS undefined. Your code may not be using it properly. You may have a single global instead! Perhaps that's a flaw in the macro, but it's up to the implementer to check the macro like:

#ifdef TLS
  int TLS myInt;
#else
  // Visit pthread_key_* hell
#endif

As for gcc... maybe they just never closed the bug... ?

~ $ cat test_thread.c 
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

#define NUM_THREADS 5

int __thread value;

void * test_thread(void *arg) {
    printf("%p\n", &value);
    sleep(1);
    return NULL;
}

int main(void) {
    int i;
    pthread_t thread[NUM_THREADS];

    for(i=0; i < 5; i++) {
        pthread_create(&thread[i], NULL, test_thread, NULL);
    }

    for(i=0; i < 5; i++) {
        pthread_join(thread[i], NULL);
    }

    return 0;
}

$ gcc-mp-4.6 test_thread.c 

$ ./a.out
0x7fafd84000e8
0x7fafd8403b18
0x7fafd8403c38
0x7fafd8403d58
0x7fafd8403e78

[cooljeanius (Eric Gallager)]

Replying to jeremyhu@…:

Replying to egall@…:

Yes. Checking for the existence of the MAC_OS_X_VERSION_10_7 macro is certainly not the right thing to do. Shame on them. The compiler and deployment target determine if TLS is supported, not the existence of some macro.

So now I am getting kind of confused as to how exactly TLS support works... You say compiler and deployment target both matter, but how exactly do they interact?

Yes. The compiler needs to know about the __thread keyword and what the author of the code means by that keyword. In order for the compiler to emit code, the runtime being targeted needs to have some mechanism to implement thread local storage.

Is one of the two more important?

No. If the compiler doesn't understand __thread, it doesn't matter if the runtime supports it or not. Similarly, if the runtime doesn't have TLS support, there's no way that the compiler can translate __thread into something meaningful.

The other tickets I found (#36172, #38493) all seemed to be unsure as to whether it was the compiler or deployment target that was more important, as well...

Well, both matter.

This is getting kind of off-topic, but I was actually working on porting another package that uses TLS (libbabeltrace, for use with the recent update to gdb), and I found that versions of clang that were supposed to have TLS support (clang-3.3 here) failed to compile code containing __thread, so I am assuming that the deployment target must have been what made it fail there, but on the other hand, gcc apparently does not actually have TLS support on darwin yet (​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52268 is still open), and yet I was still able to compile code containing __thread with the gcc48 port (it passed the autoconf conftest from xorg-tls.m4, too), so I am assuming that gcc48 must have just ignored the deployment target or something?

What do you mean "passed the autoconf test from xorg-tls.m4"?

It returned "__thread" properly. Also I see you commented on the upstream gcc ticket as well, and it turns out that it was the emutls vs. native TLS thing that was confusing me. However, this raises some additional questions. If gcc is able to use emutls as a way of supporting TLS on systems where it is unsupported natively (i.e. 10.6 and earlier), is there a way to get clang to do similarly? So far I have not found one yet... Also, I came up with the following blacklist for projects that only need to blacklist based on TLS support:

if {${os.platform} eq "darwin"} {
    # uses thread-local storage, which gcc only supports via emutls
    # on darwin as of gcc45 and later:
    compiler.blacklist-append gcc-3.3 {*gcc-4.[0-4]}
    if {${os.major} >= 11} {
        # old versions of clang (from before Xcode 4.2.1) need to be
        # blacklisted for not supporting thread-local storage as well:
        compiler.blacklist-append {clang < 318.0.61}
        # blacklist the equivalent clangs from MacPorts, too:
        compiler.blacklist-append macports-clang-2.9 macports-clang-3.0
    } else {
        # clang does not support TLS at all on pre-Lion systems, not even
        # via emutls like gcc does, so blacklist all clangs:
        compiler.blacklist-append *clang*
        # Make sure a recent version of gcc supporting emutls is in the
        # fallback list:
        compiler.fallback-append macports-gcc-4.8
    }
} else {
    # not sure what to blacklist on other platforms...
}

Would that be an accurate blacklist, more-or-less?

(but anyways, this is getting kind of off-topic from root6... sorry for the derail...)

[jeremyhu (Jeremy Huddleston Sequoia)]

Would that be an accurate blacklist, more-or-less?

Yes, as long as the project's don't use C++. If the projects use C++, then that's not quite good for SL and earlier systems because the resulting port won't be using a system C++ runtime. It'll be using the C++ runtime from the libgcc port which will make it incompatible with all other ports (which don't).