Bug 199591 – sci-physics/root build failure

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Diego Elio Pettenò (RETIRED) 2007-11-18 21:16:18 UTC]

cint/src/gcc3strm.cxx: In function ‘int G__G__stream_7_7_0(G__value*, const char*, G__param*, int)’:
cint/src/gcc3strm.cxx:311: error: ‘class std::fpos<__mbstate_t>’ has no member named ‘operator==’
cint/src/gcc3strm.cxx: In function ‘int G__G__stream_7_8_0(G__value*, const char*, G__param*, int)’:
cint/src/gcc3strm.cxx:317: error: ‘class std::fpos<__mbstate_t>’ has no member named ‘operator!=’
cint/src/gcc3strm.cxx: In function ‘int G__G__stream__3_17(G__value*, const char*, G__param*, int)’:
cint/src/gcc3strm.cxx:3030: warning: dereferencing type-punned pointer will break strict-aliasing rules
make: *** [cint/src/gcc3strm.o] Error 1

[Comment 1 Sébastien Fabbro (RETIRED) 2007-11-20 16:33:51 UTC]

Hi Diego,

Could you provide the root version and emerge --info?

Sébastien

[Comment 2 Markus Dittrich (RETIRED) 2007-11-26 18:28:27 UTC]

Created attachment 137064 [details, diff]
patch containing compile fixes for >=gcc-4.2

The issue is caused by >=gcc-4.2. I've back-ported 
several fixes from upstream's svn trunk and merged them
into the above (large) patch which fixes the issue for me.
Please give it a spin.

Thanks,
Markus

[Comment 3 Markus Dittrich (RETIRED) 2007-12-10 11:33:05 UTC]

Hi Sébastien,

I just tried the gcc-4.2 patch on my opteron and compilation
succeeds flawlessly. Could you please post the exact issue you are 
having with it on amd64 so I can have a look?

Thanks,
Markus

[Comment 4 Sébastien Fabbro (RETIRED) 2007-12-12 14:12:11 UTC]

> I just tried the gcc-4.2 patch on my opteron and compilation
> succeeds flawlessly. Could you please post the exact issue you are 
> having with it on amd64 so I can have a look?

* with use flags: afs

g++  -pipe -Wall -m64 -fPIC -Iinclude -DR__HAVE_CONFIG -pthread -I. -o cint/lib/dll_stl/G__cpp_complex.o -c cint/lib/dll_stl/G__cpp_complex.cxx
/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.2/../../../../x86_64-pc-linux-gnu/bin/ld: /usr/lib64/libafsauthent.a(client.o): relocation R_X86_64_32 against `grmutex' can not be used when making a shared object; recompile with -fPIC
/usr/lib64/libafsauthent.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
make[5]: *** [../../lib/libXrdSecpwd.so] Error 1
make[4]: *** [Linuxall] Error 2
make[3]: *** [all] Error 2
make[2]: *** [XrdSecpwd] Error 2
make[1]: *** [all] Error 2

trying to link pic with static libs. But probably be it's not gcc4.2 specific.

Also with even with USE=-truetype, complained for missing Xft.
root still needs a bit of work with deps, opengl was one problem, I am actually testing some of them now.

[Comment 5 Markus Dittrich (RETIRED) 2007-12-15 22:07:26 UTC]

Hi Sebastien,

I had a look at the afs stuff and after some time I actually
managed to (almost) build root against the afs shared libs.
Unfortunately, libafsauthent.so and libafsrpc.so are 
missing some symbols which is probably a bug in one
of afs's makefiles (I found a bug report about this on a
SUN-afs forum). I'll probably commit the gcc patch later
and will see if I can fix openafs. Once that's done root
will hopefully build against afs as well.

cheers,
Markus

[Comment 6 Markus Dittrich (RETIRED) 2007-12-16 17:27:10 UTC]

I just added a patch to root-5.16.00-r1 that fixes the afs problems
from root's point of view.
Unfortunately, it still doesn't compile since openafs's shared objects
seem to miss a few symbols that root needs. I've filed a bug with
the openafs maintainer and provided a patch (bug #202489).
After recompiling openafs with this patch root compiles smoothly
with USE=afs on my amd64 box.

[Comment 7 Sébastien Fabbro (RETIRED) 2008-01-10 00:12:59 UTC]

This one was fixed with the gcc4 patch. Thanks for reporting.