Bug 199591 - sci-physics/root build failure
|
Bug#:
199591
|
Product: Gentoo Linux
|
Version: unspecified
|
Platform: All
|
|
OS/Version: Linux
|
Status: RESOLVED
|
Severity: normal
|
Priority: P2
|
|
Resolution: FIXED
|
Assigned To: sci-physics@gentoo.org
|
Reported By: flameeyes@gentoo.org
|
|
Component: Ebuilds
|
|
|
URL:
|
|
Summary: sci-physics/root build failure
|
|
Keywords:
|
|
Status Whiteboard:
|
|
Opened: 2007-11-18 21:16 0000
|
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
Hi Diego,
Could you provide the root version and emerge --info?
Sébastien
Created an attachment (id=137064) [details]
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
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
> 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.
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
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.
This one was fixed with the gcc4 patch. Thanks for reporting.