Linking libCint.so on OS X

ROOT
1

I am linking libCint.so on OS X.
Env vars DYLD_LIBRARY_PATH and CINTSYSDIR are defined.
I can build and run Cint interactively without issue.

I wish to call the API directly.
Runtime linking does succeed (the dynamic linker calls abort() if it cannot find the image at runtime).
However I get the following dlopen() error when I try and execute a script.

If I don’t execute a script but simply call G__init_cint(“cint”); no error is raised.
Why does dlopen() fail in this case? The path to lib/libCint.so has already been resolved (or we wouldn’t have gotten so far as to be able to call G__init_cint() ).

I am invoking the API as follows. My scripts contain a main() and I wish to emulate the command line behaviour of bin/cint (ie: I want to pass in a script path and command line arguments) but I want control to return to the caller if there is an error.

	NSString *command = [NSString stringWithFormat:@"cint -E -E %@", scriptPath];
	G__init_cint((char *)[command UTF8String]);
	G__scratch_all();

Regards

Jonathan Mitchell

2

[quote]Env vars DYLD_LIBRARY_PATH and CINTSYSDIR are defined.[/quote]You may want to also set LD_LIBRARY_PATH.

[quote]If I don’t execute a script but simply call G__init_cint(“cint”); no error is raised.[/quote]This is odd. How did you link you executable?

Philippe.

3

Thanks for the reply Philippe

[quote]Env vars DYLD_LIBRARY_PATH and CINTSYSDIR are defined. You may want to also set LD_LIBRARY_PATH.[/quote].

The OS X dynamic linker docs state that DYLD_LIBRARY_PATH and LD_LIBRARY_PATH will both be searched. However if recall correctly DYLD_LIBRARY_PATH was required in order to build bin/cint.

libCint.so was linked dynamically at runtime (it was a dependent library of the executable). The issue here. I think is that stdfunc.dll is loaded on demand using dlopen(). The call to G__init_cint(“quint”) succeeds because that function doesn’t attempt to load stdfunc.dll.

I have not yet been able to resolve why stdfunc.dll could not be loaded. The path looks okay plus otool confirmed the architecture. So still unresolved.

4

[quote]libCint.so was linked dynamically at runtime (it was a dependent library of the executable).[/quote]Can you be more explicit? Can you include the link lines involved?

Thanks,
Philippe.

5

Using a dependent library is the normal method of achieving shared library linkage on OS X.
see: http://developer.apple.com/mac/library/documentation/DeveloperTools/Conceptual/DynamicLibraries/100-Articles/DynamicLibraryUsageGuidelines.html

The linkage invocation is:

/Developer/usr/bin/gcc-4.2 -arch x86_64 -L/Users/Shared/Debug -L/Users/Jonathan/Documents/Computing/KosmicTask/KosmicTask/trunk-hostdev/../../cint/cint/lib -F/Users/Shared/Debug -filelist /Users/Shared/KosmicTask.build/Debug/KosmicTaskCINTRunner.build/Objects-normal/x86_64/KosmicTaskCINTRunner.LinkFileList -Xlinker -rpath -Xlinker @loader_path/../../../../Frameworks -mmacosx-version-min=10.5 -sectcreate __TEXT __info_plist KosmicTaskRunner-Info.plist -lCint -framework Foundation -framework Cocoa -framework Carbon -framework MGSKosmicTaskRunner -o /Users/Shared/Debug/KosmicTaskCINTRunner

On OS X, at least, the linked libraries install name becomes embedded in the executable binary. This is fine for system dylibs that reside in fixed locations but for libraries bundled with applications you have to use install_name_tool to patch the binary

# patch the executable so that it knows where to look for the framework
cd "$BUILD_DIR/$BUILD_STYLE/$FULL_PRODUCT_NAME/Contents/MacOS"
install_name_tool -change lib/libCint.so "@executable_path/../Frameworks/Cint.framework/$dylibVersion" KosmicTaskCINTRunner

In the above case libCint.so is included with the app with a relative path of @executable_path/…/Frameworks/Cint.framework.

The linkage to libCint.so is okay, I think. Its the subsequent loading of dlls that is problematic.

For now I am using bin/cint out of process. The API still looks appealing and I may return to have another try at it.

Thanks,
Jonathan.

6

[quote]The linkage to libCint.so is okay, I think. Its the subsequent loading of dlls that is problematic. [/quote]I suspect that the way the cintdlls are linked is not compatible per se with the way you have to rename the library. In particular I note in the error message you mentioned first, that it complains about “lib/libCint.so” and the part I think is significant is the ‘lib/’ part. I am guessing that the cintdlls need to have a library named ‘lib/libCint.so’ in there ‘search’ path and that we the renaming all we have left is either libCint.so or someotherpath/libCint.so …

Cheers,
Philippe.