Hello Christian and Philippe, thanks for your proposals and assistance. Well it could really be a compiler problem as DCOM/Entire-X 6.1.1 is from the SuSE 6.4 days when the egcs compiler was used. A new one (7.1.1) is said to be compatible with gcc 3.2. The mico package was created from source by me, also ROOT - so there is no incompatibility with my present environment. Unfortunatley the 3rd party libraries hide their origin very well: > nm -C /opt/sag/exx/v611/lib/libbasecrypt.so nm: /opt/sag/exx/v611/lib/libbasecrypt.so: no symbols > nm -C /opt/sag/exx/v611/lib/liboleaut32.so nm: /opt/sag/exx/v611/lib/liboleaut32.so: no symbols > nm -C /opt/sag/exx/v611/lib/libmutant.so nm: /opt/sag/exx/v611/lib/libmutant.so: no symbols Some of the (not top secret) libs gave messages like: "gcc2_compiled" or "*@@@GLIBC_2.0" nm -C /usr/local/mico/lib/libmico.so | more give of course many "gcc2_compiled" messages. As we are planning soon a move to gcc 3.x I see no reason to downgrade to pre-2.95 times ;-) Do you think that I can force the loading order of the libraries ? Thanks again & Cheers Hermann-Josef On Thu, 20 May 2004, Christian Holm Christensen wrote: > Hi, > > Philippe Canal <pcanal@fnal.gov> wrote concerning > RE: [ROOT] Crashing before main() [Wed, 19 May 2004 16:01:14 -0500] > ---------------------------------------------------------------------- > > Hi, > > > > Indeed, the most likely cause is a load ordering issue. > > A long time ago, I had a similar problem that was bothering me a lot. > I was trying to run a small program that used a third-party, > proprietary, binary-only, library - it kept SIGSEGV even before I > could break into main. > > Well, it turned out, that the third-party library I was linking > against, was compiled with another (and incompatible) compiler than > the one I was using (I think it was EGCS vs. GCC - yes, that long time > ago :-). I solved the problem by using the compiler used to build the > third-party library. > > So, I guess you should check Mico and see if it's build with the same > compiler as you build ROOT and your application with. > > > Surprisingly (actually I think this is a compiler error), gSystem > > must be neither zero nor a valid value. > > What about NULL? > > > You could assert this 'guess' by putting a fprintf(stderr,"0x%x\n",gSystem); > > in TTimer::Reset(). > > Why not > > std::cout << "0x" << std::hex << gSystem << std::endl; > > :-) > > > You may also want to check that ldd esmd returns the expected libraries. > > This may also give you a hint of what I was talking about. > > You can also check > > nm -C <path to lib>/libmico.so > > (or what ever it's called) and see what kind of GCC was used (the > symbols are obvious). > > > > > Cheers, > > Philippe. > > > > -----Original Message----- > > From: owner-roottalk@pcroot.cern.ch > > [mailto:owner-roottalk@pcroot.cern.ch]On Behalf Of Mathes, Hermann-Josef > > Sent: Monday, May 10, 2004 10:46 AM > > To: roottalk@cern.ch > > Cc: Mathes, Hermann-Josef; kopmann@ik.fzk.de; > > michael.funcke@physik.uni-wuppertal.de > > Subject: [ROOT] Crashing before main() > > > > > > Dear Rooters, > > > > I have a problem in a large application coming probably from some dynamic library incompatibilities. > > > > The program is crashing before main() is executed. > > > > I am using the following 'environment': > > - SuSE Linux 7.3 with gcc 2.95.3 and kernel 2.4.10 > > - root 3.05.07, generated with the options: > > "./configure linux --enable-table --enable-thread --enable-soversion" > > - Mico 2.3.0 (a free CORBA implementation) > > - Entire-X 6.1.1 (DCOM for Linux/Unix) + OCSLTK 1.1 (this is an OPC=OLE for > > Process Control built on top of DCOM) > > > > The problem persits independent from the fact if a TROOT object is created. Im not using any ROOT classes (like TObject & Co. or TSocket) simply the dictionary compiled into one of my own libs. > > > > Using this rather 'old' releases is done for technical (hardware & driver compatibility) reasons. > > > > The DCOM-stuff is using threads (intrinsically for IUnknown derived client side interfaces=callbacks). > > > > This is the error I get (with/without debugger): > > > > mathes@ikauger2:~/FD-DAS/Eye/Esm/daemon> esmd > > Segmentation fault > > mathes@ikauger2:~/FD-DAS/Eye/Esm/daemon> gdb esmd > > GNU gdb 20010316 > > CThis GDB was configured as "i386-suse-linux"... > > (gdb) r > > Starting program: /home/mathes/FD-DAS/Eye/Esm-devel/daemon/esmd > > [New Thread 1024 (LWP 4509)] > > > > Program received signal SIGSEGV, Segmentation fault. > > [Switching to Thread 1024 (LWP 4509)] > > 0x410547b1 in TTimer::Reset () from /usr/local/root-3.05.07/lib/libCore.so.3.05 > > (gdb) back > > #0 0x410547b1 in TTimer::Reset () > > from /usr/local/root-3.05.07/lib/libCore.so.3.05 > > #1 0x41054317 in TTimer::TTimer () > > from /usr/local/root-3.05.07/lib/libCore.so.3.05 > > #2 0x41054b8e in __static_initialization_and_destruction_0 () > > from /usr/local/root-3.05.07/lib/libCore.so.3.05 > > #3 0x41054e12 in global constructors keyed to TTimer::TTimer () > > from /usr/local/root-3.05.07/lib/libCore.so.3.05 > > #4 0x412d8f27 in __do_global_ctors_aux () > > from /usr/local/root-3.05.07/lib/libCore.so.3.05 > > #5 0x40fe4452 in _init () from /usr/local/root-3.05.07/lib/libCore.so.3.05 > > #6 0x4000b7a7 in call_init () from /lib/ld-linux.so.2 > > #7 0x4000b900 in _dl_init () from /lib/ld-linux.so.2 > > (gdb) > > > > Thanks for any help or proposal to solve the problem. > > Regards > > Hermann-Josef > > Yours, > > ___ | Christian Holm Christensen > |_| | ------------------------------------------------------------- > | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 > _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 > _| Denmark Office: (+45) 353 25 404 > ____| Email: cholm@nbi.dk Web: www.nbi.dk/~cholm > | | > >
This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:08 MET