hello Andy,
that's also what I did. It could be a problem with data
encoding: it is being suggested by one of the message below (ldd ...).
However -xarch=amd64 should include __amd64. So I really don't know
what's wrong.
And I guess you do not have any problem at all on your big memory test
machines. Could you send me the compilation echo in order to see the
options given to CC ?
thanks,
JY
Andy Hanushevsky wrote:
> Hi JY,
>
> This indicates that the template cache is corrupted. Do a make clean
> and start over again.
>
> Andy
>
> ----- Original Message ----- From: "Jean-Yves Nief" <[log in to unmask]>
> To: "Andy Hanushevsky" <[log in to unmask]>
> Cc: "Xrootd Mailing List" <[log in to unmask]>; "Gerardo
> Ganis" <[log in to unmask]>
> Sent: Tuesday, October 04, 2005 7:13 AM
> Subject: Re: compiling xrootd on Solaris 10 AMD64
>
>
>> hello Andy, Pete,
>>
>> I had already removed the security package in order to make
>> it compile (as well as monitoring) and it worked. However as I say,
>> there is a problem with the binairies
>> > xrootd -c .... -l ....
>> /scratch/nief/xrootd: syntax error at line 1: `(' unexpected
>>
>> and if I do for example:
>> > ldd libXrdOfs.so
>> ldd: libXrdOfs.so: has wrong class or data encoding
>>
>> there is something really wrong there though I am not able to
>> determine what it is exactly.
>> it is either a problem or some wrong option have been given to CC
>> (here is an example below), but I don't see anything obvious there.
>>
>> Creating executable ../../bin/sunx86_510/xrootd
>> CC -KPIC -DSUNCC -DSUNX86 -D_REENTRANT -mt
>> -D_POSIX_PTHREAD_SEMANTICS -fast -xtarget=opteron -xarch=amd64
>> ../../obj/sunx86_510/XrdXrootdAdmin.o
>> ../../obj/sunx86_510/XrdXrootdAio.o
>> ../../obj/sunx86_510/XrdXrootdConfig.o
>> ../../obj/sunx86_510/XrdXrootdFile.o
>> ../../obj/sunx86_510/XrdXrootdFileLock1.o
>> ../../obj/sunx86_510/XrdXrootdLoadLib.o
>> ../../obj/sunx86_510/XrdXrootdMonitor.o
>> ../../obj/sunx86_510/XrdXrootdPrepare.o
>> ../../obj/sunx86_510/XrdXrootdProtocol.o
>> ../../obj/sunx86_510/XrdXrootdResponse.o
>> ../../obj/sunx86_510/XrdXrootdStats.o
>> ../../obj/sunx86_510/XrdXrootdXeq.o
>> ../../obj/sunx86_510/XrdXrootdXeqAio.o -L/usr/lib/amd64 -L/lib/amd64
>> -lposix4 -lsocket -lnsl -L/lib -lpthread -ldl -lsunmath
>> -L../../lib/sunx86_510 -lXrd -lXrdNet -lXrdOuc
>> ../../obj/sunx86_510/XrdSfsNative.o -o ../../bin/sunx86_510/xrootd
>>
>> cheers,
>> JY
>>
>> Andy Hanushevsky wrote:
>>
>>> Hi JY,
>>>
>>> This is a known problem. If you're not using security, simply
>>> disable the package. Geri, finally, here's the explanation of what
>>> is happening. I will get you access to one of the memfs machines.
>>>
>>> Andy
>>>
>>> ----- Original Message ----- From: "Jean-Yves Nief" <[log in to unmask]>
>>> To: "Xrootd Mailing List" <[log in to unmask]>
>>> Sent: Monday, October 03, 2005 8:40 AM
>>> Subject: compiling xrootd on Solaris 10 AMD64
>>>
>>>
>>>> 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
>>>>
>>>>
>>>
>>
>>
>
