You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@sedona.apache.org by "mdsumner (via GitHub)" <gi...@apache.org> on 2026/10/03 21:41:22 UTC
[I] R: GDAL-backed RS_* functions fail with "dlsym failed" on a stock install; no sd_configure_gdal() (llm driven) [sedona-db]
mdsumner opened a new issue, #1395:
URL: https://github.com/apache/sedona-db/issues/1395
opening as I'd mentioned in a chat forum and had this material and failed to act on it until now @paleolimbot . Happy to pursue again, this is worked out with Claude - I haven't been active since finding this - but, I can revisit and and ensure the details are concrete soonish.
On a stock R install, any GDAL-backed raster function (`RS_FromPath`, `RS_AsRaster`, ...) plans fine but fails at execution with
```
Error: External error: Failed to load symbol GDALOpenEx: dlsym failed
```
<details>
<summary>Click to expand code or text</summary>
<html>
<body>
<!--StartFragment--><html><head></head><body><h1>R: GDAL-backed RS_* functions fail with "dlsym failed" on a stock install; no sd_configure_gdal()</h1>
<h2>Summary</h2>
<p>On a stock R install, any GDAL-backed raster function (<code>RS_FromPath</code>, <code>RS_AsRaster</code>, ...) plans fine but fails at execution with</p>
<pre><code>Error: External error: Failed to load symbol GDALOpenEx: dlsym failed
</code></pre>
<p>even when a system GDAL is installed. The R package has no equivalent of Python's <code>configure_gdal()</code> (it has <code>sd_configure_proj()</code> only), so there is no supported way to point it at a GDAL. A global <code>dyn.load()</code> of libgdal from R makes everything work, which indicates that symbol resolution is against the process's global symbol table rather than a library opened by name.</p>
<p>Net effect: the gap between <code>install.packages("sedonadb")</code> and a working <code>rs_frompath()</code> is currently several undocumented build steps plus an undocumented runtime workaround. The Python side has had <code>configure_gdal(preset=, shared_library=)</code> since the dynamic-GDAL change in 0.4.0; the R side did not get the matching hook.</p>
<h2>Environment</h2>
<ul>
<li>Image: <code>rocker/r-ver</code> (Ubuntu 24.04), R 4.6.1</li>
<li>sedonadb 0.4.1.9000 built from source via r-multiverse (r-universe manual built 2026-10-02 still lists only <code>sd_configure_proj()</code>)</li>
<li>Build-time deps that were needed and are not currently in the R install docs: Rust toolchain (rustup/cargo), curl, cmake, pkg-config, libgeos-dev</li>
<li>GDAL: Ubuntu <code>libgdal34t64</code> / <code>libgdal-dev</code> (GDAL 3.8.4)</li>
<li>Same failure reproduced on a separate image (gdal-r-ci) with a source-built GDAL 3.x, where gdalraster/terra/sf all work</li>
</ul>
<h2>Reproduction</h2>
<p>No data file needed; an inline VRT string serves as the reference raster.</p>
<pre><code class="language-r">library(sedonadb)
ref <- '<VRTDataset rasterXSize="400" rasterYSize="400"><GeoTransform>0,1,0,400,0,-1</GeoTransform><VRTRasterBand dataType="Byte" band="1"/></VRTDataset>'
q <- sprintf("
SELECT rs_asraster(
st_geomfromwkt('POLYGON((150 150, 220 260, 190 300, 300 220, 150 150))'),
rs_frompath('%s'),
'B', false, 230, 0, false
) AS rasterized_geom
", ref)
x <- sd_sql(q) # plans fine
x # execution fails
#> Error: External error: Failed to load symbol GDALOpenEx: dlsym failed
</code></pre>
<p>Results by condition (fresh session each):</p>
Condition | Result
-- | --
No libgdal installed | dlsym failed
apt install libgdal34t64 (runtime only: libgdal.so.34, no unversioned symlink) | dlsym failed
apt install libgdal-dev (adds unversioned libgdal.so) | dlsym failed
Either of the above plus dyn.load("/usr/lib/x86_64-linux-gnu/libgdal.so.34", local = FALSE) | works
<p>The <code>dyn.load()</code> can be done before the first raster call or after a failed one in the same session; the next call succeeds either way, so the symbol is re-resolved per call and nothing latches.</p>
<p>Working output (after the <code>dyn.load</code>):</p>
<pre><code><sedonab_dataframe: ?? x 1>
+-----------------------------+
| rasterized_geom |
| raster |
+-----------------------------+
| [400x400/1] @ [0 0 400 400] |
+-----------------------------+
Preview of up to 6 row(s)
</code></pre>
<h2>Diagnosis</h2>
<ul>
<li>The failure is at <code>dlsym</code>, not <code>dlopen</code>, and is unchanged by whether the unversioned <code>libgdal.so</code> exists, so the library is not being opened by name.</li>
<li>R loads package shared objects with <code>RTLD_LOCAL</code>, so a libgdal pulled in by sf, terra or gdalraster is present in the process but not visible to a global symbol lookup. Loading it with <code>RTLD_GLOBAL</code> (<code>dyn.load(..., local = FALSE)</code>) is exactly what makes it work.</li>
<li><code>LD_PRELOAD=/path/to/libgdal.so R</code> is the equivalent from the shell.</li>
<li>The same error message appears when no GDAL is installed at all, so a user cannot tell "GDAL missing" from "GDAL present but not visible".</li>
</ul>
<h2>Requests</h2>
<ol>
<li>Add <code>sd_configure_gdal(preset = , shared_library = )</code> mirroring <code>sd_configure_proj()</code> and Python's <code>configure_gdal()</code>. Given the per-call re-resolution above, it can be called at any time; it only needs to dlopen the library with <code>RTLD_GLOBAL</code> (or pass the handle to the Rust side).</li>
<li>Have an "auto"/"system" preset try to dlopen <code>libgdal.so</code> / <code>libgdal.so.NN</code> by name so a distro GDAL works without any call, as the Python package does at import.</li>
<li>Replace the raw <code>dlsym failed</code> message with something like "GDAL is not configured; call sd_configure_gdal()".</li>
<li>Document the source-build dependencies (Rust toolchain, cmake, pkg-config, libgeos-dev, curl) in the R install docs, since r-multiverse currently delivers a source package on this platform.</li>
</ol>
<h2>Related (positive) finding</h2>
<p><code>RS_FromPath</code> accepts an inline <code><VRTDataset></code> XML string, which gives a zero-byte reference grid for <code>RS_AsRaster</code> with no data file. Since SedonaDB has no <code>RS_MakeEmptyRaster</code>, this may be a useful basis for a grid-spec helper; raised separately in the discussion forum.</p></body></html><!--EndFragment-->
</body>
</html>
</details>
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sedona.apache.org.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] R: GDAL-backed RS_* functions fail with "dlsym failed" on a stock install; no sd_configure_gdal() (llm driven) [sedona-db]
Posted by "james-willis (via GitHub)" <gi...@apache.org>.
james-willis commented on issue #1395:
URL: https://github.com/apache/sedona-db/issues/1395#issuecomment-5974167503
> SedonaDB has no RS_MakeEmptyRaster
MakeEmptyRaster should release in 0.5.0 including a geom overload to give extent.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sedona.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] R: GDAL-backed RS_* functions fail with "dlsym failed" on a stock install; no sd_configure_gdal() (llm driven) [sedona-db]
Posted by "mdsumner (via GitHub)" <gi...@apache.org>.
mdsumner commented on issue #1395:
URL: https://github.com/apache/sedona-db/issues/1395#issuecomment-5974372532
Ah indeed I knew that, apologies - this material predates that request
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sedona.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [I] R: GDAL-backed RS_* functions fail with "dlsym failed" on a stock install; no sd_configure_gdal() (llm driven) [sedona-db]
Posted by "paleolimbot (via GitHub)" <gi...@apache.org>.
paleolimbot closed issue #1395: R: GDAL-backed RS_* functions fail with "dlsym failed" on a stock install; no sd_configure_gdal() (llm driven)
URL: https://github.com/apache/sedona-db/issues/1395
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@sedona.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org