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.

Same as @jev-vv

updated grive to 0.5.1-1

had to remove .grive and .grive_state

ran grive -a and got the:

Sign in with Google temporarily disabled for this app
This app has not been verified yet by Google in order to use Google Sign In.

It is interesting that it says "grive2"...

Same thing here.

As I got oauth failure:

Failed to refresh auth token: HTTP 401, body: exception: /home/vasqueja/.cache/aurutils/snapshot/grive/src/grive2-0.5.1/libgrive/src/protocol/OAuth2.cc(111): Throw in function void gr::OAuth2::Refresh() Dynamic exception type: boost::wrapexcept<gr::OAuth2::AuthFailed> [gr::expt::BacktraceTag*] = #0 0x559c9e093d7c grive gr::Exception::Exception()

<h1>1 0x559c9e0892ea grive gr::OAuth2::AuthFailed::AuthFailed()</h1> <h1>2 0x559c9e088f24 grive gr::OAuth2::Refresh()</h1> <h1>3 0x559c9e089115 grive gr::OAuth2::OAuth2(gr::http::Agent*, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)</h1> <h1>4 0x559c9e03947b grive Main(int, char**)</h1> <h1>5 0x559c9e037369 grive main</h1> <h1>6 0x7fe96847a153 /usr/lib/libc.so.6 __libc_start_main</h1> <h1>7 0x559c9e037e9e grive _start</h1>

Then I tried removing ".grive", and "grive -a", and after logging in I got the message:

Sign in with Google temporarily disabled for this app This app has not been verified yet by Google in order to use Google Sign In.

Weird enough is that when attempting to login, the app showed up as grive2. Then I checked on google security, and grive was actually authorized. I'm not sure if the "grive2" app name is the issue...

I'm having issues connecting it to google, google says that the app has not been verified and that logins are disabled, is this normal?

@deemon The -git package fetches the very latest version from the repository itself, while the non-git version, i.e. this package, uses the latest tag. This naming convention is used through the AUR and described in much more detail in the ArchWiki.

I see 2 packages, grive and grive-git both maintained by edh and both referring to the same upstream url. Why 2 packages and which one is the better version to use? For a while grive wasn't even updated, but not it seems...?

So, comparing cmake output between running it within a tty and in X I noticed that the paths were different, which led me to comparing $PATH.

Turns out that in X something was adding /bin to my $PATH. This normally should be fine, /bin is symlinked to /usr/bin after all, but for some reason this causes errors in this specific instance.

Changing build() to the following allows makepkg to succeed even within Xorg for me.

        PATH="${PATH#/bin:}" cmake -DCMAKE_BUILD_TYPE=Release \
        -DCMAKE_INSTALL_PREFIX=/usr \
        -DCMAKE_EXE_LINKER_FLAGS=-ljson-c ..

    make

I have no idea what adds /bin to the path, it's something specifically sourced by zsh for my user configuration (but when run inside Xorg), as bash or zsh as root don't have the same problem.

I just added the same addition to my .zshenv, and that removes it from my profile.

If someone has the same issue and this solution works I'd love to compare dotfile configurations, in order to find the offender.

@Mr.Smith1974, In a chroot or tty as well?

(I tried building after a reboot as well, and I still get the same error when building in X but on a tty it still builds, it probably is some weird environment setting that is set somewhere, but we probably won't be able to find out what it is unless we compare systems)

@MagicAndWires @edh I still have error:

  ==> Starting build()...
  CMake Warning (dev) in CMakeLists.txt:
    No project() command is present.  The top-level CMakeLists.txt file must
    contain a literal, direct call to the project() command.  Add a line of
    code such as

      project(ProjectName)

    near the top of the file, but after cmake_minimum_required().

    CMake is pretending there is a "project(Project)" command on the first
    line.
  This warning is for project developers.  Use -Wno-dev to suppress it.

  -- The C compiler identification is GNU 9.2.0
  -- The CXX compiler identification is GNU 9.2.0
  -- Check for working C compiler: /bin/cc
  -- Check for working C compiler: /bin/cc -- works
  -- Detecting C compiler ABI info
  -- Detecting C compiler ABI info - done
  -- Detecting C compile features
  -- Detecting C compile features - done
  -- Check for working CXX compiler: /bin/c++
  -- Check for working CXX compiler: /bin/c++ -- works
  -- Detecting CXX compiler ABI info
  -- Detecting CXX compiler ABI info - done
  -- Detecting CXX compile features
  -- Detecting CXX compile features - done
  -- Found libgcrypt: -lgcrypt -lgpg-error
  -- Found CURL: /usr/lib/libcurl.so (found version "7.66.0")
  -- Found EXPAT: /usr/lib/libexpat.so (found version "2.2.7")
  -- Found Boost: /lib64/cmake/Boost-1.71.0/BoostConfig.cmake (found suitable version "1.71.0", minimum required is "1.40.0") found components:  program_options filesystem unit_test_framework regex system
  -- Found libbfd: /usr/lib/libbfd.so
  -- Found libiberty: /usr/lib/libiberty.a
  -- Found ZLIB: /usr/lib/libz.so (found version "1.2.11")
  -- Found PkgConfig: /bin/pkg-config (found version "1.6.3")
  -- Checking for module 'yajl'
  --   Found yajl, version 2.1.0
  -- Found Boost: /lib64/cmake/Boost-1.71.0/BoostConfig.cmake (found version "1.71.0") found components:  program_options
  -- Configuring done
  CMake Error in libgrive/CMakeLists.txt:
    Imported target "Boost::program_options" includes non-existent path

      "/include"

    in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

    * The path was deleted, renamed, or moved to another location.

    * An install or uninstall procedure did not complete successfully.

    * The installation package was faulty and references files it does not
    provide.



  CMake Error in libgrive/CMakeLists.txt:
    Imported target "Boost::program_options" includes non-existent path

      "/include"

    in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

    * The path was deleted, renamed, or moved to another location.

    * An install or uninstall procedure did not complete successfully.

    * The installation package was faulty and references files it does not
    provide.



  CMake Error in grive/CMakeLists.txt:
    Imported target "Boost::program_options" includes non-existent path

      "/include"

    in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

    * The path was deleted, renamed, or moved to another location.

    * An install or uninstall procedure did not complete successfully.

    * The installation package was faulty and references files it does not
    provide.



  CMake Error in grive/CMakeLists.txt:
    Imported target "Boost::program_options" includes non-existent path

      "/include"

    in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

    * The path was deleted, renamed, or moved to another location.

    * An install or uninstall procedure did not complete successfully.

    * The installation package was faulty and references files it does not
    provide.



  -- Generating done
  CMake Generate step failed.  Build files cannot be regenerated correctly.

@edh @simona @Mr.Smith1974

This problem is resolved by building in a chroot, and even works if you build it in a new login session (I built it successfully in virtual terminal when I couldn't in X)

It probably has something vaguely to do with something not being properly notified that files have changed.

No PKGBUILD changes necessary.

@simona,Mr.Smith1974 Can you try reproducing your problem in a clean chroot? If so, I suppose it probably is a bug in grive itself. I am unfortunately still unable to reproduce the described error on two separate machines.

I am happy to add any workarounds necessary, if there is a consensus on the bug-tracker.