Arch Linux User Repository

Note that this issue only manifests itself on a stock Arch Linux configuration. Changes in /etc/makepkg.conf or in /etc/makepkg.conf.d/* can prevent the issue from occurring. See the referenced issue.

Zepman: aarch64: noted, I will add this asap. x86_64: ok, i tried quickly but couldn't reproduce yet, i will look into this. Thanks!

This package successfully builds under aarch64 (tested on a Pi 5 with 8 GB of RAM). This architecture can be added to array 'arch' in PKGBUILD.

This package fails to build under x86_64 due to this issue:

   Compiling lldap v0.5.1-alpha (/tmp/a/src/lldap-git/server)
error: linking with `cc` failed: exit status: 1
(a whole lot of link debug information)
          /usr/bin/ld: /tmp/a/src/lldap-git/target/release/deps/lldap_set_password-e90d8e82e4251d52: hidden symbol `GFp_ia32cap_P' isn't defined
          /usr/bin/ld: final link failed: bad value
          collect2: error: ld returned 1 exit status

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-link-lib)

error: could not compile `lldap_set_password` (bin "lldap_set_password") due to 1 previous error

This error repeats for lldap_migration_tool and lldap.

The fix is:

diff -Naru a/PKGBUILD b/PKGBUILD
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -32,6 +32,7 @@
 }

 build() {
+  CFLAGS+=' -ffat-lto-objects'
   export RUSTUP_TOOLCHAIN=stable
   cd "$pkgname"
   cargo build --offline --release --all-features -p lldap -p lldap_migration_tool -p lldap_set_password

Zepman: Well then i'm puzzled as to:

• Who sent a SIGKILL to a perfectly fine rustc compilation process during build.
• Why you got the same error pattern when building the "lldap" aur package (according to your comment there).
• How it is possible that you fixed your error on the "lldap" aur package by simply silencing warnings during build (something which doesn't affect anything besides what gets printed out).

Two explanations: either there is a really weird bug somewhere in rustc, or somehow the compilation process hit a resource limit and got killed by a system watchdog. In either case, i cannot see how this kind of error (someone sending SIGKILL) could be originating from the package definition, it is neither a dependency missing nor a (normal) compiler error. Supporting second explanation is the fact that i reproduced the error in low memory conditions and built without error on fresh install with high memory and swap enabled.

As to why your edits fixed the problem, perhaps if you restarted the build without doing a cleanbuild, the resource usage got lower since some dependencies were already compiled.

Note that it might also be the case that rustc/cargo uses /tmp or some other tmpfs quite enthusiastically which could add to the memory pressure. The debian farm reports 10GiB max disk space, i don't know how much of this was on /tmp.

Perhaps i'll pin a comment to check available ram and swap device if this issue pops up again. Until then i don't think i have more input to give.

@lapinot

Incorrect. My building machine (the one running stock Arch Linux system with base-devel installed) has 16 GB of (mostly free, since stock) memory.

Furthermore, building with your recipe at the time failed. Building with my recipe at the time did not. I did not try your latest recipe.

I know building LLDAP is taxing, which is why I created lldap-bin for the stable version of LLDAP. For building I use a beefy enough configuration of which I know that it works.

Zepman: Confirming your error is caused by not enough memory available. See https://github.com/lldap/lldap/issues/660. It needs ~5GiB memory to complete.

@lapinot

I asked you two questions you answered neither (if this could be a ram issue).

You asked two questions:

1. Did you also try to build in a chroot?

My answer:

I did not use a chroot environment.

You can infer that this means "no".

Your second question:

1. In the meantime, outside of any chroot or VM: have you tried doing rustup update before building?

My answer:

Tested on a stock Arch Linux system with base-devel installed, without the use of an AUR helper. (...) I also did not install or configure Rust as a build dependency.

You can infer this means "no", since a stock Arch Linux system with base-devel installed does not have Rust installed.

Please lets keep things factual, don't insinuate i don't really read your messages

Please do not appear as if you are insinuating that others don't read your messages when claiming that others insinuate that you do not read their messages. Your questions were answered, and your claim was unnecessary.

I am being factual. The emphasis was on the word very to clarify that I really used a stock Arch Linux system with only minimal tooling (base-devel and yes, sudo...) to attempt an install. There are too many bug reports that are based on AUR helpers, which are not supported and make debugging way more complex.

My PKGBUILD diff (based on the PKGBUILD of lldap):

3,5c3,6
< pkgname=lldap
< pkgver=0.5.0
< pkgrel=2
---
> pkgname=lldap-git
> _pkgname=lldap
> pkgver=0.5.0.r97.g959bb90
> pkgrel=1
9a11,12
> provides=('lldap')
> conflicts=('lldap')
14d16
< _commit='6f04530700cbe00e979c84483a8310b1339e9d6e'
16c18
<   "$pkgname::git+$url#commit=$_commit"
---
>   "$pkgname::git+$url"
23c25
<         '3c1a5d25ecd028b11c42ef92dd4e9763d2817c63157fb9b31e1e6283cd1195063eeb7fb0867362cfd585921c09a1010e3a2c8545e69cd2d304d708d385a2da2c'
---
>         'e7578314bfcc41e5e0413233f0d1aba26003b6ad9066f7e29bfb938b5d97716d4e0dd68643990e1762f16b889368385eda873e679a78de12ea220e49c6835e2d'
31c33,34
<   git describe --tags | sed 's/^v//'
---
>   #git describe --tags | sed 's/^v//'
>   git describe --long --tags | sed 's/\([^-]*-g\)/r\1/;s/-/./g;s/^v//'
72,74c75,77
<   install -vDm644 systemd.service "$pkgdir/usr/lib/systemd/system/$pkgname.service"
<   install -vDm644 sysusers.conf "$pkgdir/usr/lib/sysusers.d/$pkgname.conf"
<   install -vDm644 tmpfiles.conf "$pkgdir/usr/lib/tmpfiles.d/$pkgname.conf"
---
>   install -vDm644 systemd.service "$pkgdir/usr/lib/systemd/system/${_pkgname}.service"
>   install -vDm644 sysusers.conf "$pkgdir/usr/lib/sysusers.d/${_pkgname}.conf"
>   install -vDm644 tmpfiles.conf "$pkgdir/usr/lib/tmpfiles.d/${_pkgname}.conf"
86c89
<   install -vDm640 lldap_config.docker_template.toml "$pkgdir/etc/$pkgname.toml"
---
>   install -vDm640 lldap_config.docker_template.toml "$pkgdir/etc/${_pkgname}.toml"
90,94c93,97
<   install -vd "$pkgdir/var/lib/$pkgname"
<   install -vDm644 app/index_local.html "$pkgdir/var/lib/$pkgname/app/index.html"
<   install -vDm644 -t "$pkgdir/var/lib/$pkgname/app/static" app/static/*.{css,js,gif}
<   install -vDm644 -t "$pkgdir/var/lib/$pkgname/app/static/fonts" app/static/fonts/*.woff2
<   install -vDm644 -t "$pkgdir/var/lib/$pkgname/app/pkg" app/pkg/*
---
>   install -vd "$pkgdir/var/lib/${_pkgname}"
>   install -vDm644 app/index_local.html "$pkgdir/var/lib/${_pkgname}/app/index.html"
>   install -vDm644 -t "$pkgdir/var/lib/${_pkgname}/app/static" app/static/*.{css,js,gif}
>   install -vDm644 -t "$pkgdir/var/lib/${_pkgname}/app/static/fonts" app/static/fonts/*.woff2
>   install -vDm644 -t "$pkgdir/var/lib/${_pkgname}/app/pkg" app/pkg/*
97,98c100,101
<   install -vDm644 -t "$pkgdir/usr/share/doc/$pkgname" README.md
<   cp -vr docs "$pkgdir/usr/share/doc/$pkgname"
---
>   install -vDm644 -t "$pkgdir/usr/share/doc/${_pkgname}" README.md
>   cp -vr docs "$pkgdir/usr/share/doc/${_pkgname}"

The hash of the patch file config-template.patch was changed because I created a new patch that is compatible with the latest development version:

--- a/lldap_config.docker_template.toml
+++ b/lldap_config.docker_template.toml
@@ -95,7 +95,7 @@
 ##  - "mysql://mysql-user:password@mysql-server/my-database"
 ##
 ## This can be overridden with the LLDAP_DATABASE_URL env variable.
-database_url = "sqlite:///data/users.db?mode=rwc"
+database_url = "sqlite:///var/lib/lldap/data/users.db?mode=rwc"

 ## Private key file.
 ## Not recommended, use key_seed instead.
@@ -105,7 +105,7 @@ database_url = "sqlite:///data/users.db?
 ## each password.
 ## Randomly generated on first run if it doesn't exist.
 ## Env variable: LLDAP_KEY_FILE
-#key_file = "/data/private_key"
+#key_file = "/var/lib/lldap/data/private_key"

 ## Seed to generate the server private key, see key_file above.
 ## This can be any random string, the recommendation is that it's at least 12

Zepman: Please lets keep things factual, don't insinuate i don't really read your messages and don't explain to me what basic makepkg options do. Works for me and apparently also a couple other, so you're not entitled to me debugging your issue. I understand building in a fresh install is important, as i said "I will try to build in a clean VM to see if it works better". This will be fixed very soon. I asked you two questions you answered neither (if this could be a ram issue). Also rustup update will never be needed if rustup is not present before building, i said it might help with a stalled toolchain.

In case of a fresh install, the lldap package indeed doesn't use rustup but the arch-provided toolchains. Perhaps i forgot a dependency but afaiu x86-64, wasm and wasm-bindgen get installed dynamically. I previously thought that because of the need for the wasm target it wasn't possible to make the package agnostic to rustup vs arch-provided, but i might be wrong. I will test and switch if it doesn't pull anything when rustup is already installed.

If you'd like, I can share that PKGBUILD with you.

Yes, i guess you mostly took their makedepends, but indeed i'd be happy to see a diff.

@lapinot

As I wrote before:

Tested on a stock Arch Linux system with base-devel installed, without the use of an AUR helper.

You must take this very literally. I did not use a chroot environment. I also did not install or configure Rust as a build dependency. The package should do this if needed. Any AUR recipe should be able to build a package when base-devel is installed and when a (non-root, but with sudo rights) user runs makepkg -sr, since -s should take care of any build dependencies (sudo rights are only used for that and for removing packages using -r).

So no, I will not run rustup update before building. Such preparations should not be necessary to build any AUR recipe. Also, for diagnosing it would not do anything since rustup is not installed before I run makepkg -sr.

For now I created a workaround based on package lldap, which seems to have a more robust build process. If you'd like, I can share that PKGBUILD with you.

Also on my todolist: review the default config. At first it came from example config from the repo, i edited some with standard values. Maybe i should just put whatever the default value actually is for each.