Hi Christian,
Apparently OSX does not yet have an ldd equivalent. Trying to find it
on the web I found a message noting this was one of the development
shortcoming of the system.
In terms of the brat test programs:
base -- WORKS
chkvparams -- FAILS with No Parameters found for C1
coord -- WORKS
detectorvolume - WORKS
eventmanager -- SEGFAULTS
geometry -- WORKS
geometrymanager -- FAILS with ROOT system not initialized
magnetvolume -- WORKS
rotategeofile -- WORKS
setgeometryfiles -- WORKS
units -- FAILS with No Parameters found for C1
Although I doubt if this accounts for the bratroot problem,
I 'm hoping you might point me in the right direction for what is needed
in
the auto* regime to get shared modules created. Quoting from the
OSX porting notes on the fink.sourceforge.net site:
2.1 Shared Libraries vs. Loadable Modules
One Mach-O feature that hits many people by surprise is the strict
distinction between shared libraries and dynamically loadable modules.
On ELF systems both are the same; any piece of shared code can be used
as a library and for dynamic loading.
Mach-O shared libraries have the file type MH_DYLIB and carry the
extension .dylib. They can be linked against with the usual static
linker flags, e.g. -lfoo for libfoo.dylib. However, they can not be
loaded as a module. (Side note: Shared libraries can be loaded
dynamically through an API. However, that API is different from the API
for bundles and the semantics make it useless for an dlopen() emulation.
Most notably, shared libraries can not be unloaded.)
Loadable modules are called "bundles" in Mach-O speak. They have the
file type MH_BUNDLE. Since no component involved cares about it, they
can carry any extension. The extension .bundle is recommended by Apple,
but most ported software uses .so for the sake of compatibility. Bundles
can be dynamically loaded and unloaded via dyld APIs, and there is a
wrapper that emulates dlopen() on top of that API. It is not possible to
link against bundles as if they were shared libraries. However, it is
possible that a bundle is linked against real shared libraries; those
will be loaded automatically when the bundle is loaded.
Runing aclocal, automake, autoconf with the current brat setup does
generate the .dylib files correctly. However, the
loadable modules are not created. This, for instance, prevents using
the gSystem->Load("library.so") in root.
To make loadable module I need to do something like:
c++ -g -bundle -flat_namespace -undefined_suppress -o libmultReplay.so
multTreeModule.o multCalibModule.o Analysiscint.o
I have built and accessed in ROOT my private library successfully using
this format. However, I've not been able to
locate he magic directive that will result in configure producing the
loadable modules. Any suggestions?
The fink discussion on this has:
2.4 Building a Shared Library
To build a shared library, you invoke the compiler driver with the
-dynamiclib option. This is best demonstrated by a comprehensive
example. We'll build a library called libfoo, composed of the source
files source.c and code.c. The version number is 2.4.5, where 2 is the
major revision (incompatible API change), 4 is the minor revision
(backwards-compatible API change) and 5 is the bugfix revision count
(some people call this the "teeny" revision, it denotes fully compatible
changes). The library depends on no other shared libraries and will be
installed in /usr/local/lib.
cc -fno-common -c source.c
cc -fno-common -c code.c
cc -dynamiclib -install_name /usr/local/lib/libfoo.2.dylib \
-compatibility_version 2.4 -current_version 2.4.5 \
-o libfoo.2.4.5.dylib source.o code.o
rm -f libfoo.2.dylib libfoo.dylib
ln -s libfoo.2.4.5.dylib libfoo.2.dylib
ln -s libfoo.2.4.5.dylib libfoo.dylib
Note which parts of the version are used where. Also note that the
static linker will use the libfoo.dylib symlink, while the dynamic
linker will use the libfoo.2.dylib symlink. It is possible to point
these symlinks at different minor revisions of the library.
2.5 Building a Module
To build a loadable module, you invoke the compiler driver with the
-bundle option. If the module uses symbols from the host program, you'll
have to specify -undefined suppress to allow undefined symbols, and
-flat_namespace along with it to make the new linker in Mac OS X 10.1
happy. A comprehensive example:
cc -fno-common -c source.c
cc -fno-common -c code.c
cc -bundle -flat_namespace -undefined suppress \
-o mymodule.so source.o code.o
Note that no version numbering is used. It is possible to use it in
theory, but in practice it's pointless. Also note that there are no
naming restrictions for bundles. Some packages prefer to prepend a "lib"
anyway because some other systems require it; this is harmless.
Thanks for any additional thoughts you might have on any of this!
Regrads,
Steve
This archive was generated by hypermail 2b30 : Wed Aug 28 2002 - 15:42:51 EDT