On Wed, 12 Mar 2025, Even Rouault wrote:
Roger,
good catch. Thanks for your patient testing. I could reproduce on a fresh
build directory when BUILD_SHARED_LIBS was not set at all. There was an
ordering issue between setting the default value of BUILD_SHARED_LIBS and
EMBED_RESOURCE_FILES that led EMBED_RESOURCE_FILES to be set to ON in that
situation.
Fixed per
https://github.com/OSGeo/PROJ/pull/4422
Thanks! Will try when RC3 is available.
Might the build-time embedded status of resource files perhaps be noted in
proj.pc?
Roger
Even
Le 12/03/2025 à 20:36, Roger Bivand a écrit :
On Wed, 12 Mar 2025, Roger Bivand wrote:
On Wed, 12 Mar 2025, Even Rouault wrote:
ok, on second thought, I figured the issue. I assume you have
statically
linked PROJ or have explicitly enabled EMBED_RESOURCE_FILES=ON when
building it (cf
https://proj.org/en/latest/install.html#cmdoption-arg-EMBED_RESOURCE_FILES).
At least I can reproduce those test failures with
EMBED_RESOURCE_FILES=ON.
In proj-9.6.0/build/CMakeCache.txt created by naked cmake .., I see:
//Whether resource files (limited to proj.db) should be embedded
// into the PROJ library
EMBED_RESOURCE_FILES:BOOL=ON
//Whether the PROJ_DATA_PATH should be embedded
EMBED_PROJ_DATA_PATH:BOOL=ON
//Directory that contains .tif, .json or .pol files to embed into
// libproj
EMBED_RESOURCE_DIRECTORY:PATH=
//Whether embedded resource files (limited to proj.db) should be
// used (should nominally be used together with EMBED_RESOURCE_FILES=ON,
// otherwise this will result in non-functional builds)
USE_ONLY_EMBEDDED_RESOURCE_FILES:BOOL=OFF
and lib contains only libproj.so.25.9.6.0 and its links, so not a static
build.
lib/libproj.so.25.9.6.0 is 14.9 MB
How did EMBED_RESOURCE_FILES get turned on by default, but with
USE_ONLY_EMBEDDED_RESOURCE_FILES off?
but no EMBED_RESOURCE_FILES entry at all in 9.5.1, which only has
//Whether the PROJ_DATA_PATH should be embedded
EMBED_PROJ_DATA_PATH:BOOL=ON
Trying again with 9.6.0 and
cmake -DEMBED_RESOURCE_FILES=OFF ..
gives
//Whether resource files (limited to proj.db) should be embedded
// into the PROJ library
EMBED_RESOURCE_FILES:BOOL=OFF
so trying to re-build everything - I don't use ccache, and am using
separate build directories, it'll take a little while.
lib/libproj.so.25.9.6.0 is 5.4 MB
Now rebuilding GDAL ...
Roger
Those tests aren't compatible with that configuration of PROJ. Ideally
we
should have some mechanism to skip them, but that would require that
PROJ
exposes how it has been built. In any case, this isn't something to
worry
about, just a testing issue.
Le 12/03/2025 à 18:53, Roger Bivand a écrit :
On Wed, 12 Mar 2025, Even Rouault wrote:
Le 12/03/2025 à 18:07, Roger Bivand a écrit :
On Wed, 12 Mar 2025, Even Rouault wrote:
unset PROJ_LIB ; ctest for example. Should I add the complete
output
of
running ctest to this thread (490 lines)?
maybe paste it some paste service (github gist, etc) and link it
to
it.
https://gist.github.com/rsbivand/09bd9e998889a44d2eecbb842c1a5168
sorry, no clue. I doubt this is 9.6.0 related
There are no such errors with PROJ 9.5.1 and GDAL 3.10.2 on the same
platform, so the only obvious change is building GDAL with 9.5.1 or
9.6.0RC2. That is why I waited, as the airport internet I was
depending
on
before I got to my desktop could have been a factor. For 9.5.1:
Start 35: test-osr-set-proj-search-paths
35/46 Test #35: test-osr-set-proj-search-paths ... Passed 0.12 sec
Start 40: autotest_gdrivers
40/46 Test #40: autotest_gdrivers ................ Passed 125.56 sec
Start 43: autotest_osr
43/46 Test #43: autotest_osr ..................... Passed 4.14 sec
Roger
--
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: [email protected]
_______________________________________________
PROJ mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/proj
