Date: Thu, 9 Mar 2017 13:29:26 +0100 From: Dimitry Andric <dim@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: Tijl Coosemans <tijl@FreeBSD.org>, ports@FreeBSD.org, arch@FreeBSD.org, Baptiste Daroussin <bapt@FreeBSD.org> Subject: Re: manpath change for ports ? Message-ID: <D6D673D7-A7FA-47C6-9E69-7E6BB8EB0791@FreeBSD.org> In-Reply-To: <861su6ont5.fsf@desk.des.no> References: <20170306235610.cmpxk27jhoafel6l@ivaldir.net> <86mvcvojzt.fsf@desk.des.no> <20170308204126.6d152c44@kalimero.tijl.coosemans.org> <861su6ont5.fsf@desk.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 9 Mar 2017, at 09:29, Dag-Erling Smørgrav <des@des.no> wrote: ... > 1) > > | I discovered that lang/gcc48 (and presumably the other gcc ports as > | well) not only have /usr/local/include in their default include path, > | but actually place it ahead of /usr/include. This is causing me no end > | of grief with software that uses iconv, because GNU libiconv's <iconv.h> > | f*s up your namespace so the build fails unless you explicitly link with > | GNU libiconv instead of using the libc version. [...] > > 2) > > | [...] I realized over the weekend that the > | situation is even worse than I initially thought. Basically, ports gcc > | is unusable for any other purpose than to build ports which don't > | support clang. Let me explain with a hypothetical scenario: > | > | You are developing a library which is important enough that you need to > | have the stable version installed on your development system. It is > | installed in /usr/local as usual. You've been working on fixing a bug, > | and have written a unit test which exercises the relevant code and > | verified that it can deterministically trigger the bug. You fix the bug > | and 'make check' again, all green. Then you clean out your working > | copy, re-run configure with CC=gcc and 'make check' again. Your tests > | fail. > | > | What happened is that when you built your code with gcc, the tests were > | linked and run with the stable version of the library, where the bug is > | not fixed. You can build with LDFLAGS=-L$(top_builddir)/lib, you can > | even specify the full path to the library in LDADD for each individual > | test, it doesn't matter. It will *always* pick the installed version > | first. The only way to get your tests to pass is to not have the > | library installed. Please pin this email for re-use the next time a discussion is started about adding /usr/local to the default include and library paths for the base system compiler... It's been more than a year now, so I expect it to be regurgitated any time soon. :) -Dimitry [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljBSrEACgkQsF6jCi4glqO4TgCdFuLXd4PMTuMXebe5Xsp7kCq+ sM0AnjCCTOAdqi5P9oGEcS8gYOmuxOlC =7qLs -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D6D673D7-A7FA-47C6-9E69-7E6BB8EB0791>