Which linker setting determines the load path of a shared library?

I have built the Poco C++ library on Mac. When inspecting the built output files I notice that their load paths are absolute paths that point to the build directory. For example:

$ otool -L libPocoFoundation.dylib
libPocoFoundation.dylib:
    /Users/francis/orig/poco-1.3.6p2/lib/Darwin/i386/libPocoFoundation.9.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
    /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 625.0.0)

Which compiler or linker option determined this? How can I override this? (At compile time. I know that I can change it afterwards with the install_name_tool.)

Edit

The compiler is g++-4.0 (开发者_Go百科gcc version 4.0.1 Apple).

The linker is libtool (Apple Computer, Inc. version cctools-782)

I'm perusing the makefiles currently. Perhaps I'll figure it out myself. But all help is welcome!

Related question at stackoverflow.com "How to set the runtime path (-rpath) of an executable with gcc under Mac OSX?" explains some ways to do it at compile-time.

BTW: I've reproduced your POCO bug on MacOS Leopard and opened a bug 3164792 for POCO-1.4.0