Hello,
I have noticed that ROOTCINT requires the .so extension on dynamic/shared libraries on the MacOS to load them, which is annoying since automake creates *.dylib files. Everything works fine if I make a symlink from the .dylib file to a .so file. This is not a perfect solution. Is there any thought on changing ROOT so that it also accepts .dylib libraries? If not, any tips on how to make a .so instead of a .dylib on MacOS using automake?
Dylib’s can only be used to link against, but cannot be used by the dynamic loader (dlopen). In the past .dylib’s and .so’s were different objects. Since 10.4 MacOS X they are compatible and you can create a symlink from a .so to a .dylib so you can link against them and since 10.5 the linker directly accepts .so’s. So since 10.5 the .dylib extension is not needed anymore and MacOS X behaves like all other *nix systems and uses .so’s for linking and dynamic loading. So update your autotools.
Cheers, Fons.
Hi,
as far as I understand, the ratio of .so to .dylibs is growing constantly on MacOS. I’d suggest to talk to the autotools guys 
Cheers, Axel.
Thanks for the replies! Even though they weren’t all that helpful, they spurred an intense search for more information with Google. Since a symlink from the .dylib file to a .so file works I added hooks in the Makefile.am to create/delete this symlink. It is not the prettiest solution but it works. But,(!) since this works I see no reason why ROOT shouldn’t be able to load a module ending in .dylib. So I looked into the ROOT source code, in particular TSystem::Load(…) and TUnixSystem::DynamicPathName(…). In the latter I could add some code to make ROOT recognize the .dylib extension. With this change ROOT no longer complains about not finding the module (dynamic library) but gives the error
"Error: Bad source file(binary) …"
Is this a ROOT error or an error from the shared object loader? I know this is a bit on a tangent from a ROOT question, but I am sincerely interested in how these things work.
You think we didn’t try? It is dlopen() that does not accept the .dylib extension and that is the “Bad source file (binary)” error you get. It is on the OS level, not ROOT. So please forget about .dylibs and only use .so’s and you don’t need the symlinks anymore (when >= 10.5). And in the process get rid of autotools.
Cheers, Fons.
[quote=“rdm”]You think we didn’t try? It is dlopen() that does not accept the .dylib extension and that is the “Bad source file (binary)” error you get. It is on the OS level, not ROOT. So please forget about .dylibs and only use .so’s and you don’t need the symlinks anymore (when >= 10.5). And in the process get rid of autotools.
Cheers, Fons.[/quote]
Dear Fons,
While running into the same problem (loading a .dylib), I found this post. I was quite surpised to read your comment, as I regularly use dylib files with dlopen without complaints from the OS. So the issue would have been something with ROOT/CINT, or perhaps because I have an updated version of Mac OS X.
Darwin new-host.home 10.7.0 Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386 i386
The error, “Error: Bad source file(binary)”, comes from static int G__isbinaryfile(char *filename) in CINT (./cint/cint/src/loadfile.cxx) and is strictly related to the interpreter. I’ve modified the ROOT/CINT source and got dylibs to load (and operate) into ROOT/CINT. I don’t claim that everything is fixed for all possible aspects of this, so I propose this to the development team for review.
I only had to modify ./core/unix/src/TUnixSystem.cxx and ./cint/cint/src/loadfile.cxx to accept .dylib and .DYLIB (probably not needed but I mainly copied the .dll case and adjusted it). I’ve attached these two files (from root_v5.28.00c). They work fine for me. Let me know if you find issues. I didn’t try to make it compile from scratch (I just re-ran make after making the modifications) but I would be surprised there are issues (strictly in terms of compiling) since my changes only affect string operations relating to not checking whether .dylib files are binary (which they are).
Best,
Karolos
TUnixSystem.cxx (153 KB)
loadfile.cxx (96.9 KB)
Hi,
indeed this has changed and dlopen() does not accept .dylib as extension. I’ll make the changes. For more see also here:
stackoverflow.com/questions/2339 … lib-on-osx
Cheers, Fons.
Hi Fons,
Thanks for the link. I understand the issues better now.
It just stoke me as odd that one could just rename/link the .dylib to an .so and have it load. I think dlopen() actually doesn’t check the name of the file; it just reads in the first bytes (magic number) to determine if it can load the library.
Cheers,
Karolos
Actually in the past, I am almost 100% sure, dlopen() checked the extension and did not accept .dylib. That is when we introduced symbolic links from .dylib to .so as a simple work around. Clearly this check has been silently removed (actually I submitted a bug report, in the 10.4 times, it was marked as a duplicate and then I did not hear anything about it anymore).
Cheers, Fons.
Hi,
My first encounter with OS X is with 10.5, and yet there were many things not done in the *nix way (checking extensions is one of them). I’m glad things move along, thanks to bug reports like the one you filed.
Cheers,
Karolos
Hi,
I’ve made the changes in the trunk (r39196) to support .dylibs on OSX.
Cheers, Fons.