Compilation - OSX

[bkatiemills]

Hey @pcbend & @carlu & @damiller - I'm trying to write a quickstart for compiling on OSX and running into problems. After pointing all the appropriate variables in the SOURCEME file, compilation fails in the TigInput library with:

g++ -c -fPIC  TigInput.cxx -I../../include `root-config --cflags`
rootcint TigInputDict.cxx -c ../../include/TigInput.h
g++ -c -fPIC  TigInputDict.cxx -I../../include `root-config --cflags`
ar rcs libTigInput.a TigInput.o TigInputDict.o words.o
cp libTigInput.a ..
g++ --shared  -Wl,-soname=libTigInput.so -olibTigInput.so TigInput.o TigInputDict.o words.o
ld: unknown option: -soname=libTigInput.so
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libTigInput.so] Error 1 

Any thoughts?

[carlu]

Is it this:

http://stackoverflow.com/questions/4580789/cmake-mac-os-x-ld-unknown-option-soname

It looks like the command line options are different for specifying a library to be linked. If so we will have to test for OSX in the makefile.

Carl

On 20 January 2014 11:23, Bill Mills notifications@github.com wrote:

Hey @pcbend https://github.com/pcbend & @carluhttps://github.com/carlu& @damiller https://github.com/damiller - I'm trying to write a quickstart for compiling on OSX and running into problems. After pointing all the appropriate variables in the SOURCEME file, compilation fails in the TigInput library with:

g++ -c -fPIC TigInput.cxx -I../../include root-config --cflags rootcint TigInputDict.cxx -c ../../include/TigInput.h g++ -c -fPIC TigInputDict.cxx -I../../include root-config --cflags ar rcs libTigInput.a TigInput.o TigInputDict.o words.o cp libTigInput.a .. g++ --shared -Wl,-soname=libTigInput.so -olibTigInput.so TigInput.o TigInputDict.o words.o ld: unknown option: -soname=libTigInput.so clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *\ [libTigInput.so] Error 1

Any thoughts?

— Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/GRSISpoon/issues/10 .

[bkatiemills]

RIght you are Carl! But sadly, that just peels the onion back another layer. Doing make either at root or at ./libraries/TigInput yields the following trainwreck:

g++ -c -fPIC -std=c++0x -O2  TigInput.cxx -I/Users/billmills/Desktop/GRSISpoonDev/GRSISpoon/include `root-config --cflags`
rootcint TigInputDict.cxx -c /Users/billmills/Desktop/GRSISpoonDev/GRSISpoon/include/TigInput.h
g++ -c -fPIC -std=c++0x -O2  TigInputDict.cxx -I/Users/billmills/Desktop/GRSISpoonDev/GRSISpoon/include `root-config --cflags`
ar rcs libTigInput.a TigInput.o TigInputDict.o words.o
cp libTigInput.a ..
g++ --shared -std=c++0x -O2  -Wl,-install_name,libTigInput.so, -olibTigInput.so TigInput.o TigInputDict.o words.o
ld: warning: ignoring file words.o, file was built for unsupported file format ( 0x7F 0x45 0x4C 0x46 0x02 0x01 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 ) which is not the architecture being linked (x86_64): words.o
Undefined symbols for architecture x86_64:

So words.o is 32 bit? I remember @pcbend mentioning something about this file yesterday, but I don't recall what...

[pcbend]

pull request in that should fix this.

[bkatiemills]

Looks good - next up:

g++ -c -fPIC  TigInput.cxx -I../../include `root-config --cflags`
rootcint TigInputDict.cxx -c ../../include/TigInput.h
g++ -c -fPIC  TigInputDict.cxx -I../../include `root-config --cflags`
ar rcs libTigInput.a TigInput.o TigInputDict.o 
cp libTigInput.a ..
g++ --shared  -Wl,-install_name, libTigInput.so, -olibTigInput.so TigInput.o TigInputDict.o words.o
clang: error: no such file or directory: 'libTigInput.so,'
make: *** [libTigInput.so] Error 1

This may have to do with an undefined CFLAGS - we defined one when we were hacking yesterday but it never made it into a commit.

[pcbend]

-install_name, libTigInput.so,

remove the space in the make file:

-install_name,libTigInput.so,

On Tue, Jan 21, 2014 at 1:41 PM, Bill Mills notifications@github.comwrote:

Looks good - next up:

g++ -c -fPIC TigInput.cxx -I../../include root-config --cflags rootcint TigInputDict.cxx -c ../../include/TigInput.h g++ -c -fPIC TigInputDict.cxx -I../../include root-config --cflags ar rcs libTigInput.a TigInput.o TigInputDict.o cp libTigInput.a .. g++ --shared -Wl,-install_name, libTigInput.so, -olibTigInput.so TigInput.o TigInputDict.o words.o clang: error: no such file or directory: 'libTigInput.so,' make: *\ [libTigInput.so] Error 1

This may have to do with an undefined CFLAGS - we defined one when we were hacking yesterday but it never made it into a commit.

— Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/GRSISpoon/issues/10#issuecomment-32966744 .

[bkatiemills]

Right - now the words.o problem is back, but now wrt libTigInput.so. I hate to poop the party, but if this words.o just generates a random word, maybe it's time to drop it in favour of 'Nuclear data'.

[damiller]

Okay... Here is exactly what I've done previously in Makefiles to make things work with OS X:

# handle Mac OS X appropriately
LFLAGS            += -fPIC
ifeq ($(UNAME),Darwin)
LFLAGS          += -dynamiclib -single_module -undefined dynamic_lookup
SHAREDSWITCH    = -install_name # ENDING SPACE
else
SHAREDSWITCH    = -shared -Wl,-soname,#NO ENDING SPACE
endif
COMPILESHARED   = $(CPP) $(LFLAGS) $(SHAREDSWITCH)#NO ENDING SPACE

lib%.so: %.o
    $(COMPILESHARED)$@ -o $(LIB_DIR)/$@ $^ $(BASELIBS) -lc

We can choose our BASELIBS accordingly, and libc might not be needed for our case.

[bkatiemills]

The PR I just merged solves a bunch of problems here, but we're currently stuck against the following:

Undefined symbols for architecture x86_64:
  "TObject::SavePrimitive(std::__1::basic_ostream<char, std::__1::char_traits<char> >&, char const*)", referenced from:
      vtable for TigScope in TigScope.o
ld: symbol(s) not found for architecture x86_64

This problem seems to have cropped up for other ROOT users who were able to solve it in an old version of xcode, but the prescribed solution doesn't work here; investigation ongoing.

[damiller]

Okay... I think I have reached the end of this rabbit hole, albeit with no simple solution. Unfortunately, it seems the OS X developers chose to implement the C++11 standard in a fresh new library libc++. Their legacy library, libstdc++, does not provide any of the new standard support. However, it seems that the Reflex which serves as ROOT's runtime type identification, is strongly dependent on the definitions as they exist in libstdc++.

I suppose there are several ugly ways to proceed. 1) Backport a version that works without the recent extensions in the standard library which certainly have performance implications. 2) Hope that ROOT 6 does something intelligent, and punt the problem. Or finally, 3) Figure out what causes Reflex to choke and die and hack functions for possibly all used ROOT classes to interface between C++11 and the last standard.

[pcbend]

After doing some reading too, root has an option in the configure script called enable-cxx11 that can be set before building. We should try to excplicitly set this and rebuild root on bills laptop before we do anything to crazy. The random root vodoo has worked in the past. On Jan 21, 2014 10:34 PM, "David Miller" notifications@github.com wrote:

Okay... I think I have reached the end of this rabbit hole, albeit with no simple solution. Unfortunately, it seems the OS X developers chose to implement the C++11 standard in a fresh new library libc++. Their legacy library, libstdc++, does not provide any of the new standard support. However, it seems that the Reflex which serves as ROOT's runtime type identification, is strongly dependent on the definitions as they exist in libstdc++.

I suppose there are several ugly ways to proceed. 1) Backport a version that works without the recent extensions in the standard library which certainly have performance implications. 2) Hope that ROOT 6 does something intelligent, and punt the problem. Or finally, 3) Figure out what causes Reflex to choke and die and hack functions for possibly all used ROOT classes to interface between C++11 and the last standard.

— Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/GRSISpoon/issues/10#issuecomment-32996942 .

[bkatiemills]

@damiller Cool, thanks for looking into this so thoroughly! Of your options, (1) is the only one I see as being realistic if it comes to that; nobody wants ROOT 6 and I'm not going to try to force it on this project, and hacking every single ROOT class is not something I'm going to put resources on - keep in mind, getting this to go on OSX is mostly for the convenience of developers; production runs aren't going to be happening in that environment. But by the same token, I don't care if I lose a little speed in my dev environment if it all comes back in my production environment - this will be the way to proceed if Peter's suggestion doesn't work.

@pcbend setting a flag sounds like my kind of solution, if we can make it go - I'll see if I can figure this out today.

[bkatiemills]

hmmm nope - setting --enable-cxx11 (or --enable-libcxx) both produce the same errors, a bunch of complaints along the lines of

cint/cint/lib/dll_stl/G__cpp_vector.cxx:566:14: error: calling a private constructor of class 'std::__1::__wrap_iter<char *>'
 p = new vector<char,allocator<char> >::iterator(libp->para[0].ref ? *(const vector<char,allocator<char> >::iterator::pointer*) libp->para[0].ref : *(const vector<char,allocator<char> >::itera...

[pcbend]

Did you remake root with this option set in the configure script? On Jan 22, 2014 11:53 AM, "Bill Mills" notifications@github.com wrote:

hmmm nope - setting --enable-cxx11 (or --enable-libcxx) both produce the same errors, a bunch of complaints along the lines of

cint/cint/lib/dll_stl/G__cpp_vector.cxx:566:14: error: calling a private constructor of class 'std::1::wrapiter<char *>' p = new vector<char,allocator >::iterator(libp->para[0].ref ? (const vector<char,allocator >::iterator::pointer_) libp->para[0].ref : *(const vector<char,allocator >::itera...

— Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/GRSISpoon/issues/10#issuecomment-33060543 .

[bkatiemills]

I rebuilt ROOT via

./configure --all --enable-cxx11
make -j2

make fails with the above error.

[pcbend]

Well, I guess that solution was to easy to work. On Jan 22, 2014 11:56 AM, "Bill Mills" notifications@github.com wrote:

I rebuilt ROOT via

./configure --all --enable-cxx11 make -j2

make fails with the above error.

— Reply to this email directly or view it on GitHubhttps://github.com/GRIFFINCollaboration/GRSISpoon/issues/10#issuecomment-33060839 .

[bkatiemills]

Alright, as it stands it looks like our options are to either hope for magic from the ROOT ticket @damiller is going to open (link here once open plz), or see if ROOT 6 plays nicer with OSX and doesn't blow everything up on SL6. I will try to make heads or tails of ROOT 6 on the mac side shortly.

[damiller]

Here is the post I made regarding our compilation woes:

http://root.cern.ch/phpBB3/viewtopic.php?f=3&t=17545