[cvsnt-dev] Re: Build issues 2.5.03.2146

[Richard Wirth]

Hello Tony,

Thursday, November 10, 2005, 7:56:01 AM, you wrote:

TH> Richard Wirth wrote:
>> Hello Tony,
>> 
>>   current sources do not build on x86_64 linux :-(

TH> Too late to fix for this release - we're dead on a release deadline at
TH> the moment.

>>   >>>>>
>> /bin/sh ../libtool --mode=link g++  -g -O2   -o sspi_protocol.la -rpath /usr/local/lib64/cvsnt -module -avoid-version ntlm/libntlm.la sspi_unix.lo common.lo  -lcrypt
>> g++ -shared -nostdlib /usr/lib64/gcc/x86_64-suse-linux/3.4.5/../../../../lib64/crti.o /usr/lib64/gcc/x86_64-suse-linux/3.4.5/crtbeginS.o  .libs/sspi_unix.o .libs/common.o -Wl,--whole-archive ntlm/.libs/libntlm.a -Wl,--no-whole-archive  -Wl,--rpath -Wl,/usr/lib64/../lib64 -Wl,--rpath -Wl,/usr/lib64/../lib64 -lcrypt -L/usr/lib64/gcc/x86_64-suse-linux/3.4.5 -L/usr/lib64/gcc/x86_64-suse-linux/3.4.5/../../../../x86_64-suse-linux/lib -L/usr/lib64/gcc/x86_64-suse-linux/3.4.5/../../../../lib64 -L/usr/lib64/gcc/x86_64-suse-linux/3.4.5/../../.. -L/lib/../lib64 -L/usr/lib/../lib64 /usr/lib64/../lib64/libstdc++.so -lm -lc -lgcc_s /usr/lib64/gcc/x86_64-suse-linux/3.4.5/crtendS.o /usr/lib64/gcc/x86_64-suse-linux/3.4.5/../../../../lib64/crtn.o  -Wl,-soname -Wl,sspi_protocol.so -o .libs/sspi_protocol.so
>> /usr/lib64/gcc/x86_64-suse-linux/3.4.5/../../../../x86_64-suse-linux/bin/ld: ntlm/.libs/libntlm.a(des.o): relocation R_X86_64_32S against `a local symbol' can not be used when making a shared object; recompile with -fPIC
>> ntlm/.libs/libntlm.a(des.o): could not read symbols: Bad value
>>   <<<<<

TH> Sounds like a linker (or possibly libtool) problem... the same code 
TH> works fine on 64bit solaris for example.  The code *is* compiled -fPIC
TH> by libtool automatically.

TH> Try updating libtool.

libtool version 1.5.14 (1.1220.2.195 2005/02/12 12:12:33) on SuSe 9.3

But it looks to me, the C-runtime ist the problem here (wrong crti.o /
crtbeninS.o). i'll heve to investigate more in deep...
And I'll try a build on Suse 10.0 with gcc 4.0.2...


>>   and the mdnsclient will not work because of misdefined mdnshandle_t
>>   (this should not be int).

TH> ???  It's a void*.

Sorry. I've misinterpreted the warnings. The cast go from int to pointer,
so they can be ignored...



-- 
Best regards,
 Richard                            mailto:richard at wirthware.de