[Gtkradiant] GtkRadiant and x86_64 linux
xpatrikx at home.se
Fri Jul 29 16:46:49 CDT 2005
> Patrik Jakobsson wrote:
>> Hi, I don't know if this has been discussed before but since the
>> mailing list archives are gone...
>> Im trying to compile GtkRadiant (SVN Checkout Mon Jul 25 20:14:33)
>> for x86_64 linux (slamd64).
>> I ran into some trouble:
>> scons: Building targets ...
>> g++ -Wl,-fini,fini_stub -L. -static-libgcc -ldl -shared -o
>> build/release/plugins/archivepak/plugin.os build/relea
>> build/release/plugins/archivepak/pak.os -Lbuild/release/libs -Llibs
>> ./libstdc++.a(tree.o): relocation R_X86_64_PC32 against
>> `std::_Rb_tree_increment(std::_Rb_tree_node_base*)' can not be used
>> when making a shared object; recompile with -fPIC
>> final link failed: Bad value
>> collect2: ld returned 1 exit status
>> I also get a couple of these:
>> scons: warning: Two different environments were specified for target
>> but they appear to have the same action: gcc -W -Wall
>> -Wcast-align -Wcast-qual -Wno-unused-parameter -O2 `xml2-config
>> --cflags` `pkg-
>> config glib-2.0 --cflags` `libpng-config --cflags` -c -o
>> File "SConscript", line 194, in ?
>> Has anyone gotten this to work?
> Yeah, but only for Doom 3 and you'll probably need to be a coder to
> use it.
> I don't have much time right now, but I'll send this to get you
> started [I haven't updated from svn for a while, so this might not
> apply cleanly]
> [If I get time later I'll clean it up if you get problems - let me know]
> It's a messy patch [because once you start trying 64-bit from latest
> svn you'll hit every 32-bit bug as well, so there
> might be some rubbish left over from fixing those only to notice them
> them get fixed by spog soon after.
> There are a few mass changes of int to unsigned and the like I did to
> try and remove warnings that aren't really necessary for 64 bit.
> The biggest problems, once you fixed scons to build with -fPIC, are
> std::size_t used in places where 32 bit is required or assumed [md5
> model loading had that, but
> I think it was fixed when sscanf was replaced. I think there's at
> least one GL_UNSIGNED_INT RenderIndex IIRC, that was std::size_t too]
> Running a release version might still hit the g++ bug if you load some
> maps - Caused by sse instructions like sqrt hanging if nans are used
> [afaict the default behaviour
> should be to ignore floating point errors unless you set the flags
> with fesetenv, so it appears to be a compiler bug] - but the bottom
> line is, it's better to use debug version.
Ok, thanks alot! I'll be digging into this when I get back from my
vacation (1-2 weeks).
More information about the Gtkradiant