| 1 Jun 2023 |
 artemis | In reply to @trofi:matrix.org
If it does not help try to figure out why libtool build triggers for you (CDPATH="${ZSH_VERSION+.}:" && cd . && /nix/store/7z4pgfv4vqgfi5d894cwzj4jha47vrhr-bash-5.1-p16/bin/bash '/build/libtool-2.4.7/build-aux/missing' autoheader) do i need to be using ZSH for this idk what CDPATH is | 00:29:08 |
 trofi | No, it's the code from libtool's Makefile.in that runs unexpectedly. | 06:23:41 |
| trofi | if you have some familiarity you can investigate why make thinks it needs to run. | 06:24:05 |
| trofi | Sometimes it's enough to add "-d" to makeFlags to see why exactly the target needs an update. | 06:24:54 |
| artemis | i dont know that im good enough at nix to do that in this context | 06:31:45 |
| artemis | i usually work with more traditional package build systems tbh | 06:32:20 |
| trofi | If you do something like locally:
--- a/pkgs/development/tools/misc/libtool/libtool2.nix
+++ b/pkgs/development/tools/misc/libtool/libtool2.nix
@@ -53,0 +54 @@ stdenv.mkDerivation rec {
+ makeFlags = [ "-d" ];
you should be able to get libtool build logs with nix build -f. libtool.
| 06:34:51 |
| trofi | * If you do something like locally:
--- a/pkgs/development/tools/misc/libtool/libtool2.nix
+++ b/pkgs/development/tools/misc/libtool/libtool2.nix
@@ -53,0 +54 @@ stdenv.mkDerivation rec {
+ makeFlags = [ "-d" ];
you should be able to get libtool build logs with nix build -f. libtool.
| 06:35:11 |
| artemis | ty | 06:40:51 |
|  raphi changed their display name from raphi to raphi (element unread channel fix when). | 13:03:26 |
| artemis | trofi:
libtool-riscv64-unknown-linux-gnu> Prerequisite 'libtoolize.in' is newer than target 'doc/libtoolize.1'.
libtool-riscv64-unknown-linux-gnu> Must remake target 'doc/libtoolize.1'. | 21:32:34 |
| artemis | its not regenerating libtoolize.in though it seems like | 21:34:29 |
| artemis | libtool-riscv64-unknown-linux-gnu> Finished prerequisites of target file 'libtoolize.in'.
libtool-riscv64-unknown-linux-gnu> No need to remake target 'libtoolize.in'. | 21:34:30 |
| artemis | * its not regenerating libtoolize.in though it seems like. from earlier up the log: | 21:34:56 |
| trofi | Oh, it's a cross-compilation? | 21:34:58 |
| artemis | yeah | 21:35:04 |
| artemis | cross compiling from x86_64 to riscv64 | 21:35:41 |
| trofi | That I should be able to reproduce locally. Which package do you build? | 21:36:03 |
| trofi | (and I would expect libtoolize.in not to require a rebuild, what does log say, what triggers it's rebuild?) | 21:37:11 |
| artemis | vi@philomena ~/z/nixpkgs (nixos-22.11)> nix build -f. pkgsCross.riscv64.libtool | 21:37:14 |
| artemis | commit 9af373a61647257d16ae6062cddaa9094d24920c to be exact | 21:37:24 |
| trofi | nod, i'll try on staging-next first | 21:37:38 |
| artemis | In reply to @trofi:matrix.org
(and I would expect libtoolize.in not to require a rebuild, what does log say, what triggers it's rebuild?) nothing, it doesnt rebuild | 21:37:43 |
| artemis | look up there it says no need to remake target libtoolize.in | 21:37:53 |
| artemis | so libtoolize.in is not rebuilt. but it is newer than doc/libtoolize.1 which does rebuild | 21:38:21 |
| trofi | Aha. Then some other prerequisite is stale if it still wants to rebuild doc/libtoolize.1. Maybe a few lines earlier. | 21:38:39 |
| artemis | hmm? no it says that libtoolize.in is newer | 21:39:01 |
| artemis | and is the reason for the rebuild | 21:39:09 |
| artemis | here is the full evaluation of libtoolize.1 https://dpaste.com/G93P2BJ5X | 21:40:51 |
| trofi | Hm. If you add --keep-failed you can check both files' timestamps in temp dir. I wonder if one of them matches build time. | 21:41:53 |
