FS#75749 - [gdal] ERROR 1: libarrow.so.800: cannot open shared object file: No such file or directory

Attached to Project: Community Packages
Opened by Thomas (thomastc) - Tuesday, 30 August 2022, 13:50 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:04 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Jaroslav Lichtblau (Dragonlord)
Bruno Pagani (ArchangeGabriel)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 3
Private No

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]
...
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:04 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/gdal/issues/1
Comment by Toolybird (Toolybird) - Tuesday, 30 August 2022, 22:16 GMT
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
Comment by Thomas (thomastc) - Wednesday, 31 August 2022, 20:37 GMT
  • Field changed: Percent Complete (100% → 0%)
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.
Comment by plasmoid (plasmoid) - Friday, 02 September 2022, 08:04 GMT
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 directory
Comment by Konstantin Gizdov (kgizdov) - Thursday, 24 November 2022, 22:26 GMT
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.
Comment by Antonio Rojas (arojas) - Thursday, 24 November 2022, 22:57 GMT
@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)
Comment by Konstantin Gizdov (kgizdov) - Friday, 25 November 2022, 00:05 GMT
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.
Comment by Konstantin Gizdov (kgizdov) - Friday, 25 November 2022, 02:34 GMT
3.6.0-2 should be reverted to normal
Comment by Toolybird (Toolybird) - Sunday, 11 June 2023, 21:35 GMT
Dupes  FS#77348   FS#78765 

Loading...