Arch Linux User Repository

hi gyscos, thanks for the heads up, i've been doing something similar since a few days ago with the -bin and -git versions of this package, i'm keeping this as it is since i'm currently unable to build, i will update the dependencies as soon as a release with the pure_rust crypto flag is available.

Looking at the output of cargo build --release -vv | rg simd, I see (among other things):

[simsimd 6.5.3] cargo:rustc-link-lib=static=simsimd

This looks like it tries to build simsimd statically.

Looking at simsimd's build script (https://github.com/ashvardanian/NumKong/blob/v6.5.16/build.rs), it also looks like it's building the vendored lib into a static lib (the default for cc).

So maybe we don't need the simsimd dependency at all? Even not as a makedepends, since it just compiles the C source packaged in the crate.

I also suspect the other -l flags are not needed, as I don't see any of them mentioned in ldd $(which tursodb).

Hi @gyscos, I've merged your change into the simsimd PKGBUILD. I still have to investigate why libsimsimd is not dynamically linked into tursodb, I'm sure it was required for compilation at some point.

I will take a look into it as soon as I'm able to. In the meantime, feel free to reach out if you have any other suggestion!

Hi! I'm getting compilation errors with the latest version of this package:

error: linking with `cc` failed: exit status: 1
  |
  = note:  "cc" "-m64" "/tmp/rustcifch2g/symbols.o" "<4 object files omitted>" "-Wl,--as-needed" "-Wl,-Bdynamic" "-laegis" "-lgit2" "-lmimalloc" "-lonig" "-lsimsimd" "-Wl,-Bstatic" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib/{libstd-*,libpanic_unwind-*,libobject-*,libmemchr-*,libaddr2line-*,libgimli-*,libcfg_if-*,librustc_demangle-*,libstd_detect-*,libhashbrown-*,librustc_std_workspace_alloc-*,libminiz_oxide-*,libadler2-*,libunwind-*,liblibc-*,librustc_std_workspace_core-*,liballoc-*,libcore-*,libcompiler_builtins-*}.rlib" "-Wl,-Bdynamic" "-lgcc_s" "-lutil" "-lrt" "-lpthread" "-lm" "-ldl" "-lc" "-L" "/tmp/rustcifch2g/raw-dylibs" "-B<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/bin/gcc-ld" "-fuse-ld=lld" "-Wl,--eh-frame-hdr" "-Wl,-z,noexecstack" "-L" "<sysroot>/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-o" "/run/user/60039/paru/clone/turso/src/turso_cli-0.4.0/target/release/build/getrandom-aca3fdb86cdcdf7c/build_script_build-aca3fdb86cdcdf7c" "-Wl,--gc-sections" "-pie" "-Wl,-z,relro,-z,now" "-nodefaultlibs"
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: rust-lld: error: unable to find library -lsimsimd
          collect2: error: ld returned 1 exit status


error: could not compile `getrandom` (build script) due to 1 previous error

The same happens for many other crates when building this package.

It's complaining about the inability to find -lsimsimd, but I do have simsimd 6.5.4-2 installed. But it looks like simsimd stores its libsimsimd.so in /usr/local/lib for some reasons. Maybe that's the issue?

If I remove -l simsimd from the RUSTFLAGS, it builds fine (but might end up not using simsimd?).

If I leave that flag, but copy /usr/local/lib/libsimsimd.so to /usr/lib/libsimsimd.so, it also builds fine.

At this point I believe the issue is in the simsimd package, I left a comment there.

Though curiously, note that in both cases, the resulting tursodb binary doesn't seem to dynamically link to it (but that's a different problem):

> ldd (which tursodb)
        linux-vdso.so.1 (0x00007fd24cbfc000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007fd24cbc7000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007fd24be99000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007fd24bc00000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007fd24cbfe000)

Hi @gycos, I've created the turso package, I'm gonna merge this one with it once there's a stable release. Thanks for letting me know!

Hi! It looks like limbo is being renamed to turso. Not sure if a new AUR package should be started or if this one can be renamed?

Fixed! Thanks for letting me know

Hi, and thanks for maintaining this package! I'm getting compilation error building this with gcc 15.1.1, oniguruma 6.9.10:

  cargo:warning=oniguruma/src/regparse.c: In function 'onig_st_init_strend_table_with_size':
  cargo:warning=oniguruma/src/regparse.c:588:5: error: initialization of 'int (*)(void)' from incompatible pointer type 'int (*)(st_str_end_key *, st_str_end_key *)' [-Wincompatible-pointer-
types]
  cargo:warning=  588 |     str_end_cmp,
  cargo:warning=      |     ^~~~~~~~~~~
  cargo:warning=oniguruma/src/regparse.c:588:5: note: (near initialization for 'hashType.compare')
  cargo:warning=oniguruma/src/regparse.c:550:1: note: 'str_end_cmp' declared here
  cargo:warning=  550 | str_end_cmp(st_str_end_key* x, st_str_end_key* y)
  cargo:warning=      | ^~~~~~~~~~~
  cargo:warning=oniguruma/src/regparse.c:589:5: error: initialization of 'int (*)(void)' from incompatible pointer type 'int (*)(st_str_end_key *)' [-Wincompatible-pointer-types]
  cargo:warning=  589 |     str_end_hash,
  cargo:warning=      |     ^~~~~~~~~~~~
  cargo:warning=oniguruma/src/regparse.c:589:5: note: (near initialization for 'hashType.hash')
  cargo:warning=oniguruma/src/regparse.c:571:1: note: 'str_end_hash' declared here
  cargo:warning=  571 | str_end_hash(st_str_end_key* x)
  cargo:warning=      | ^~~~~~~~~~~~

(And a bunch of similar ones)

The weird thing is that it works totally fine on 2 other computers running up-to-date arch as well :^S

That's wonderful news!

A few more votes and a little more stability upstream and I'll be migrating this to [extra].