Opened 6 years ago
Closed 6 years ago
#57028 closed defect (fixed)
appstream-glib @0.7.12: Include dir /usr/include/uuid does not exist
Reported by: | chicagotripp (Altoine Barker) | Owned by: | dbevans (David B. Evans) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.5.99 |
Keywords: | mojave | Cc: | chicagotripp (Altoine Barker), captainproton1971 (Captain Proton), amake (Aaron Madlon-Kay), MaddTheSane (C.W. Betts), ryandesign (Ryan Carsten Schmidt) |
Port: | appstream-glib |
Description
I am running Mojave OS 10.14 Beta (18A371a). Using port version 2.5.99. I am trying to install gimp2-devel +quartz and I receive the following error building appstream-glib @0.7.12:
Build machine cpu family: x86_64 Build machine cpu: x86_64 meson.build:52:0: ERROR: Include dir /usr/include/uuid does not exist. A full log can be found at /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_appstream-glib/appstream-glib/work/build/meson-logs/meson-log.txt Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_appstream-glib/appstream-glib/work/appstream-glib-0_7_12" && /opt/local/bin/meson --prefix=/opt/local -Drpm=false /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_appstream-glib/appstream-glib/work/appstream-glib-0_7_12 /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_appstream-glib/appstream-glib/work/build Exit code: 1 Error: Failed to configure appstream-glib: configure failure: command execution failed DEBUG: Error code: NONE DEBUG: Backtrace: configure failure: command execution failed while executing "$procedure $targetname" Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_devel_appstream-glib/appstream-glib/main.log for details. Error: Follow https://guide.macports.org/#project.tickets to report a bug. Error: Processing of port gimp2-devel failed
I am including the main.log.
Attachments (2)
Change History (16)
Changed 6 years ago by chicagotripp (Altoine Barker)
comment:1 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | dbevans removed |
---|---|
Keywords: | mojave added |
Owner: | set to dbevans |
Status: | new → assigned |
Summary: | appstream-glib @0.7.12 build config failure → appstream-glib @0.7.12: Include dir /usr/include/uuid does not exist |
comment:2 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
I wonder if the problem is specific to this port, or whether it also affects other ports that build with meson. Can you try some others? Use port echo depends:meson
to see a list of such ports.
comment:3 Changed 6 years ago by chicagotripp (Altoine Barker)
I have no /usr/include directory. This is what I have when I view the directory (ls /usr ):
$ls /usr/ X11 lib local share bin libexec sbin standalone
If I run which uuid, I get:
$which uuid /opt/local/bin/uuid
I have followed your suggestion and installed two ports (gcab and urbit) that depend on Meson with no problems.
comment:4 Changed 6 years ago by chicagotripp (Altoine Barker)
I have looked over the error message and it seems to be that the patch use-system-uuid.patch implicitly points uuid to use directory /usr/include/uuid.
Is this directory present on OS versions earlier than MojaveOS? Otherwise, should there be a script to use /opt/local/bin/uuid which my port says is provided by ossp-uuid?
Google search shows that this hasn't been in the MacOSX since El Capitan or Yosemite without XCode6.1. I found the file under the Xcode Developer tools directory located at /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/.
Notice that the latest MacOS 10.14 SDK has the Xcode-beta.app when in the past it was Xcodebeta.app .
Should the patch then check for or point to the MacOS SDK path when /usr/include/ is not present?
I see if you look at line 52 in the file meson.build shows:
uuid_inc = include_directories('/usr/include/uuid')
When I inserted /Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include/uuid in place of /usr/include/uuid this completes and fully installs. Recap: I changed line 52 to now show:
uuid_inc = include_directories('/Applications/Xcode-beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/includ/uuid')
comment:5 Changed 6 years ago by captainproton1971 (Captain Proton)
Cc: | captainproton1971 added |
---|
comment:6 Changed 6 years ago by captainproton1971 (Captain Proton)
Having the same issue, however line 52 of the file meson.build shows me something different:
uuid = dependency('uuid')
so I'm not sure where to make the suggested edit. This is preventing gimp from building for me.
comment:7 Changed 6 years ago by amake (Aaron Madlon-Kay)
Cc: | amake added |
---|
comment:8 Changed 6 years ago by MaddTheSane (C.W. Betts)
Apple seems to have moved the include directory to /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include.
comment:9 Changed 6 years ago by MaddTheSane (C.W. Betts)
Cc: | MaddTheSane added |
---|
comment:10 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
The change in Mojave is that the command line tools no longer also install a copy of the headers at /usr/include. We would like ports to adapt to this change, because although there is a method to get /usr/include on Mojave, we don't want users to have to do that, since it's clearly Apple's intention to deprecate this directory.
The appstream-glib port has forced the use of /usr/include/uuid since [5fda12f80c85e7d09ffdaaa494491c22ccbdec2d/macports-ports] but no explanation for this change was given. I tried removing that and building it with ossp-uuid instead, but the build failed. Maybe that's why it wasn't used before.
I've asked the developers of appstream-glib to support ossp-uuid.
comment:11 follow-up: 12 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Alternately we could make appstream-glib use the libuuid port. That builds, however libuuid and ossp-uuid currently conflict, and nothing in MacPorts currently uses libuuid; everything that needs uuid support uses ossp-uuid. So if we want appstream-glib to use libuuid, we either have to make the two ports not conflict, or we have to switch all ports that use ossp-uuid to use libuuid (and it's not clear that all such ports would be compatible with that).
From what I've read, ossp-uuid is more common on BSD systems (macOS is derived from BSD), while libuuid is included with Linux so it is more popular there. However, /usr/include/uuid/uuid.h seems to be an earlier version of the uuid.h that's part of the libuuid port, while ossp-uuid's uuid.h seems unrelated. Maybe that speaks for switching MacPorts uuid use from ossp-uuid to libuuid.
ossp-uuid is also older, having had its most recent release in 2008, while libuuid's most recent release was in 2014, in case that informs our decision.
comment:12 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to ryandesign:
I've asked the developers of appstream-glib to support ossp-uuid.
The developers have declined to do this.
Replying to ryandesign:
Alternately we could make appstream-glib use the libuuid port. That builds, however libuuid and ossp-uuid currently conflict, and nothing in MacPorts currently uses libuuid; everything that needs uuid support uses ossp-uuid. So if we want appstream-glib to use libuuid, we either have to make the two ports not conflict, or we have to switch all ports that use ossp-uuid to use libuuid (and it's not clear that all such ports would be compatible with that).
I'll see what we can do about this.
comment:13 Changed 6 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | ryandesign added |
---|
comment:14 Changed 6 years ago by dbevans (David B. Evans)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
Replying to chicagotripp:
Please attach this file too.