Re: Symbol clash -- Root 5.32 and Geant4 9.5

From: Tom Roberts <tjrob_at_fnal.gov>
Date: Sat, 21 Jan 2012 10:12:47 -0600


I removed libG4zlib.a from the link, and the link succeeded (presumably Geant4 is using the Root implementation of zlib). The program passes my test "Root input and output", which is the only use of Root in the program (reading and writing TNtuples). Some other regression tests fail, but that is common for a new release of Geant4; I have to study them, and probably increase their tolerances to accommodate new versions of physics processes.

For now I consider this resolved, and have modified my Makefile accordingly.

Tom Roberts

On 1/21/12 1/21/12 12:07 AM, Tom Roberts wrote:
> I am trying to build a program (G4beamline) with the latest versions of both
> Root and Geant4. Unfortunately there is a symbol clash, and I'm looking for
> advice. The problem seems to be more with Root than Geant4, but I don't know
> that for sure. Note I build from source, do "make static", and use libRoot.a,
> not the shared objects. For now I am working on Mac OS X 10.5.8 (Leopard), which
> is a 64-bit OS but a 32-bit compiler; eventually I'll need to build on 32- and
> 64-bit Mac, Linux, and Windows.
>
> Root 5.32 has an option "--minimal" that looks like what I need, because the
> only Root classes used directly are TFile, TDirectory, and TNtuple. I found that
> Root determines 32-bit vs 64-bit architecture based on the OS, not the compiler;
> as I am compiling with other code I need to specify the architecture of the
> compiler. I then found that the obvious configuration did not build because of
> missing symbols:
> ./configure macosx --minimal
> I enabled builtin-s until Root built by itself:
> ./configure macosx --minimal --enable-builtin-lzma --enable-builtin-zlib
>
> Then I tried building G4beamline, with Geant4 9.5 and Root 5.32. I got this error:
> Linking g4beamline
> ld: duplicate symbol _zlibVersion in .../libRoot.a(zutil.o) and
> .../libG4zlib.a(zutil.cc.o)
> collect2: ld returned 1 exit status
>
> Then I tried the obvious way to resolve the conflict (after completely removing
> Root so it gets re-configured and re-built):
> ./configure macosx --minimal --enable-builtin-lzma --disable-builtin-zlib
> and got this error:
> Linking g4beamline
> Undefined symbols:
> "_inflate", referenced from:
> _R__unzip in libRoot.a(ZInflate.o)
> "_inflateEnd", referenced from:
> _R__unzip in libRoot.a(ZInflate.o)
> _R__unzip in libRoot.a(ZInflate.o)
> "_inflateInit_", referenced from:
> _R__unzip in libRoot.a(ZInflate.o)
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
>
>
> Part of the problem is that neither codes has a class name or namespace to
> differentiate the two implementations of zlib. I don't care about 2
> implementations, as long as they co-exist peacefully (the Geant4 and Root code
> never interact directly with each other).
>
> Suggestions?
>
> [If there is only one symbol in conflict, one option is to just
> edit one source to change its name. But I suspect there are
> lots of conflicting names and link only displayed the first one.
> I already have a handful of edits to Geant4 that must be re-done
> for each new version.]
>
> [Another option is to revert to using shared objects. This has thorns
> on systems with other installations of Root. It is also a pain when
> distributing a binary release (which I need to do). And some
> supercomputers do not support shared objects on worker nodes.]
>
> [These two zutil.cc are obviously derived from the same initial
> implementation, a third option is for me to put the union of
> them into my source. As I don't think my code actually uses
> any of this, perhaps making them just call abort().]
>
>
> Tom Roberts
>
Received on Sat Jan 21 2012 - 17:12:57 CET

This archive was generated by hypermail 2.2.0 : Mon Jan 23 2012 - 23:50:01 CET