glycin still FTBFS if not already installed

[zeckma]

The sed for the meson.build does fixes the issue partially, but the current instructions still result in a system without glycin to fail. This is because glycin-thumbnailer still is being built and it cannot find the glycin library. It doesn't seem to want to link again the glycin library after it is built, but instead tries to link against a system version that doesn't exist.

There seems to be two options here:

1. Do something like:

   meson setup ... $(pkgconf glycin-2 || echo -D glycin-thumbnailer=false)
   

and address that to get the thumbnailer, glycin must be built twice.

2. Try to get glycin-thumbnailer to link against the glycin library that will be built, meaning glycin-thumbnailer must be built at a later step than the glycin library.

The first option is easy, but if there isn't a good reason preventing option 2 beyond time and effort, I think going for option 2 is best unless there isn't time able to be afforded for it.

[Bruce Dubbs]

Would setting LD_LIBRARY_PATH to the directory where the glycin library is built work?

[Xi Ruoyao]

Please paste the exact error message. It's hard to tell what's happening without that.

[zeckma]

Replying to Xi Ruoyao:

Please paste the exact error message. It's hard to tell what's happening without that.

Compiling glycin-thumbnailer v2.1.0 (/sources/slfs/glycin-2.1.1/glycin-thumbnailer)
error: linking with `cc` failed: exit status: 1
  |
  = note:  "cc" "-m64" "<1 object files omitted>" "-Wl,--as-needed" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-*.rlib" "-Wl,-Bdynamic" "-lglycin-2" "-lfontconfig" "-lgio-2.0" "-lgobject-2.0" "-lglib-2.0" "-lseccomp" "-llcms2" "-lgio-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgobject-2.0" "-lglib-2.0" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-L" "/sources/slfs/glycin-2.1.1/build/cargo-target/release/deps/rustcuOssw2/raw-dylibs" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "/sources/slfs/glycin-2.1.1/build/libglycin" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/sources/slfs/glycin-2.1.1/build/cargo-target/release/deps/glycin_thumbnailer-ad36797c78919166" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-Wl,--strip-debug" "-nodefaultlibs"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: /usr/bin/ld: cannot find -lglycin-2: No such file or directory
          collect2: error: ld returned 1 exit status
          

error: could not compile `glycin-thumbnailer` (bin "glycin-thumbnailer") due to 1 previous error
while executing ['/opt/rustc/bin/cargo', 'build', '--target-dir', '/sources/slfs/glycin-2.1.1/build/cargo-target', '--profile', 'release', '--manifest-path', '/sources/slfs/glycin-2.1.1/Cargo.toml', '--package=glycin-thumbnailer']
ninja: job failed with status 101: /usr/bin/meson --internal exe --unpickle /sources/slfs/glycin-2.1.1/build/meson-private/meson_exe_cargo_5889454d826f2e63c64cc09adf1a0498f6af0241.dat
ninja: subcommand failed

build/libglycin/libglycin-2.so is present, but, it's a broken symlink to libglycin-2.so.0 which wasn't built. So it seems like some dependency information is missing or the thumbnailer is listed as an earlier target than the actual library. Note that the only target that was handled before the thumbnailer was glycin-loaders/glycin-heif.

[zeckma]

Okay, I figured out two issues. I've been using samurai instead of Ninja we supply in LFS. However, and I have brought this up with the people behind samurai, these type of issues are always caused by incorrect or incomplete dependency information, and under certain circumstances will still trigger with regular Ninja. When running ninja glycin-thumbnailer/glycin-thumbnailer, this issue can be reproduced.

[zeckma]

Closing this but I'll see if I can resolve this with upstream since most of the time we shouldn't hit this.

[Xi Ruoyao]

I guess there's a race condition then. Maybe we should add -j1 to ninja (cargo will parallelize the build anyway so I don't think -j1 will really slow down too much).

[zeckma]

We could, though there are 21 targets as of now, and I haven't hit the issue with regular Ninja. It does pop up if parallelism is too high. I'm guessing there also needs to be a high target count? That or it's up to chance. I don't think we should though until someone reports it with regular Ninja.

The fix as well is pretty easy. The same thing happened in gnome-keyring with header generation but they fixed it. The fix is always usually pretty simple.

[zeckma]

I couldn't fork the repository but made an issue with a diff and explanation. The issue exists here: ​https://gitlab.gnome.org/GNOME/glycin/-/issues/282.