Re: AliSoft Re: [ROOT] MacOS 10.3 linking problem root/pythia or aliroot

From: Federico Carminati (Federico.Carminati@cern.ch)
Date: Tue Jan 06 2004 - 11:52:50 MET


Ciao,
  I am afraid that compiling with -single_module does not solve the 
problem. This just means that the different routines will effectively 
share the common blocks. However here the problem is different, because 
the common block is in two different locations, which are one in C++ and 
the other in Fortran, and which are not compiled together. The problem can 
be solved here defining HEPEVT only as extern in ROOT. In fact in the 
Hepevt.h file HEPEVT is both defined and declared extern, and I just 
removed the definition

Index: eg/inc/Hepevt.h
===================================================================
RCS file: /user/cvs/root/eg/inc/Hepevt.h,v
retrieving revision 1.2
diff -r1.2 Hepevt.h
37,38d36
< HEPEVT_DEF HEPEVT;
< 

Up to the root experts to decide whether this can be introduced in the 
repository or not. 
  However this does not solve all problems.  I could not find a way to
convince gcc + ld that the same common in two different libraries is not a 
duplicate symbol. In the case of HEPEVT is simple, as C offers the 
external keyword. For two FORTRAN libraries this is different. And in fact 
the link of AliRoot fails with the following message

ld: warning multiple definitions of symbol _w50512_
/usr/local/AliRoot/NewIO/lib/tgt_Darwin/libpythia6.dylib(single module) 
definition of _w50512_
/usr/local/AliRoot/NewIO/lib/tgt_Darwin/libpdf.dylib(single module) 
definition of _w50512_
ld: warning multiple definitions of symbol _w50513_
/usr/local/AliRoot/NewIO/lib/tgt_Darwin/libpythia6.dylib(single module) 
definition of _w50513_
/usr/local/AliRoot/NewIO/lib/tgt_Darwin/libpdf.dylib(single module) 
definition of _w50513_

  The only solution I know of for this is to use f2c to translate the two 
offending pdf routines in c, and then change the definition of common in 
extern. In fact there is an option in f2c that does that for you (-E). We 
may consider doing that if the number of MacOSX users increases, but I was 
also hoping for Apple to realise that this is a problem for FORTRAN users. 
Apparently they are not sensitive to this issue.
  The loadlibs.C procedure would not work because there are 
cross-dependencies in our libraries. I could make it work splitting our 
libraries to avoid cross dependencies, but this is what is happening 
anyway with the new reconstruction class. Again, if there is request for 
this we may introduce the split libraries... there are only the following 
files to modify:

M ITS/ITSLinkDef.h
M ITS/libITS.pkg
M STEER/STEERLinkDef.h
M STEER/libSTEER.pkg
M TPC/TPCBarrelLinkDef.h
M TPC/TPCLinkDef.h
M TPC/libTPC.pkg
M TPC/libTPCBarrel.pkg
M build/module.dep
M macros/loadlibs.C

Or I can provide the mods to private users to test. Hope this helps. Ciao, 
Fed

On Mon, 5 Jan 2004, Remi Mommsen wrote:

> Hi Constantin,
> 
> You could try to compile the fortran stuff with -single_module.
> 
> BTW: are you aware that you can install root3 with cernlib support from 
> fink (http://fink.sourceforge.net)?
> 
> HTH,
> 	Remi
> 
> On Jan 5, 2004, at 10:38 AM, Constantin Loizides wrote:
> 
> > Hi, sorry to bother again,
> > but this time I really think its
> > a problem:
> >
> > When trying to use pythia with Root and external
> > compile libpythia6 or with Aliroot I run
> > into the "multiple definitions of symbols"
> > problem (see down), known for the dyld on mac.
> > The definition of HEPEVT in pythia6x.f and
> > libEG.so (Hepevt.h) simply clash and
> > the linker does not simply take
> > the first defintion and disregards the
> > second (as e.g. ld on linux does).
> >
> > I tried to solve it by explicitely
> > makeing hepevt external in Hepevt.h
> > but then loading libEG.so fails
> > with very strange missing symbols
> > which are in libPythia6.so (which
> > is loaded first).
> >
> > Any ideas? I have been browsing
> > the web, it seems that one has
> > to work around it by suitably
> > using "external" but maybe someone
> > knows of a superior approach?
> > Maybe not using flat namespaces?
> >
> > Regards, Constantin
> >
> >
> > ALIROOT head (with config option to use pythia)
> > ---------------
> > root [0] gAlice->Init("ConfigPPR.C");
> >      ****************************************************************
> >      *                                                              *
> >      *    You are running AliRoot version NewIO
> >      *    The cvs tag for the current program is $Name:  $
> >      *                                                              *
> >      ****************************************************************
> > Seed for random number generation= 12345
> > dlopen error: dlcompat: dyld: aliroot multiple definitions of symbol 
> > _hepevt_
> > /prog/root/ali-head/lib/libEG.dylib(TGenerator.o) definition of 
> > _hepevt_
> > /prog/aliroot/ali-head/lib/tgt_Darwin/libpythia6.dylib(single module) 
> > definition of _hepevt_
> >
> >
> > ROOT 10.02 and pythia6.221
> > ---------------
> > gSystem->Load("$PYTHIA6LIB/libPythia6.so"); // Pythia6 library
> > root [1]    gSystem->Load("libEG.so");
> > root [2]    gSystem->Load("libEGPythia6.so");
> > dlopen error: dlcompat: dyld: /prog/root/ali-head/bin/root.exe 
> > multiple definitions of symbol _hepevt_
> > /prog/root/ali-head/lib/libEG.so definition of _hepevt_
> > /prog/pythia6/libPythia6221.dylib(single module) definition of _hepevt_
> >
> > Load Error: Failed to load Dynamic link library 
> > /prog/root/ali-head/lib/libEGPythia6.so
> >
> >
> >
> 
> 
> ---------------------------------------------------------------------
> Failure is not an option.
> It comes bundled with your Microsoft product.       (Ferenc Mantfeld)
> 
> *********************************************************************
> Remigius K. Mommsen                 e-mail: mommsen@slac.stanford.edu
> University of California, Irvine       URL:    http://cern.ch/mommsen
> c/o SLAC                             voice:        ++1 (650) 926-3595
> 2575 Sand Hill Road #35                fax:        ++1 (650) 926-3882
> Menlo Park, CA 94025, US              home:        ++1 (650) 233-9041
> *********************************************************************
> 
> 

-- 

                                            Federico Carminati

==============================================================================
|| Federico Carminati             ||  Telephone : +41.22.767.4959           ||
|| CERN-EP                        ||  Fax       : +41.22.767.9480           ||
|| 1211 Geneva 23                 ||  Mobile    : +41.76.487.4843           ||
|| Switzerland                    ||                                        ||
==============================================================================



This archive was generated by hypermail 2b29 : Sun Jan 02 2005 - 05:50:05 MET