Libvips-cpp.so.42 not found on AppImage upgrade from 0.9.1 to 1.0.0-alpha.7

Hi. I just downloaded and wanted to try 1.0.0-alpha.7
I was previously on 0.9.1

On startup it loads the (lovely) splash screen and nothing further. I left it for two hours in case it was doing some upgrade, although CPU usage is minimal.

Starting from the command line, I see the following…

 ~/bin/PhotoStructure-1.0.0-alpha.7-x86_64.AppImage
(node:276216) UnhandledPromiseRejectionWarning: Error: 
Something went wrong installing the "sharp" module

libvips-cpp.so.42: cannot open shared object file: No such file or directory

- Remove the "node_modules/sharp" directory then run
  "npm install --ignore-scripts=false --verbose sharp" and look for errors
- Consult the installation documentation at https://sharp.pixelplumbing.com/install
- Search for this error at https://github.com/lovell/sharp/issues

    at Object.<anonymous> (/tmp/.mount_PhotoSCLJKkk/resources/app.asar/node_modules/sharp/lib/constructor.js:32:9)
    at Module._compile (internal/modules/cjs/loader.js:1078:30)
    at Object.Module._extensions..js (internal/modules/cjs/loader.js:1108:10)
    at Module.load (internal/modules/cjs/loader.js:935:32)
    at Module._load (internal/modules/cjs/loader.js:776:14)
    at Function.f._load (electron/js2c/asar_bundle.js:5:12684)
    at Module.require (internal/modules/cjs/loader.js:959:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> (/tmp/.mount_PhotoSCLJKkk/resources/app.asar/node_modules/sharp/lib/index.js:3:15)
    at Module._compile (internal/modules/cjs/loader.js:1078:30)
(Use `photostructure --trace-warnings ...` to show where the warning was created)
(node:276216) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:276216) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Ubuntu info…

No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal

Oof, sorry about that: I thought that library was statically linked.

I’m away from my desk this weekend, but I’ll look into it on Monday.

If you want to try an alpha build, the node and docker editions should run OK.

I just tried docker tonight. It looks like it want so re-index my lib on 0.9.1. Presumably my UUIDs have changed.

However, docker on :alpha says “No library path set”.
Changing back to 0.9.1 in docker works (albiet with a reindex).

Can I “move” my library somehow? I have the following.

/opt/Media                 <- NFS mount point. Used by AppImage
/opt/Media/.uuid           <- Manually created .uuid file.
/opt/Media/Pictures/.uuid  <- Manually created .uuid file. This is the bind mount for docker.
/opt/Media/Pictures/PhotoStructure/.uuid   <- I don't remember creating this, but it is my PS library location.

So, to avoid the re-index, can I “move” my images to the new path somehow?

Also, can you give me pointers on how to fix the “No library set” issue? It wants me to start from scratch.

To avoid reindexing, the path from the mountpoint needs to match your prior computer. The URI structures are designed to handle plugging in an external drive and having the OS mount it to different directories each time (like on macOS, you’ll see /Volumes/Untitled, then /Volumes/Untitled 1, …).

You must bind mount your library to /ps/library.

I’m afraid v1.0 requires a rebuild to add the new person/who tagger, filesystem tagger, improved raw image decoding, and improved image deduping heuristics.

I have and will continue to try to avoid changes that require rebuilds, though: I appreciate how inconvenient they are for people with large libraries!

To avoid reindexing, the path from the mountpoint needs to match your prior computer.

Yep, that’s what I thought. Not much I can do about that now, as the AppImage doesn’t really give control over that.

Any ideas on why 1.0 is coming up blank? Can I send some logs?

Ah, can’t “send logs” until I have run the setup wizard, and I couldn’t DM you a tgz file. I’ll email you.

Thanks for the logs. From within the docker container, it looks like /ps/library/.photostructure/settings.toml doesn’t exist, which is why it’s saying you don’t have a library set up.

If, say, you set up PhotoStructure for Desktops and set up your library as /home/tim/Pictures, you’ll need to bind-mount /home/tim/Pictures to /ps/library, like this (in a docker-compose.yml):

    volumes:
      ...
      - type: bind
        source: /home/tim/Pictures
        target: /ps/library
      ...

Yeah, but what confuses me the most, is that the same docker-compose file works for 0.9.1, but 1.0 gives me that message.

ll /opt/Media/Pictures/PhotoStructure/.photostructure/settings.toml 
-rw-rw-r-- 1 timw timw 36161 Apr 11 07:20 /opt/Media/Pictures/PhotoStructure/.photostructure/settings.toml
      - type: bind
        source: /opt/Media/Pictures/PhotoStructure # < CHANGE THIS LINE
        target: /ps/library

      - type: bind
        source: "${HOME}/.cache/photostructure"
        target: /ps/tmp

      - type: bind
        source: "${HOME}/.config/PhotoStructure-docker"
        target: /ps/config

      - type: bind
        source: "${HOME}/.config/PhotoStructure-docker/logs"
        target: /ps/logs

      - type: bind
        source: /opt/Media/Pictures # < CHANGE THIS LINE
        target: /opt/Media/Pictures

What’s the output of

ls -l /opt/Media/Pictures/PhotoStructure/.photostructure/settings.toml

?

I did post that above. But I edited a previous post. Ooops.

Sorry, missed that. That all seems right to me. I’ll think about what else could be fouling the works.

I wondered if I have some stuff in the settings file that was customised from last year on 0.8 on docker.
It’s still the same NFS mount so there could’ve been some stuff lurking.

However I just looked and it looks like a standard 0.9.1 file. Nothing is uncommented.

@tim_w_photography apologies for the delay in figuring this out, but this may solve your issue:

I’m about to release alpha.8, so either way, if it works or doesn’t, I’d be interested in knowing. :+1:

Thanks. Yep, that fixed it.

This will be fixed in the new alpha I’m releasing today. Thanks again for taking the time to report it!