Re: Problem with statically-linked executable

Hi,

The static link of ROOT (roota and libRoot.a) should now work properly on linux and MacOS.

Cheers,
Philippe.

Fons Rademakers wrote:
> Hi Tom,
>
> on SLC5 or other Linux version I've not (yet) seen the
> GetGroupInfo() warning. Do you see this when doing "make static" or
> when using special static options to link your app?
>
> The Mac static version is currently broken as CINT is always
> dynamically loaded. We are working on a fix.
>
> Cheers, Fons.
>
>
>
> Tom Roberts wrote:
>> When I link my program with Root using static libraries, I get the
>> following warning (this is Linux, SLF 309):
>>
>> /home/tjrob/g4bl/G4beamline/lib/Linux-g++/libRoot.a(TUnixSystem.o)(.text+0x3d11):
>> In function `TUnixSystem::GetGroupInfo(int)':
>> : Using 'getgrgid' in statically linked applications requires at
>> runtime the shared libraries from the glibc version used for linking
>> ... about a dozen similar warnings.
>>
>> The program does execute, but of course I do have those shared
>> libraries present at runtime. I have no idea if it is actually
>> loading and using them. ldd says "not a dynamic executable".
>>
>> The whole point of linking statically is to avoid dependence on ANY
>> shared libraries at runtime.
>>
>> Is it possible to build Root so it is static safe?
>>
>> Note the only Root code I actually need is TFile and TNtuple and the
>> stuff they need. And even that's overkill, as I am ONLY reading and
>> writing TNtuples (so I don't really need all the stuff to read/write
>> arbitrary objects).
>>
>> I'm having so much trouble re-doing my build scripts using Root, I
>> have to wonder: is there some small and simple subset of Root code I
>> could pull out, that just does what I need? IIRC there was an old RIO
>> package....
>>
>> BTW I have been completely unable to link statically on Mac OS X, for
>> reasons unrelated to Root. Fortunately there's no burning need to do
>> that.
>>
>>
>> Tom Roberts
>>
>>
>> FYI here is how I configure Root 5.24. This is every disable I could
>> get away with -- the only things not disabled are cint5 and zlib:
>> ./configure \
>> --disable-afs --disable-alien --disable-asimage --disable-astiff
>> --disable-bonjour --disable-builtin-afterimage --disable-builtin-ftgl
>> --disable-builtin-freetype --disable-builtin-glew
>> --disable-builtin-pcre --disable-castor --disable-chirp
>> --disable-cint7 --disable-cintex --disable-clarens --disable-dcache
>> --disable-exceptions --disable-explicitlink --disable-fftw3
>> --disable-gdml --disable-gfal --disable-g4root --disable-globus
>> --disable-glite --disable-gsl-shared --disable-krb5 --disable-ldap
>> --disable-genvector --disable-mathmore --disable-memstat
>> --disable-minuit2 --disable-monalisa --disable-mysql --disable-odbc
>> --disable-opengl --disable-oracle --disable-pch --disable-peac
>> --disable-pgsql --disable-pythia6 --disable-pythia8 --disable-python
>> --disable-qt --disable-qtgsi --disable-reflex --disable-rfio
>> --disable-roofit --disable-rpath --disable-ruby --disable-sapdb
>> --disable-shadowpw --disable-shared --disable-soversion --disable-srp
>> --disable-ssl --disable-table --disable-unuran --disable-winrtdebug
>> --disable-xml --disable-xrootd --disable-xft
>>
>
Received on Wed Sep 09 2009 - 20:29:30 CEST