gcc is configured to use ${prefix} for local include files, so /usr/local missing from library and include search path

[krovetz (Ted Krovetz)]

Xcode's clang lists /usr/local on the default search path while gcc10 does not. For example:

icelake> clang -Xlinker -v
<snip>
Library search paths:
	/usr/local/lib
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
	/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/

but gcc10 does not

icelake> gcc-mp-10 -Xlinker -v 
<snip>
Library search paths:
	/opt/local/lib/gcc10/gcc/x86_64-apple-darwin19/10.1.0
	/opt/local/lib/gcc10
	/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/lib
Framework search paths:
	/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/

Same goes for include search paths

icelake> gcc-mp-10 -x c -v -E /dev/null 
<snip>
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/lib/gcc10/gcc/x86_64-apple-darwin19/10.1.0/include
 /opt/local/lib/gcc10/gcc/x86_64-apple-darwin19/10.1.0/include-fixed
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include
 /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks
End of search list.
icelake> clang -x c -v -E /dev/null
<snip>
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.3/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.

[kencu (Ken)]

we have gcc specifically configured to do this on purpose:

--with-local-prefix=/opt/local

See <​https://gcc.gnu.org/install/configure.html>.

I suppose we could debate why that is -- none of the clangs are built that way, and we pass -I${prefix}/include all the time anyway, or else the clang's would not work.

Dunno who decided we needed to do this, or how many years ago that happened...

[kencu (Ken)]

Chris - thoughts? I don't know why we do this at present. Seems unnecessary to me at first glance.

[kencu (Ken)]

well this goes back forever on MacPorts, right to the beginning of gcc-4.3 <​https://github.com/macports/macports-ports/blob/b707f6f84a8207ed7ba244ddbfd827f4431b0695/lang/gcc43/Portfile>

It was probably done to be "helpful" and avoid pulling in anything in /usr/local while automatically including everything in /opt/local.

In fact, it probably made it much easier to use MacPorts with other non-macports software as the macports tree in /opt/local was automatically included.

But it is different than how clang has been configured, certainly, and that is not ideal. In a way, it's a shame we can't change our clang builds to do this too, but that would make them too different than xcode clangs.

I'm not overly inclined to change this just now...how many things might break? Every gcc would need to be rebuilt, and some software that links properly now might build differently.

You can pass /usr/local in yourself, of course, if you want to build and link against software in there.

[kencu (Ken)]

see also 52828

[kencu (Ken)]

relevant <​https://gcc.gnu.org/legacy-ml/gcc-patches/2016-11/msg00521.html>

[kencu (Ken)]

So this (somewhat odd) method of configuring gcc goes back to ancient times, at least a decade <​https://github.com/macports/macports-ports/blame/master/lang/gcc45/Portfile>.

Who knows how many of the 20,000 ports might now rely on this behaviour? And, it does help keep errors from coming into builds by accidentally picking things up in /usr/local.

So I'm going to close this is a "wontfix" as this is -- for MacPorts, at least -- expected and planned and desired behaviour.