You mean setting rpath in LDFLAGS of PROJ or GDAL ?
CMake has a lot of tunings for RPATH, and some extra more for Mac :
CMAKE_INSTALL_RPATH, CMAKE_SKIP_RPATH,
CMAKE_INSTALL_RPATH_USE_LINK_PATH, MACOSX_RPATH etc. . Users might need
to tune them depending on their use cases. In
https://github.com/OSGeo/PROJ/commit/e1253e4b09d4260acc541acf15967356419197c9
that went to 9.0.0, we've removed most RPATH releated overrides to just
let CMake defaults, so users can tune them more freely.
Le 11/05/2022 à 02:59, Sean Gillies a écrit :
Explicitly setting rpath in LDFLAGS solved my PROJ 9 problem. This
feels like a regression. It isn't necessary for Linux and wasn't
necessary for autotools builds of PROJ 8.2.1.
Back on topic: GDAL 3.5.0rc4 seems fine.
On Tue, May 10, 2022, 4:18 PM Sean Gillies <[email protected]> wrote:
Thanks, Alan!
I feel like we're in the middle of going backwards to go forwards
when it comes to FOSS4G software builds.
On Tue, May 10, 2022 at 4:05 PM Alan Snow <[email protected]>
wrote:
This might be a helpful reference:
https://github.com/pyproj4/pyproj-wheels/issues/45
On Tue, May 10, 2022, 4:33 PM Even Rouault
<[email protected]> wrote:
Sean,
So your issue is with a GDAL autoconf build. I can't see
any significant changes in configure.ac
<http://configure.ac> between GDAL 3.5.0 and 3.4.0 related
to rpath. This has probably not changed in years. I do see
in your logs that the linking line of GDAL has a
-rpath /usr/local/lib
and that there's a /usr/local/lib/libproj.25.dylib file
But perhaps the issue is more with the PROJ CMake build
(hypothesis that you could check by testing with a PROJ
8.2.1 autoconf build) ? I don't know... Mac + rpath is
hostile territory for me.
Does running a GDAL binary, like gdalinfo, works before
using that delocate module ?
Yes 5413 is CMake specific.
Even
Le 10/05/2022 à 23:02, Sean Gillies a écrit :.
Hi Even,
I'm running into a problem with GDAL 3.5.0rc4 and PROJ
9.0.0 on macos. It occurs when I use
https://github.com/matthew-brett/delocate to relocate
GDAL and its dependencies into rasterio wheels.
The error:
ERROR:delocate.libsana:
@rpath/libproj.25.dylib not found:
Needed by: /usr/local/lib/libgdal.31.dylib
Search path:
ERROR:delocate.libsana:@rpath/libproj.25.dylib not found,
requested by /usr/local/lib/libgdal.31.dylib
Here is its context:
https://github.com/rasterio/rasterio-wheels/runs/6375882173?check_suite_focus=true#step:4:4025.
I searched the GDAL tracker for related issues and only
found https://github.com/OSGeo/gdal/issues/5413. It looks
like it could be related, but it also looks like the fix
is cmake specific and isn't available for autotools
builds. Is that correct?
On Tue, May 10, 2022 at 8:13 AM Even Rouault
<[email protected]> wrote:
Hi,
I've issued a rc4 with the following fixes w.r.t rc3:
* fix build error with CMake >= 3.10.2 and < 3.11
* fix build errors with Fedora mingw32
Updated archives:
https://download.osgeo.org/gdal/3.5.0/gdal-3.5.0rc4.tar.xz
https://download.osgeo.org/gdal/3.5.0/gdal-3.5.0rc4.tar.gz
https://download.osgeo.org/gdal/3.5.0/gdal350rc4.zip
Even
Le 06/05/2022 à 15:06, Even Rouault a écrit :
> Hi,
>
> I have prepared a GDAL/OGR 3.5.0 release candidate.
>
> NEWS at:
>
> https://github.com/OSGeo/gdal/blob/v3.5.0RC1/NEWS.md
>
> Note the first item about the new CMake build
system, and the
> deprecation of the autoconf & nmake build systems
that will be removed
> in GDAL 3.6.0
>
> Pick up an archive among the following ones (by
ascending size):
>
>
https://download.osgeo.org/gdal/3.5.0/gdal-3.5.0rc1.tar.xz
>
https://download.osgeo.org/gdal/3.5.0/gdal-3.5.0rc1.tar.gz
> https://download.osgeo.org/gdal/3.5.0/gdal350rc1.zip
>
> A snapshot of the gdalautotest suite is also
available :
>
>
https://download.osgeo.org/gdal/3.5.0/gdalautotest-3.5.0rc1.tar.gz
>
https://download.osgeo.org/gdal/3.5.0/gdalautotest-3.5.0rc1.zip
>
> A snapshot of the documentation is at:
>
> https://download.osgeo.org/gdal/3.5.0/gdal350doc.zip
>
> The GDAL-GRASS plugin sources and release process
has been moved to
> https://github.com/OSGeo/gdal-grass
>
> I'll call for a vote promoting it to next week if
no serious problems
> are reported before.
>
> The "release/3.5" branch has been created for all
bug fixes related to
> 3.5.x. master is now targetting 3.6.0dev.
>
> Best regards,
>
> Even
>
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
Sean Gillies
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
