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.
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?
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.