Arch Linux User Repository

If you encounter errors similar to error [...] loading shared libraries, you most likely need to rebuilt the grive package. Usually no further action is needed except for forcing a rebuilt.

The error is due to grive having been built against an older version of the library mentioned in the error message. The library has likely since been updated by pacman and grive need to be made aware of this by rebuilding it.

@growleg The README is outdated. The service files are installed correctly however they are named grive-changes@.{service,timer}.

P.S. in the issue that you referenced the service files are enabled via systemctl --user start grive-changes@$(systemd-escape google-drive).service and not via grive@... :P

The systemd files seem to end up in the wrong directory (see https://github.com/vitalif/grive2/issues/283). Running systemctl --user enable --now grive@$(systemd-escape google-drive).service (as it is specified in the README) results in Failed to enable unit: Unit file grive@google\x2ddrive.service does not exist. Is it possible to manually move them into the right directory?

For some reason it didn't work for me when i tried merely uninstalling grive, cleaning the cache, and reinstalling grive. Instead, I had to also remove all dependent packages (orphans) in addition to the preceding steps. Now it works.

@Crandel Sure but as outlined this mostly makes sense for binary packages that are managed together (bbswitch is in community) with the library that is being bumped.

I think hardcoding a specific library version is not a good idea because for one it blocks new users from installing the package for now good reason in the time it takes me to update the package and furthermore it would block system updates for all users of grive until the PKGBUILD is updated.

@edh The problem was solved by removing cache directory. BTW, a lot of packages have minor updates when their dependencies was updated. For example bbswitch at the moment has version 0.8-513 which means it was updated 513 times without any changes in it sources. You can specify exact boost version and update grive PKGBUILD file every time boost will be updated

@Pound_Hash Then you could have just asked that... Anyways, the important part of the comment is the "rebuild" part. The "problem" with packages in the AUR is that they link against whatever was installed when building the package and rebuilds are not coordinated between the AUR and Arch repos. In this case, back when you first built grive, it was linked against libboost_filesystem.so.1.78. At some point after that boost was updated and now grive links against the wrong version. You can fix this simply by rebuilding the package.

Because nothing about the PKGBUILD changes, I feel reluctant to update it. Hence, I used the word "local" to denote that the problem is solely on your end.

The problem is I don't understand what building locally means. I doubt this is the same as building manually. If not, what's the difference? Aren't all my builds done locally? I only ever use my own machine, never a remote one.

@Pound_Hash Please read the comment that is literally right below yours! In the future it would make sense to do that before posting a new comment ;)

grive: error while loading shared libraries: libboost_filesystem.so.1.78.0: cannot open shared object file: No such file or directory

@Crandel Please rebuild locally.