<div dir="ltr"><div><br></div><div><br></div>For my weird google production setup: I haven't heard of any bugs along those lines. I only build cs2cs and gie for running tests and users have no access to any of the proj binaries in production. I don't think folks do much with sqlite (most db usage are things like Spanner or FireBase) and most proj usage is pretty boring.<div><br></div><div>If they need them, they get them through debian on their desktops or whatever cloud container they might use if they are allowed to do that, but not in the normal production environment.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 3, 2024 at 10:30 AM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
I've now a PROJ branch with proj.db embedding working at <br>
<a href="https://github.com/OSGeo/PROJ/pull/4265" rel="noreferrer" target="_blank">https://github.com/OSGeo/PROJ/pull/4265</a>. And contrary to the current <br>
wording of the RFC text, I've actually invested in making it work with <br>
non-C23 compilers too (C23 mechanism used when available), by adapting <br>
<a href="https://gitlab.com/jhamberg/cmake-examples/-/blob/master/cmake/FileEmbed.cmake" rel="noreferrer" target="_blank">https://gitlab.com/jhamberg/cmake-examples/-/blob/master/cmake/FileEmbed.cmake</a> <br>
and optimizing it because its performance at generating a .c file from a <br>
binary was not acceptable on multi-megabyte large files like proj.db.  <br>
Non-C23 embedding works fine with older gcc, clang, MSVC. The proj_db.c <br>
generation from proj.db runs in 8 seconds, and building it with gcc in <br>
18 seconds (looking at build times in CI, that seems to be fast with <br>
MSVC too)<br>
<br>
But I won't (probably) support non-C23 embedding for GDAL: that would be <br>
too much complication w.r.t benefit. Only a "few" GDAL drivers need <br>
resource files, whereas access to proj.db is a strong requirement.<br>
<br>
Kurt, I had to modify the memOpen() and the memvfs_init() functions of <br>
the <a href="https://www.sqlite.org/src/doc/tip/ext/misc/memvfs.c" rel="noreferrer" target="_blank">https://www.sqlite.org/src/doc/tip/ext/misc/memvfs.c</a> (I did other <br>
changes in memvfs_init() to avoid making it the default VFS, and <br>
registering it per db-connection to avoid a global registration), <br>
otherwise some complex SQL requests that require creating a temporary <br>
file wouldn't work, such as the ones of 'bin/projinfo --list-crs' or <br>
'bin/cct "this is a bogus CRS meant to trigger a syntax error in <br>
proj_create"'  (with sqlite 3.46 of fedora:rawhide). Is it something you <br>
ran into? Cf the changes in memvfs.c in <br>
<a href="https://github.com/rouault/PROJ/commit/e7fcf162f6968c48587836f537b506708112e7d4" rel="noreferrer" target="_blank">https://github.com/rouault/PROJ/commit/e7fcf162f6968c48587836f537b506708112e7d4</a><br>
<br>
With those changes, ctest pass<br>
<br>
Even<br>
<br>
<br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
<br>
</blockquote></div>