Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!de-l.enfer-du-nord.net!feeder1.enfer-du-nord.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Rainer Weikusat Newsgroups: comp.os.linux.development.apps Subject: Re: Linking problem Date: Thu, 15 Dec 2011 09:39:40 +0000 Lines: 21 Message-ID: <8762himaw3.fsf@sapphire.mobileactivedefense.com> References: <20111215001104.13eda1b8@efreet.linux> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: individual.net 7lcH3izUn0rgiz9/MDeNoAcmkp2pTt1OkE/oyrzwCPRw+aHV0= Cancel-Lock: sha1:Bf7bMfMKFO8TeO3HRtTNZTOIJUk= sha1:IC9KYMmewg0eTDndEtZW2EK8USo= User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux) Xref: x330-a1.tempe.blueboxinc.net comp.os.linux.development.apps:325 Kevin Nathan writes: > I have just been tasked with maintaining a KDE/Qt app originally > written in 2004/2005 and parts of it updated in 2009. It is currently > compiling on a KDE 3.5.7 and Qt 3.0 system and needs to be able to run > on systems with various versions of KDE. The previous maintainer left > no notes on how he was doing this. The current autoconf/automake system > does not allow running on slightly older systems or newer KDE > 4.x/Qt4.0, at least not when I compile it. We have some clients that > are running the older systems and we cannot make them upgrade, so I am > stuck trying to support them. Chances are that the -rpath or -R linker options do what you need. You'll have to ship the libraries and the binaries which need them and know the place where the libraries will be installed. The compiler will also need suitable -I options to find the 'custom' headers and the linker additional -L to find them at link time. Provided autosorrow is being used correctly (almost a contradictio in adiecto, it seems ...), all of this should be settable by passing suitable LDFLAGS and CFLAGS environment variables to the configure invocation.