Re: 5.30/5.32 CompileMacro() inconsistency

Hi Thiemo,

This is most likely caused by ROOT now requiring that the libraries have their symbols resolved. The release notes do mention that "In addition we added the linker option "-Wl,--no-undefined" - but of course it was not obvious that these two are connected. Please see the release notes for the motivation.

Note that the documentation for "c" is a bit misleading: "c" was always compiling /and/ linking - it just doesn't load the library. But before, linking succeeded because ROOT did not require the shared libraries to resolve all their symbols at link time.

The work-around is to load the library that defines TestClass::DoSomething() before ACLiC-ing test3.C.

Cheers, Axel.

Thiemo Nagel wrote on 01/24/2012 10:01 AM:
> Dear ROOTers,
>
> trying out ROOT v5.32, I've come across an inconsistency in
> TSystem::CompileMacro() w.r.t. v5.30.
>
> Take the following code (test3.C):
>
> class TestClass {
> public:
> void DoSomething();
> };
>
> void test3() {
> TestClass a;
> a.DoSomething();
> }
>
> With v5.30/03, this compiles nicely (no linking is done):
>
> root [1] gSystem->CompileMacro( "test3.C", "C" )
> (int)1
>
> But on 5.32 (svn-v5-32-00-patches, r42668), compilation fails at the
> linking stage. Of course, linking must fail because DoSomething() is
> not defined, but the old behaviour of CompileMacro() was to not even
> attempt to link when "c" is specified.
>
> [1] themis:~/computing> root
> root [0] gSystem->CompileMacro( "test3.C", "c" )
> Info in <TUnixSystem::ACLiC>: creating shared library
> /nfs/hicran/home/tnagel/private/computing/test3_C.so
> /nfs/hicran/home/tnagel/private/computing/test3_C_ACLiC_dict.o: In
> function `G__test3_C_ACLiC_dict_3018_0_1(G__value*, char const*,
> G__param*, int)':
> test3_C_ACLiC_dict.cxx:(.text+0xa2b): undefined reference to
> `TestClass::DoSomething()'
> /nfs/hicran/home/tnagel/private/computing/test3_C_ACLiC_dict.o: In
> function `test3()':
> test3_C_ACLiC_dict.cxx:(.text+0xa69): undefined reference to
> `TestClass::DoSomething()'
> collect2: ld returned 1 exit status
> Error in <ACLiC>: Compilation failed!
> (int)0
>
> Bottom line: Is this change in behaviour intended? In the release
> notes, I haven't found anything about it (and it breaks my code).
>
> Cheers!
> Thiemo
>