Opened 4 years ago

Closed 4 years ago

#60835 closed defect (wontfix)

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

Reported by: krovetz (Ted Krovetz) Owned by:
Priority: Normal Milestone:
Component: ports Version: 2.6.2
Keywords: Cc: Dave-Allured (Dave Allured), cjones051073 (Chris Jones)
Port: gcc10 gcc9 gcc8 gcc7 gcc6 gcc5 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 gcc49 gcc-devel

Description

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.

Change History (11)

comment:1 Changed 4 years ago by Dave-Allured (Dave Allured)

Cc: Dave-Allured added

comment:2 Changed 4 years ago by 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...

comment:3 Changed 4 years ago by kencu (Ken)

Cc: cjones051073 added

comment:4 Changed 4 years ago by kencu (Ken)

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

comment:5 Changed 4 years ago by 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.

Last edited 4 years ago by kencu (Ken) (previous) (diff)

comment:6 Changed 4 years ago by kencu (Ken)

see also 52828

comment:8 Changed 4 years ago by kencu (Ken)

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

comment:9 Changed 4 years ago by kencu (Ken)

Port: gcc9 gcc8 gcc7 gcc6 gcc5 gcc43 gcc44 gcc45 gcc46 gcc47 gcc48 gcc48 gcc-devel added
Summary: gcc is configured to use ${prefix} for local include files, so /usr/local missing from gcc10 library and include search pathgcc is configured to use ${prefix} for local include files, so /usr/local missing from library and include search path

comment:10 Changed 4 years ago by kencu (Ken)

Port: gcc49 added

comment:11 Changed 4 years ago by kencu (Ken)

Resolution: wontfix
Status: newclosed

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.

Note: See TracTickets for help on using tickets.