gcc compatibility

[cdinesh]

 Hi Sven

 I have tried with  set LD_DEBUG  on system A .
 The binary is looking  for libc and ld-linux librarys and 
 while loading them on system A  ld  has some problem.
 as of your reference ld checking  hashing type also  (.hash or .gnuhash)

now Iam planning to copy system B libraries ( mainly glibc-2.5) to system A 
at some location 
(i.e /usr/local/lib-2.5 ) and while building binary on system B  and give 
-L /usr/local/lib-2.5 

Is there any other processor ??

regards
dinesh



Sven Eschenberg wrote:
> 
> Hi Dinesh,
> 
> Well it is fairly normal to run into problems when trying to run a 
> progam with old libs, if it was linked to newer ones.
> 
> If there is a command line switch, it's rather related to ld (the 
> linker) whose switches of course can be passed to gcc.
> 
> To find out which switch might help and why exactly the old glibc's 
> dynamic linker doesn't like the executeable from system B, you can try 
> the following:
> 
> set LD_DEBUG to all (export LD_DEBUG="all")
> 
> Then run your program, and see if the linker spits out something where 
> exactly the problem occurs (maybe you are lucky)
> 
> One issue could be the .hash versus .gnu.hash section ... I don't know 
> when this was changed. But as long as we do not know what the linker was 
> trying to do, when it crashed, it will be hard to see, if the problem 
> can be fixed by a commandline switch.
> 
> Regards
> 
> -Sven
> 
> P.S.: To answer your previous gate.so question - It is a virtual shared 
> object which maps the kernel's syscall interface into the proces' memory 
> map ... I doubt this causes the linker to go nuts ...
> 
>>  Thank you Sven for quick response
>>   
>>   
>>>>  As you can see your program is linked against the NTPL version of
>>>> glibc 
>>>> on System A (running glibc 2.3) ... LinuxThreads support was dropped in 
>>>> 2.4 AFAIK. Obviously the version compiled on System B is linked against 
>>>> version 2.5 of glibc.
>>>>       
>> Correct both have different thread  versions
>>
>>   
>>>> You could check the outputs of your two glibc version to check for 
>>>> differences ... (Just run them), the output should somewhat look like
>>>>       
>> this:
>> yaa , correct  but  is there any compile option  in gcc that can ignore
>> glibc versions or ABI changes ??
>>
>>  Is there any problem in "linux-gate.so.1" ??
>>
>> thank you 
>> dinesh
>>  
>>   
> 
> 

-- 
View this message in context: http://www.nabble.com/gcc--compatibility-tp17396275p17420841.html
Sent from the gcc - Help mailing list archive at Nabble.com.