On Wed, 08 Mar 2017 16:39:50 +0100 Dag-Erling Smørgrav <d...@des.no> wrote: > 4) Remove the hardcoded library path in lang/gcc* > > This makes it possible to work on software that includes both libraries > and programs while an earlier copy of the same software is already > installed. With the current state of gcc, the programs you are working > on will be linked against the version of the library that's already > installed instead of the version you just compiled, and there is nothing > you can do to prevent it. You won't notice anything if all you ever do > is "make && make install", because the new library will replace the old, > but if you try to run your program directly from the build tree, it will > use the wrong library. This can be incredibly frustrating if you're not > aware of it - imagine you're trying to fix a bug in that library and no > matter what you do, your regression test keeps failing...
If you want to run a program from its build directory and the program links to a library also in the build directory then you have to run the program with LD_LIBRARY_PATH environment variable set to the build directory. Or, you could link the program with -rpath <builddir>, but then you should relink it before installation. It's one of the things libtool takes care of automatically. If this is the problem you have then it has nothing to do with gcc. If you're not using libtool then your program probably does not have any rpath or runpath so it falls back on rtld/ldconfig which may find it in /usr/local/lib. _______________________________________________ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"