fangee <[EMAIL PROTECTED]> writes: > As I can recall, I was able to static compiling it and having it run > on linux systems where no g++ nor libstdc++ were installed.
I see. Your goal is to "get rid of dynamic libstdc++.so" dependency. > Recently I discovered that I lost the executable and so I wanted to > recompile it. As it seems I cannot static compile it again, but > linking with '-rpath .' I only have to put libstdc++ in the same > directory where the executable (dinamycally compiled) is. Your solution works only if you run your exe from the same directory where libstdc++.so resides. E.g. mkdir /tmp/foo cp a.out libstdc++-3-libc6.1-2-2.10.0.so /tmp/foo cd /tmp/foo && ./a.out # works cd ../ && ./foo/a.out # doesn't work cd $HOME; PATH=/tmp/foo:$PATH; a.out # doesn't work If copying 2 files to the target system (a.out and libstdc++-3-libc6.1-2-2.10.0.so) is acceptable, a better solution is to use '-Wl,-rpath,$ORIGIN'. This tells the dynamic loader to look for libraries in the same place where the executable was loaded from (as opposed to "in current directory"). Alternatively, here is a recipe that eliminates dynamic libstdc++.so, while leaving the rest of the executable dynamically linked: ln -s $(g++ -print-file-name=libstdc++.a) ./ g++ -o a.out main.o ... -L. rm -f ./libstdc++.a Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
