Hi Steve, On Wed, 28 Aug 2002 14:35:35 -0500 Stephen Sanders <ssanders@ku.edu> wrote concerning "Mac OSX and Brat": > 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. Oh yes. I use ldd quite often to figure out if I did the linking correctly, and so on. Do you have something like objdumb, or something? > In terms of the brat test programs: > > base -- WORKS > chkvparams -- FAILS with No Parameters found for C1 Could this be the filesystem again? > coord -- WORKS > detectorvolume -- WORKS > eventmanager -- SEGFAULTS > geometry -- WORKS > geometrymanager -- FAILS with ROOT system not initialized You're using a rather new version of ROOT aren't you? I don't think this has anything to do with the TROOT static instance, but I'm just checking. > magnetvolume -- WORKS > rotategeofile -- WORKS > setgeometryfiles -- WORKS > units -- FAILS with No Parameters found for C1 I think this may be related to the DLL/Bundle issue, but I'm not sure. Could you run `eventmanager' and `geometrymanager' in a debugger and see where it segfaults? Perhaps you need debugging symbols in the ROOT libraries to get any kind of meaningful result. Sometimes, ROOT and BRAT libraries will load libraries (not modules) behind your back. For example, the TSQLServer loads the MySQL library on demand. > 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 Thank you for that piece of information. That was very useful (and klind of you to provide it, so I didn have to go dig it up :-). > 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. Yep, that wouldn't work according to the quoted text. > 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 Ok. I get the `-g', but not really `-flat_namespace', and I guess `-undefined_suppress' allows you to have undefined references (like DEC's `-Wl,-excpect-unresolved,*'). > 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? For the BRAT libraries proper that would probably be near impossible, as we link a lot of program against the libraries. Anyway, try making a simple project, like say: // File Foo.hh (whopes, I mean foo.hh :-) class Foo : public Foo { int fFoo; public: Foo(int foo) : fFoo(foo) {} ClassDef(Foo,0) }; // File foo.cc ClassImp(Foo); // File configure.in AC_INIT(foo.cc) AM_INIT_AUTOMAKE(foo, 1.0) AC_PROG_CXX AC_DISABLE_STATIC AM_PROG_LIBTOOL ROOT_PATH AC_OUTPUT(Makefile) // File makefile.am pkglib_LTLIBRARIES = foo.la pkginclude_HEADERS = foo.hh foo_la_SOURCES = foo.cc foodict.cc foo_la_LDFLAGS = -module -avoid-version %dict.cc %dict.h:%.h @ROOTCINT@ -f $*dict.cc $(AM_CPPFLAGS) -c $< and copy <ROOT-PREFIX>/share/aclocal/root.m4 (unless <ROOT-PREFIX> is /usr or whatever) to acinclude.m4, and then run the usual cycle: aclocal automake -a autoconf ./configure --prefix=${HOME}/tmp make make install Note the compiler lines. They should be similar to the one you gave above. Now start ROOT, and see if you can load the module: root [0] gSystem->Load("${HOME}/tmp/lib/foo/foo.so"); If this doesn't work, then Libtool doesn't really know MacOSX. Could you specify the version of automake autoconf libtool compiler that you use? Thanks. Is it a GNU-like environment? But as you can see, there's defently hooks in Libtool to deal with modules and libraries differently. If libtool doesn't work, you're more or less forced to you plain-ol'-makefiles (not entirely, but almost) - but we'll deal with that if needed. > The fink discussion on this has: > 2.4 Building a Shared Library again thanks for that useful info. BTW, could you send me the link to the sourceforge page? Thanks. > 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 - 16:16:43 EDT