lix-project/lix

Fork 55

Static builds fail #306

New issue

Closed

opened 2024-05-12 13:50:55 +00:00 by raito · 10 comments

raito commented

2024-05-12 13:50:55 +00:00

Owner

Traces: https://0x0.st/XKiG.txt

Happened during https://github.com/NixOS/nixpkgs/pull/310194.

Reproducer: nix-build -A lixStatic on that PR.

Traces: https://0x0.st/XKiG.txt Happened during https://github.com/NixOS/nixpkgs/pull/310194. Reproducer: `nix-build -A lixStatic` on that PR.

raito commented

2024-05-12 13:51:00 +00:00

Author

Owner

cc @delroth

raito added the

Area/build-packaging

label

2024-05-12 13:53:32 +00:00

delroth self-assigned this

2024-05-12 17:56:55 +00:00

raito commented

2024-05-12 18:11:52 +00:00

Author

Owner

@delroth FYI, it was found out that it's related to passing -shared and -static to the plugin build. It should probably be skipped at the Meson level, i.e. dynamic plugin tests make no sense for static builds (dlopen for musl returns dummy values, NULL or something IIRC).

@delroth FYI, it was found out that it's related to passing `-shared` and `-static` to the plugin build. It should probably be skipped at the Meson level, i.e. dynamic plugin tests make no sense for static builds (`dlopen` for musl returns dummy values, NULL or something IIRC).

delroth commented

2024-05-12 18:12:36 +00:00

Member

Yeah, that was fairly obvious and I already have a patch for this. But there are further problems with unit tests and C++ constructors causing store registration to sometimes not work (and that's what I'm currently debugging).

👍 1

delroth commented

2024-05-12 21:08:22 +00:00

Member

https://gerrit.lix.systems/c/lix/+/1106/1 fixes the first trivial part of the problem.

Then libstore tests fail because the linker is pruning .o files for store implementations due to them not being referenced. This is because store registrations are done via static initializers instead of having e.g. an init function being called by libstore's init, so unless the linker is forced to keep those .o files via (for example) Meson's link_whole it doesn't. But if you make libstore link_whole, that breaks a whole bunch of things, for example linking with libexpr because libexpr depends on libstore but Meson isn't transitively passing dependencies? I think?

Anyway, it's a fairly deep rabbit hole. Dropping for now.

https://gerrit.lix.systems/c/lix/+/1106/1 fixes the first trivial part of the problem. Then libstore tests fail because the linker is pruning .o files for store implementations due to them not being referenced. This is because store registrations are done via static initializers instead of having e.g. an init function being called by libstore's init, so unless the linker is forced to keep those .o files via (for example) Meson's `link_whole` it doesn't. But if you make libstore link_whole, that breaks a whole bunch of things, for example linking with libexpr because libexpr depends on libstore but Meson isn't transitively passing dependencies? I think? Anyway, it's a fairly deep rabbit hole. Dropping for now.

delroth removed their assignment

2024-05-12 21:08:29 +00:00

jade commented

2024-05-13 01:32:56 +00:00

Owner

why did this work in the first place?! :O cursed

~~like, did this work properly in make? because you still should need to give whole-archive right?~~oh i see we have some staticlibs that get linked together into a shared lib. yeah, hm. right.

why did this work in the first place?! :O cursed ~~like, did this work properly in make? because you still should need to give whole-archive right?~~oh i see we have some staticlibs that get linked together into a shared lib. yeah, hm. right.

delroth commented

2024-05-29 12:51:41 +00:00

Member

Blocked on #359 (most likely).

Blocked on https://git.lix.systems/lix-project/lix/issues/359 (most likely).

delroth commented

2024-05-29 14:07:11 +00:00

Member

Also, is static builds availability something that should block release? I'd be tempted to say it's a major regression tbf.