From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31190 invoked by alias); 22 May 2008 07:18:41 -0000 Received: (qmail 31179 invoked by uid 22791); 22 May 2008 07:18:40 -0000 X-Spam-Check-By: sourceware.org Received: from hera.rbi.informatik.uni-frankfurt.de (HELO hera.rbi.informatik.uni-frankfurt.de) (141.2.1.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 22 May 2008 07:18:22 +0000 Received: from [141.2.119.180] (fahrenheit.ghl40.whgl.uni-frankfurt.de [141.2.119.180]) by hera.rbi.informatik.uni-frankfurt.de (8.13.8/8.13.8) with ESMTP id m4M7IIIe032118; Thu, 22 May 2008 09:18:18 +0200 Message-ID: <48351E4C.7010104@cs.uni-frankfurt.de> Date: Thu, 22 May 2008 08:17:00 -0000 From: Sven Eschenberg User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: cdinesh CC: gcc-help@gcc.gnu.org Subject: Re: gcc compatibility References: <17396275.post@talk.nabble.com> <4834EE51.1020808@cs.uni-frankfurt.de> <17397451.post@talk.nabble.com> In-Reply-To: <17397451.post@talk.nabble.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org X-SW-Source: 2008-05/txt/msg00223.txt.bz2 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 > >