duckdb: Not running on Ubuntu 18.04.5 (missing something..?)

Downloaded the Linux CLI binary (0.21, same results with e26286d9823c0b71bd02cf2e184e9031c9a273df): file duckdb: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=dd8544b648321f5918a10ef3808a1f17044c6f19, not stripped

When running it: duckdb: duckdb: /usr/lib/x86_64-linux-gnu/libstdc++.so.6: version GLIBCXX_3.4.26’ not found (required by duckdb)`

I have /usr/lib/x86_64-linux-gnu/libstdc++.so.6 from package libstdc++6:amd64 , but something is wrong… This is on Ubuntu 18.04.5 LTS.

About this issue

  • Original URL
  • State: closed
  • Created 4 years ago
  • Comments: 30 (5 by maintainers)

Most upvoted comments

I tried out making a build of an AppImage packaging of the duckdb CLI, which seems to run on my Mint and Ubuntu boxes (which are not exactly bleeding edge). It is a cloud build using this workflow.

It provides a single file of 11MB which includes everything needed to run it. It is available here

@rongfengliang @pepa65 if you download this one, and try it out does it run for you too?

wget "https://github.com/mskyttner/duckdb-cli-builds/releases/download/refs%2Fheads%2Fmain/duckdb-x86_64.AppImage"
chmod +x duckdb-x86_64.AppImage
./duckdb-x86_64.AppImage

#file duckdb-x86_64.AppImage 
#duckdb-x86_64.AppImage: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.18, stripped

Excellent. I propose to close this issue then.

Thanks for making those! Do they just work with the rest of my environment & applications from the repos? Of course it leads to a conflict with the repository managing software, to replace /usr/lib/x86_64-linux-gnu/libstdc++.so.6

yes this way maybe cause conflict,with static library maybe better

@pepa65 copy new ibstdc++ library && add softlink maybe help https://github.com/rongfengliang/libstdc-so

It would be nice if there were static binaries available for each platform, so they would always run! (Which is what AppImage binaries are, but since the application itself is already a single binary, maybe some way of compiling all dependencies into a single static binary would be possible.)

If python3 really isn’t required for building, it shouldn’t be listed in README.md.

Indeed .save is not supported yet, so this is expected behavior currently. Thanks for the report!

That error is not from SQLite itself, it’s from our SQLite3 API wrapper. We wrap the internal SQLite API in order to use the shell. However, since the API has many operations (and many we are not interested in) we have not implemented all of them. When a function that is not implemented gets used we print a warning message and return an error condition. The backup API is one of those cases.

Can you describe the actions you took that leads to this warning being printed? Just starting up the shell on Ubuntu? Does the error prevent you from doing anything else afterwards?

Edit: Nevermind, just saw the message. “.save” is indeed not supported yet.

I was going to share the version that works with Ubuntu 18.04 (GLIBCXX_3.4.25), but then I discovered that it didn’t work on my old server (Ubuntu 16.04), so I build that too: duckdb for GLIBCXX_3.4.21 or higher [Note: 16.04 doesn’t even have GLIBCXX_3.4.22, so I changed the link!]

Quite a few of those still around… Because it’s just a single binary, it’s not too hard to provide for these use cases. I’m willing to share mine. 😄