From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19537 invoked by alias); 7 Jan 2005 22:25:04 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 19493 invoked from network); 7 Jan 2005 22:24:52 -0000 Received: from unknown (HELO cygnus.hi.gemini.edu) (128.171.188.208) by sourceware.org with SMTP; 7 Jan 2005 22:24:52 -0000 Received: from [10.1.5.150] (phact.hi.gemini.edu [10.1.5.150]) by cygnus.hi.gemini.edu (Switch-3.1.7/Switch-3.1.7) with ESMTP id j07MOpFw007695 for ; Fri, 7 Jan 2005 12:24:51 -1000 (HST) Message-ID: <41DF0C33.4030506@gemini.edu> Date: Fri, 07 Jan 2005 22:25:00 -0000 From: Craig Allen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041217 MIME-Version: 1.0 CC: gcc-help@gcc.gnu.org Subject: Re: Question about linking multiple copies of the same library References: <9F6C06DD358A58458921D913A8C8BF7ACA9471@itszaex01.intec.co.za> <41D57223.9060100@datapower.com> In-Reply-To: <41D57223.9060100@datapower.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-MASF: 0.00% X-SW-Source: 2005-01/txt/msg00037.txt.bz2 Matthias, I'm not sure this is what you want to hear... someone might know a better hack that will work for you... but I think you have a serious issue there in that a regular linker is not going to like the idea that you want identical symbols linked for different compilation units. If you used static libraries, you could do this by being careful with intermediate linking steps where you linked the libraries into the different modules and then linked everything together in the end. I actually suspect you would get some duplicate symbol errors in that case too. With .so files you can dlopen() the library yourself and make the symbolic links dynamically. This is a pain, yes? In fact, you can't do this for a precompiled thirdparty library and would have to, instead, either create a thunking library to do this for the thirdparty library, or in all your standard library use you would have to manage all the dynamic library loading for yourself in your main application. Both are a mess. I think the solution of least effort is to give up wanting to use the newer version of the standard library and just use the functions in the older library for your own code as well. Ship that library or require your customer to aquire it on their own. Hopefully someone will have something better than this. What I've said is from years of C++ programming, not gcc knowledge, so maybe someone knows some gcc-specific trick. good luck. -craig Matthias David Siebler wrote: > > >> This usually works because the libraries are backwards compatible, > > > > > In general one would hope that to be true, but not in this case. > Allow me to be more specific: > > i am compiling on a GNU/Linux/Intel system. > > I have a thirdparty library (libthird.so) that requires > libstdc++-libc6.1-2.so.3 > if libthird.so is linked against another newer version of libstdc++ > then it will crash. > > However, i wish to link the rest of my application against a newer > version of libstdc++ > > is this possible? How do i set the options so that libthird.so > resolves only against libstdc++-lib6.1-2.so.3 and the rest of the code > links against the newest version of libstdc++? > > > Thanks to everyone for your help. > > > > -- Craig Allen callen@gemini.edu Software Engineer