Doc: building_from_source.rst: add a 'Typical build issues' paragraph, initiated with PROJ related issues (fixes #7248) #7250
Conversation
| Typical build issues | ||
| ++++++++++++++++++++ | ||
|
|
||
| How do I get PROJ ? |
There was a problem hiding this comment.
This may fit more naturally in dev_environment.rst
There was a problem hiding this comment.
I'm not sure. dev_environment has this connotation this is for people who want to modify GDAL, but here it is problems for people who just want to build GDAL for use
There was a problem hiding this comment.
Maybe a better name for that page is "Setting up a build environment" ?
There was a problem hiding this comment.
indeed. I'll change that in an extra commit
There was a problem hiding this comment.
hum actually not, the content is rather dev oriented, with Vagrant, git, etc. Hard to organize properly! And difficult to draw the line between "user just compiling GDAL to use it because not happy with existing packages" and "developer wanting to hack in GDAL"
…, initiated with PROJ related issues (fixes OSGeo#7248)
| For Linux based systems, given that C API/ABI has been preserved in the | ||
| PROJ 6, 7, 8, 9 series, if the custom PROJ build is more recent than the | ||
| PROJ used by those other libraries, doing aliases of the older ``libproj.so.XX`` | ||
| name to the newer ``libproj.so.YY`` (with ``ln -s``) should work, although it is | ||
| definitely not recommended to use this solution in a production environment. |
There was a problem hiding this comment.
Is the API/ABI also complete if the new newer build has less features (CURL, TIFF) than the older one?
There was a problem hiding this comment.
good question. The answer is yes. TIFF presence/absence has no impact on API. And CURL one either, because networking capabilities can be present even if CURL isn't enabled, because the user can pass its own networking capable callbacks
No description provided.