ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory
| Task Info (Flyspray) | |
|---|---|
| Opened By | Thomas (thomastc) |
| Task ID | 75749 |
| Type | Bug Report |
| Project | Community Packages |
| Category | Packages |
| Version | None |
| OS | All |
| Opened | 2022-08-30 13:50:59 UTC |
| Status | Assigned |
| Assignee | Jaroslav Lichtblau (Dragonlord) |
| Assignee | Bruno Pagani (ArchangeGabriel) |
Details
Version: gdal 3.5.1-2
Description:
If the optional arrow package is not installed, any use of the GDAL library spits out this error: ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory The message seems to be harmless, but is a bit annoying.
It's not clearly documented, but I would assume that building with -DGDAL_USE_ARROW=ON makes arrow a required dependency. So maybe the fix is as simple as moving it from optdepends to depends.
But if -DGDAL_USER_ARROW=ON merely adds support for arrow if it's found at runtime, then this would be an upstream bug.
Steps to reproduce:
Run ogr2ogr without arguments.
$ ogr2ogr ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory Usage: ogr2ogr [--help-general] [-skipfailures] [-append] [-update] ...
Activity
added priority3-normal scopebug severity4-low statusconfirmed labels
Added 2022-08-30 22:16:41 UTC - Commented by Toolybird (Toolybird)
The arrow driver clearly fits our definition of optdepends [1]. Upstream also mention it as optional [2]. The errors should probably be suppressed, so this looks like an upstream issue. Please get back in touch if a compilation option has been missed or more info comes to light etc.
[1] https://wiki.archlinux.org/title/PKGBUILD#optdepends [2] https://github.com/OSGeo/gdal/blob/v3.5.1/NEWS.md#new-optional-dependencies
Added 2022-08-31 20:37:29 UTC - Commented by Thomas (thomastc)
Upstream GDAL determined that it's not an upstream issue: https://github.com/OSGeo/gdal/issues/6281 The "optional" part is about being optional at compile time, but if enabled, it's expected to be there at run time.
Not sure what the best way is to proceed. I actually had all optional dependencies except arrow installed, and found only two that I could remove without cascading uninstalls, so most of these optional deps seem to be pretty common, so it might not hurt too much to make them required?
Alternatively, these driver plugins (see /usr/lib/gdalplugins) could be packaged separately, each with a hard dependency on gdal and their respective third-party library. That might be the more in line with The Arch Way of doing things.
Added 2022-09-02 08:04:22 UTC - Commented by plasmoid (plasmoid)
Similar for the podofo optdepend:
gdalinfo
ERROR 1: libpodofo.so.0.9.8: cannot open shared object file: No such file or directory ERROR 1: libpodofo.so.0.9.8: cannot open shared object file: No such file or directory ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directoryAdded 2022-11-24 22:26:02 UTC - Commented by Konstantin Gizdov (kgizdov)
So this is definitely a design choice on upstream's part to crash the hole application if a plugin fails to load. We normally expect the opposite. In any case, the simplest but in my opinion insufficient solutions at the moment is to add back all optional dependencies as hard dependencies and wait for upstream to list/explain or detail what files/procedures should be split-packaged to make this work correctly. I've messaged on the related GitHub issue with that goal but unfortunately the issue has been long closed. Let's see.
Added 2022-11-24 22:57:07 UTC - Commented by Antonio Rojas (arojas)
@kgizdov what do you mean by "crash the whole application"? The issue reported here is a harmless error message on stdout, which is nothing uncommon (there are similar messages eg. in enchant and sonnet if some optional dependencies used by plugins are missing)
Added 2022-11-25 00:05:50 UTC - Commented by Konstantin Gizdov (kgizdov)
For me it crashes the app, so I thought that was the error reported here. If not, then my test had some other reason for crashing. I can revert.
Added 2022-11-25 02:34:22 UTC - Commented by Konstantin Gizdov (kgizdov)
3.6.0-2 should be reverted to normal
Added 2023-06-11 21:35:05 UTC - Commented by Toolybird (Toolybird)
Dupes FS#77348 FS#78765
assigned to @jlichtblau and @archange
unassigned @jlichtblau
added resolutionupstream label
