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
--Apple-Mail=_158C0438-7EB6-4369-B706-5BA4441CF800 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 9 Mar 2017, at 09:29, Dag-Erling Sm=C3=B8rgrav <des@des.no> wrote: ... > 1) >=20 > | 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. [...] >=20 > 2) >=20 > | [...] 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=3Dgcc 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=3D-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 --Apple-Mail=_158C0438-7EB6-4369-B706-5BA4441CF800 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.30 iEYEARECAAYFAljBSrEACgkQsF6jCi4glqO4TgCdFuLXd4PMTuMXebe5Xsp7kCq+ sM0AnjCCTOAdqi5P9oGEcS8gYOmuxOlC =7qLs -----END PGP SIGNATURE----- --Apple-Mail=_158C0438-7EB6-4369-B706-5BA4441CF800--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?D6D673D7-A7FA-47C6-9E69-7E6BB8EB0791>