Opened 13 months ago
Closed 2 weeks ago
#68655 closed defect (fixed)
gdal @3.7.3: Build failure when /Library/Frameworks/rasterlite2.framework exists
Reported by: | guidod0 | Owned by: | Veence (Vincent) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | |
Keywords: | Cc: | nilason (Nicklas Larsson), cooljeanius (Eric Gallager), Dave-Allured (Dave Allured) | |
Port: | gdal |
Description (last modified by ryandesign (Ryan Carsten Schmidt))
I believe the issue comes from the fact that there is no gdal-3.7.3 for darwin_23.arm64 but would like help in understanding when it may become available.
The first error comes from
:info:archivefetch ---> gdal-3.7.3_1+postgresql15+proj9.darwin_23.arm64.tbz2 doesn't seem to exist in /opt/local/var/macports/incoming/verified :msg:archivefetch ---> Attempting to fetch gdal-3.7.3_1+postgresql15+proj9.darwin_23.arm64.tbz2 from https://packages.macports.org/gdal :debug:archivefetch Fetching archive failed: The requested URL returned error: 404 :msg:archivefetch ---> Attempting to fetch gdal-3.7.3_1+postgresql15+proj9.darwin_23.arm64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/gdal :debug:archivefetch Fetching archive failed: The requested URL returned error: 404 :msg:archivefetch ---> Attempting to fetch gdal-3.7.3_1+postgresql15+proj9.darwin_23.arm64.tbz2 from http://mirror.fcix.net/macports/packages/gdal :debug:archivefetch Fetching archive failed: The requested URL returned error: 404 :debug:archivefetch Privilege de-escalation not attempted as not running as root.
Attachments (1)
Change History (13)
comment:1 Changed 13 months ago by guidod0
Description: | modified (diff) |
---|
Changed 13 months ago by guidod0
comment:2 follow-up: 4 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)
Description: | modified (diff) |
---|---|
Summary: | gdal fails to build on MacOS Sonoma arm64 → gdal @3.7.3: Build failure when /Library/Frameworks/rasterlite2.framework exists |
comment:3 Changed 13 months ago by ryandesign (Ryan Carsten Schmidt)
Cc: | nilason added |
---|---|
Owner: | set to Veence |
Status: | new → assigned |
comment:4 Changed 13 months ago by guidod0
Thanks! Followed the FAQ and temporarly renamed the Framework, used sudo port clean gdal, and the build was successful.
Replying to ryandesign:
A missing binary archive is never the cause of a build failure.
The log shows the real problem was:
:info:build ld: file cannot be mmap()ed, errno=22 path=/Library/Frameworks/rasterlite2.framework in '/Library/Frameworks/rasterlite2.framework'Having software installed in /Library/Frameworks or /usr/local can interfere with MacPorts. See wiki:FAQ#libraryframeworks. While this problem should be fixed here if possible, I recommend removing what you have installed in /Library/Frameworks and /usr/local to avoid further problems. If you do that,
sudo port clean gdal
before trying to build it again.
comment:5 Changed 4 months ago by cooljeanius (Eric Gallager)
Cc: | cooljeanius added |
---|
comment:6 Changed 3 weeks ago by Dave-Allured (Dave Allured)
Cc: | Dave-Allured added |
---|
comment:8 Changed 3 weeks ago by ryandesign (Ryan Carsten Schmidt)
Per the duplicate, the gdal port should either add a dependency on librasterlite2 or should change -DGDAL_ENABLE_DRIVER_RASTERLITE=ON
to -DGDAL_ENABLE_DRIVER_RASTERLITE=OFF
. Either way, the revision
should increase.
comment:9 Changed 3 weeks ago by Dave-Allured (Dave Allured)
PR #26415 submitted. Decided to add a hard dependency, rather than an optional variant. Port librasterlite2
seems to build okay, not problematical.
comment:10 follow-up: 11 Changed 3 weeks ago by Dave-Allured (Dave Allured)
It remains unclear to me whether adding the dependency would fix the original complaint, specifically broken build when the framework within /Library is active. If the added Macports port gets searched ahead of the framework, then yes, this will fix everything. That is what I am hoping for.
Yes, having the active framework is still an illegal condition, not really Macports' responsibility.
comment:11 Changed 3 weeks ago by cooljeanius (Eric Gallager)
Replying to Dave-Allured:
It remains unclear to me whether adding the dependency would fix the original complaint, specifically broken build when the framework within /Library is active. If the added Macports port gets searched ahead of the framework, then yes, this will fix everything. That is what I am hoping for.
Yes, having the active framework is still an illegal condition, not really Macports' responsibility.
The fix for #37341 ought to cause the MacPorts dependency to get picked up ahead of the framework in the /Library directory.
comment:12 Changed 2 weeks ago by nilason (Nicklas Larsson)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
A missing binary archive is never the cause of a build failure.
The log shows the real problem was:
Having software installed in /Library/Frameworks or /usr/local can interfere with MacPorts. See wiki:FAQ#libraryframeworks. While this problem should be fixed here if possible, I recommend removing what you have installed in /Library/Frameworks and /usr/local to avoid further problems. If you do that,
sudo port clean gdal
before trying to build it again.