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)
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.
comment:7 Changed 4 years ago by kencu (Ken)
comment:8 Changed 4 years ago by kencu (Ken)
Summary: | /usr/local missing from gcc10 library and include search path → gcc 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 path → gcc 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: | new → closed |
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.
we have
gcc
specifically configured to do this on purpose: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...