On Wed, 12 Mar 2025, Roger Bivand wrote:
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 ...
The following tests FAILED:
40 - autotest_gdrivers (Failed)
43 - autotest_osr (Failed)
Errors while running CTest
and these are the tests patched in
https://github.com/OSGeo/gdal/commit/49ef64108b6875e5b90a4fb6cadd089e84fe53c1
- details added to gist.
The logic in CMakeLists.txt at line 371 looks OK:
if (NOT BUILD_SHARED_LIBS)
set(DEFAULT_EMBED_RESOURCE_FILES ON)
else()
set(DEFAULT_EMBED_RESOURCE_FILES OFF)
endif()
but in the default shared library case turns the embedding option on
silently.
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: roger.biv...@nhh.no
_______________________________________________
PROJ mailing list
PROJ@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/proj
