Closed Laurent-777 closed 2 years ago
if you want the RPATH to be set on installed binaries, you may need to pass the -DGDAL_SET_INSTALL_RELATIVE_RPATH=ON option to CMake
See https://gdal.org/build_hints.html#cmdoption-arg-GDAL_SET_INSTALL_RELATIVE_RPATH
OK. I guess I will try it this weekend. Besides, please note that almost all my softwares, including thirdparties ones, are not in a standard location, namely, not in /usr/local. Thank you very much. Kind regards,
Hi 👍 I tried it this morning, as indicated. Nevertheless, it fails again. Now, gdalinfo - - formats asks the proj library, and probably the other dependent ones Gdal needs. I guess one may set or find DYLD_LIBRARY_PATH. Besides, this version of Gdal is compiled and installed correctly, as for previous versions.
Note : curl provided by Apple (Lion) makes the compilation failing with this version. The curl version I compiled is OK. Same remark with Sqlite (and Spatialite), recent versions. Eventually, Java fails make to compile : but I am not using Java. As with C++, I do not use these programming languages. In fact. I use Objective-C, sometimes Fortran, and I probably will investigate D, Go, possibly one or more others.
Kind regards,
Hi : Same error with autotools (after having run autogen.sh). I will try to find what differs from versions previous to v. 3.5.x. Probably with diff.
Kind regards,
Hi : I guess I found what matters. Hereafter what I did for. I used autotools and I changed the Proj configuration from Proj9 to Proj6. I run autogen.sh then configure and make etc. With proj6, gdalinfo - - formats gave the appropriate information (but one format maybe, as for the most recent gdal versions). So, up to proj6, it works. I have not tested with proj7 and proj8. First task I will do, is to test with Cmake, and proj6. If I have time, testing with proj7 and proj8. However, please note that I am very late in my work, due to many bugs I found elsewhere, I fix step by step. So, it seems this is a proj bug.
Kind regards, Encl. Log files as earlier.
Hi : Hereafter, enclosed PDF file from ADC (Apple Developer Community). Kind regards,
Laurent D.
Encl. 2 Dynamic Library Programming Topics (2006-11-07).pdf Framework Programming Guide (2006-11-07).pdf
Hi !
Hereafter my progress to find what matters. First, PROJ7, 8, and 9 issues failure to find the dynamic libaries.
Now, I found other bugs. First, libzstd makes fail GDAL (version investigated). Enclosed the log files just herefater. Remember that all my softwares developed or compield are NOT in a standard location (namely, /usr/local) andare in an external hard drive. So, I can check everything. config.log my-configure.log my-gdal-formats.log my-install.log my-make.log my-python-autotest.log
Now a geos/spatailite error (NB I remember that the spatialite team doesn't advise to compile spatialite with Geos). Hereafter too, log files enclosed. config.log my-configure.log my-gdal-formats.log my-install.log my-make.log my-python-autotest.log
Next, CFITSIO issues an error too.
Compiled with autotools too as before. Encl. config.log my-configure.log my-gdal-formats.log my-install.log my-make.log my-python-autotest.log
GEOS error... Encl config.log my-configure.log my-gdal-formats.log my-install.log my-make.log my-python-autotest.log
The basis configuration that makes the compilation OK. Encl. config.log my-configure.log my-gdal-formats.log my-install.log my-make.log my-python-autotest.log
Before, the compilations were made with PROJ.6x. Besides, I invetsigated the PROJ sensitivity. Here with PROJ.7. gdalinfo --formats failed... Encl. config.log my-configure.log my-gdal-formats.log my-install.log my-make.log my-python-autotest.log
Now with PROJ.8... Encl. config.log my-configure.log my-gdal-formats.log my-install.log my-make.log my-python-autotest.log
And PROJ.9 as indicated earlier... That's all for today. If I have time, I will compile GDAL 3.5.0.3 with CMake AND Proj.6.x.
Kind regards, config.log my-configure.log my-gdal-formats.log my-install.log my-make.log my-python-autotest.log
Encl.
(NB I remember that the spatialite team doesn't advise to compile spatialite with Geos)
What do you mean with this? Many of the SpatiaLite functions depend on GEOS https://www.gaia-gis.it/gaia-sins/spatialite-sql-latest.html and I think that it is rather uncommon to make builds without those.
I'm closing this as I suspect it might be setup specific. I'd note also that OS X Lion is quite old, but I'm not sure this is the issue here
Fixed : When built with the autotools, works with PROJ 6.3.x but not with PROJ 7 and PROJ 8 (in a "as is" devlopment manner). Seems to be OK with PROJ 9 (not sure 100%... but it seems it was fixed with PROJ 9). For THIS version of GDAL, it works. gdal-info --formats gives the formats used and, integrated in a GIS software, I opened raster data easily. It is a PROJ issue first.
Kind regards,
Laurent Delphin
Please kindly see
Please kindly see this :
gdalinfo - -formats not running anymore even though gdal 3.5.0.3 seems to be installed correctly. -->
Expected behavior and actual behavior.
1/ gdalinfo - - formats returns the formats 2/ no dynamic library (gdal, third parties) is referenced anymore since Cmake, but previous versions work.DYLD_LIBRARY_PATH is not set anymore with Cmake.
Steps to reproduce the problem
gdalinfo - - formats doesn't find the gdal library and other ones such as proj (NB Proj. 9 was used and seems to "work").
Operating system
Mac mini Intel core 2 duo Mac os x lion Gnu gcc 4.9.4(to be confirmed) built with my Mac.
GDAL version and provenance
3.5.0.3 (in fact, even not yest tested, it should be the same with 3.5.0.x, 3.5.y.x maybe).
Kind regards,