Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#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)

main.log (325.1 KB) - added by sgrewe (Stefan Grewe) 6 years ago.
main.log
macports.conf (8.8 KB) - added by sgrewe (Stefan Grewe) 6 years ago.
macports.conf

Download all attachments as: .zip

Change History (12)

Changed 6 years ago by sgrewe (Stefan Grewe)

Attachment: main.log added

main.log

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.sdkpulseaudio: 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?

Changed 6 years ago by sgrewe (Stefan Grewe)

Attachment: macports.conf added

macports.conf

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 Changed 6 years ago by Ionic (Mihai Moldovan)

Cc: sgrewe removed
Resolution: invalid
Status: assignedclosed

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 in reply to:  8 ; 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.

Version 0, edited 6 years ago by jmroot (Joshua Root) (next)

comment:10 in reply to:  9 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.

Note: See TracTickets for help on using tickets.