rpath

I'm trying to specify rpath in my binary. My makefile looks like this- CC=gcc CFLAGS=-Wall LDFLAGS= -rpath='../libs/' main: main.c gcc -o main main.c clean: rm -f main main.o But when I query rpath using command readelf -a ./main | grep rpath I get nothing I've tried specifying rpath as LDFLAGS= "-rpath=../libs/" but even that doesn't seem to work. Can someone please post an example on how should I specify rpath in a makefile? GCC and ld versions are- gcc (Ubuntu/Linaro 4.5.2-8ubuntu4) 4.5.2 GNU ld (GNU Binutils for Ubuntu) 2.21.0.20110327 If you set the variables, you should probably use them

I have a shell that runs CentOS. For a project I'm doing, I need python 2.5+, but centOS is pretty dependent on 2.4. From what I've read, a number of things will break if you upgrade to 2.5. I want to install 2.5 separately from 2.4, but I'm not sure how to do it. So far I've downloaded the source tarball, untarred it, and did a ./configure --prefix=/opt which is where I want it to end up. Can I now just make, make install ? Or is there more? boerre You could also use the EPEL-repository , and then do sudo yum install python26 to install python 2.6 Joyce Babu Try epel wget http://download

I compiled Python 2.6.6 with google-perf tools (tcmalloc) library to eliminate some of the memory issues I was having with the default 2.6.5. After getting 2.6.6 going it seems to not work becuase I think having issues with the default 2.6.5 install in Ubuntu. Will none of the binaries installed from the software channel like wxPython and setuptools work properly with 2.6.6. Do these need to be recompiled? Any other suggestions to get it working smoothly. Can I still set 2.6.5 as default without changing the Path? The path looks in usr/local/bin first. A good general rule of thumb is to NEVER

I've got a binary "CeeloPartyServer" that needs to find libFoundation.so at runtime, on a FreeBSD machine. They're both in the same directory. I compile (on another platform, using a cross compiler) CeeloPartyServer using linker flag "-rpath=$ORIGIN". > readelf -d CeeloPartyServer |grep -i rpath 0x0000000f (RPATH) Library rpath: [$ORIGIN] > ls CeeloPartyServer Contents Foundation.framework libFoundation.so > ./CeeloPartyServer /libexec/ld-elf.so.1: Shared object "libFoundation.so" not found, required by "CeeloPartyServer" Why isn't it finding the library when I try to run it? My exact linker

I just made a basic example of using ld's -rpath option with $ORIGIN here (see 2nd response for a working version). I'm trying to create an example where main.run links to foo.so , which in turn links to bar.so , all using rpath and $ORIGIN . The run-time file-structure is: project/ lib/ dir/ sub/ bar.so foo.so run/ main.run (failing to build) I'm building foo.so using: g++ -c -o obj/foo.o src/foo.cpp -fPIC g++ -shared -o lib/dir/foo.so obj/foo.o -Wl,-soname,foo.so -Wl,-rpath,'$ORIGIN/sub' -Llib/dir/sub -l:bar.so Which builds fine. ldd lib/dir/foo.so can even find bar.so . However, when I try

I have been trying to compile openssl 1.0.0g with the following rpath: $ORIGIN/../lib64 Everytime I readelf -d apps/openssl , I am getting results like the following depending on what escaping variation I tried: \RIGIN/../lib64 RIGIN/../lib64 ORIGIN/../lib64 I want to setup my rpath without using external tools like chrpath. Is it at all possible? I will basically accept anything that does not involve using external tools like chrpath (though I would already be done with that). Ideally, I would like to do it by passing options on the command line (any form of -Wl,-rpath,$ORIGIN/../lib64 ). I

On Windows, I'm cross-compiling a program for ARM/Linux using CodeSourcery's cross-compiler suite. I use MinGW MSYS as my command interpreter, and very often it will mangle my paths and pathnames. For example, to build my program, I invoke arm-none-linux-gnueabi-gcc.exe -Wall -g \ -Wl,--dynamic-linker=/usr/lib/myrpath/ld-linux.so.3 \ -Wl,-rpath=/usr/lib/myrpath \ -I../targetsysroot/usr/include \ myprogram.c -o myprogram Of course, I want /usr/lib/myrpath inserted verbatim into the myprogram executable - the ARM Linux target I'm compiling for doesn't use MinGW or MSYS. But here's what ends up