September 2006 - openSUSE Programming - openSUSE Mailing Lists

LD_RUN_PATH on SUSE 10.x
by Roger Oberholtzer 08 Oct '06

08 Oct '06

I have a situation where a package installs some of its own libraries, as well as one library with the exact same name as on in /usr/lib. However, the package's library was compiled with different flags and is not compatible with the one in /usr/lib. If I set LD_RUN_PATH to include the package's libraries, my executables that link with the library in /usr/lib pick up the one in the package's directory instead when they are run. IIRC, SVR4.2 (e.g., UnixWare) had syntax for LD_RUN_PATH that told if the paths in LD_RUN_PATH should be checked before or after the system directories. Is there any such capability for Linux? I would in fact prefer to put the package's library directory in ldconfig. However, doing so keeps things like KDE, GNOME and YAST from running, as they then pick up the offending/incompatible version of the library. That is why I am even bothering with LD_RUN_PATH. -- Roger Oberholtzer

4 9

questions about glibc and rtkaio
by Mark Seger 22 Sep '06

22 Sep '06

I'm pretty new to glibc building but have managed to get the rtkaio support built on a redhat system by simply getting the source rpm, modifying the spec file and doing an rpmbuild. Now I want to try and build rtkaio support for sles 10 and am not sure how to proceed. I did get a copy of the glibc-2.4 tarball and tried building that. Alas, it build just fine but no rtkaio! I searched the entire source pool for 'rtkaio' and found a single entry in the .cvsignore file and so am guessing that the rtkaio source is not part of the standard distribution. Does this mean I need to get the rtkako source elsewhere and built it separately - I couldn't find anything with google - and if so can I assume the appropriate directions are contained within it? Is there such a thing as a glibc distro that does contain the rtkaio source to simplify the whole process? Is there a 'standard' recommended method? -mark

1 0

Porting from SLES9/EM64T to SLES9/AMD64
by Rajib Majumder 03 Sep '06

03 Sep '06

Hi, After porting a C++ application from SLES9/EM64T architecture to SLES9/AMD64, it fails to work. Apparently, looks like a stack corruption is happening. It works perfect on SLES9/EM64T arch. Any idea what might have gone wrong? Env is same on both boxes and gcc used was 3.3.2 to build the application. Any input is highly appreciated. Thanks Rajib

3 2