 |
 |
Hi JY, Here's the info. Compiling a true 64-bit program: CC -c -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -KPIC -DSUNCC -DSUNX86 -D_REENTRANT -mt -D_POSIX_PTHREAD_SEMANTICS -g -xs -xtarget=opteron -xarch=amd64 -DXrdDEBUG=1 -I. -I.. -o ../../obj/sunx86_510_dbg/XrdSecClient.o XrdSecClient.cc Compiling a psuedo-64-bit program: CC -c -KPIC -DSUNCC -DSUNX86 -D_REENTRANT -mt -D_POSIX_PTHREAD_SEMANTICS -g -xs -xtarget=opteron -xarch=amd64 -DXrdDEBUG=1 -I. -I.. -o ../../obj/sunx86_510_dbg/XrdSecPManager.o XrdSecPManager.cc There is one more variation specific to Solaris/AMD which involves using 32-bit interfaces in a 64-bit program and requires special if/defs in the actual source code. It's too complicated to explain here and only comes up with using the dynamic loader interface. The problem here is not the compilation step but the linkage step which has two problems: 1) library search order specified in the wrong order, and 2) including libcrypt.so which is ELF32. In Solaris that library has been renamed to libcryptoutil.so (yeah, sort of sucks doesn't it). The following is the original link step: The following modification creates a good executable: CC -KPIC -DSUNCC -DSUNX86 -D_REENTRANT -mt -D_POSIX_PTHREAD_SEMANTICS -fast -xtarget=opteron -xarch=amd64 ../../obj/sunx86_510_dbg/XrdSecpwdSrvAdmin.o ../../lib/sunx86_510_dbg/libXrdCrypto.a ../../lib/sunx86_510_dbg/libXrdSut.a ../../lib/sunx86_510_dbg/libXrdOuc.a -L/usr/lib/amd64 -L/lib/amd64 -lcryptoutil -lposix4 -lsocket -lnsl -L/lib -lpthread -ldl -lsunmath -o ../../bin/sunx86_510_dbg/xrdpwdadmin The prefered linakge is: CC -KPIC -DSUNCC -DSUNX86 -D_REENTRANT -mt -D_POSIX_PTHREAD_SEMANTICS -fast -xtarget=opteron -xarch=amd64 ../../obj/sunx86_510_dbg/XrdSecpwdSrvAdmin.o -L/usr/lib/amd64 -L/lib/amd64 -lcryptoutil -lposix4 -lsocket -lnsl -L/lib -lpthread -ldl -lsunmath -L../../lib/sunx86_510_dbg -lXrdCrypto -lXrdSut -lXrdOuc -o ../../bin/sunx86_510_dbg/xrdpwdadmin which does not include the ".a" files on the command line (it's also sorter). I will look into how to change this in the make files. I'm sure the autotools version will have conniptions with this as well. Andy On Mon, 3 Oct 2005, Jean-Yves Nief wrote: > hello, > > I am trying to compile xrootd on this platform on a test machine: > the next couple of servers I am going to have in a few weeks will be > working on that OS with Opteron CPUs (SUN v40z). > I had problems when compiling XrdSecpwdSrvAdmin.cc: > Creating executable ../../bin/sunx86_510/xrdpwdadmin > ld: fatal: file ../../obj/sunx86_510/XrdSecpwdSrvAdmin.o: wrong ELF > class: ELFCLASS64 > ld: fatal: File processing errors. No output written to > ../../bin/sunx86_510/xrdpwdadmin > gmake[4]: *** [../../bin/sunx86_510/xrdpwdadmin] Error 1 > gmake[3]: *** [SunOSall] Error 2 > gmake[2]: *** [all] Error 2 > gmake[1]: *** [XrdSecpwd] Error 2 > gmake: *** [all] Error 2 > > CC is being used: > > CC -V > CC: Sun C++ 5.7 Patch 117831-03 2005/07/21 > > I tried to remove this module as it is not necessary for me at this > point, however I ended up with a xrootd binary I was not able to > execute. So there could be something trivial missing in the installation > of the dev machine (might be possible as I noticed that there are stuff > not being there) or something that I don't know of. > The script "configure" had apparently no problem to detect the right > architecture. > thanks for any hints, > JY > >