#57712 closed defect (invalid)
pulseaudio: using incorrect sysroot
| Reported by: | sgrewe (Stefan Grewe) | Owned by: | Ionic (Mihai Moldovan) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 2.5.4 |
| Keywords: | mojave | Cc: | sgrewe (Stefan Grewe) |
| Port: | pulseaudio |
Description
New Macbook pro
migrated with migration assistant
uninstalled macports
installed xcode 10.1
installed command line tools
reinstalled macports
port install pulseaudio fails because CFLAGS is missing SDK
Attachments (2)
Change History (12)
Changed 6 years ago by sgrewe (Stefan Grewe)
comment:1 Changed 6 years ago by sgrewe (Stefan Grewe)
| Cc: | sgrewe added |
|---|
comment:2 Changed 6 years ago by jmroot (Joshua Root)
| Keywords: | mojave added |
|---|---|
| Owner: | changed from < default >, ionic to Ionic |
| Summary: | CFLAGS is missing -isysroot/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk → pulseaudio: using incorrect sysroot |
The configure script is being called with this argument in your log:
--with-mac-sysroot=/
I can't reproduce that. For me on 10.14 it's using
--with-mac-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
which makes sense looking at what the Portfile does.
Apparently configure.sdkroot is empty for you. Do you have any SDK-related options set in macports.conf? Does /usr/include exist on your system?
comment:3 Changed 6 years ago by sgrewe (Stefan Grewe)
On the old macbook it's also using
--with-mac-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
I did not change macports.conf, see attached
/usr/include exists, but again, same as on the old machine, where it's working
I now deleted the contents of /usr/include, tried again
port clean --all pulseaudio port install pulseaudio
but still the same result
comment:4 Changed 6 years ago by sgrewe (Stefan Grewe)
How can I check that macports sees the command line tools?
comment:5 Changed 6 years ago by sgrewe (Stefan Grewe)
Obviously
configure.sdkroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
in the portfile solves the problem, but what is the root cause?
comment:6 Changed 6 years ago by jmroot (Joshua Root)
If /usr/include exists, it is assumed to contain a working set of system headers and an SDK is not used. The code that sets the default value of configure.sdkroot is here: https://github.com/macports/macports-base/blob/v2.5.4/src/port1.0/portconfigure.tcl#L401
comment:7 Changed 6 years ago by kencu (Ken)
So Stefan, it looks like if instead of deleting the contents of /usr/include, if just delete /usr/include completely, you should be OK.
comment:8 follow-up: 9 Changed 6 years ago by Ionic (Mihai Moldovan)
| Cc: | sgrewe removed |
|---|---|
| Resolution: | → invalid |
| Status: | assigned → closed |
Why would one delete /usr/include in the first place?
In any case, there's nothing to do on the port (or base) side here, so closing up.
If an sdkroot is set up correctly (manually or automatically through base), it's getting used, otherwise the root is set to /, which is fine.
Btw: you do not need to CC yourself if you are the reporter.
comment:9 follow-up: 10 Changed 6 years ago by jmroot (Joshua Root)
Replying to Ionic:
Why would one delete /usr/include in the first place?
It normally doesn't exist on Mojave. There is an extra installer included in the command line tools which will install it though, and some users have used it.
comment:10 Changed 6 years ago by Ionic (Mihai Moldovan)
| Cc: | sgrewe added |
|---|
Replying to jmroot:
Replying to Ionic:
Why would one delete /usr/include in the first place?
It normally doesn't exist on Mojave. There is an extra installer included in the command line tools which will install it though, and some users have used it.
Does that mean that base now has to check whether /usr/include is empty and set configure.sdkroot appropriately to an SDK path and we have a general bug here? If we already check for the presence of /usr/include (and unless Apple installs a stub empty directory by default to preserve the hierarchy), the only way this could go wrong is if users delete the directory contents manually or uninstall the package, without the installer removing the directory.
Btw: you do not need to CC yourself if you are the reporter.
This is no longer necessarily the case: users can change their notification preferences such that they will not be notified for tickets that they reported unless they are also in Cc.
Ah, must have missed that. Okay then, ignore that comment. Re-adding to CC list.
main.log