| 18 Sep 2021 |
 sterni | I guess GNU binutils on aarch64-darwin are a problem, but honestly, I couldn't care less | 12:09:20 |
| sterni | * I guess GNU binutils on aarch64-darwin are a problem (since strip needs to sign apparently?), but honestly, I couldn't care less | 12:09:33 |
 Alyssa Ross | yeah let somebody else worry about that | 12:10:36 |
 Mic92 | What does homebrew uses for linking? | 16:06:01 |
| sterni | pkgsLLVM.libgcc now somehow ends up with llvm-bintools somewhere lol | 23:46:11 |
| sterni | okay, that's not accurate, rather building the gcc cross toolchain for that fails because we have llvm-bintools somewhere in there | 23:47:37 |
| sterni | ugh:
[
"--with-as=${targetPackages.stdenv.cc.bintools}/bin/${targetPlatform.config}-as"
"--with-ld=${targetPackages.stdenv.cc.bintools}/bin/${targetPlatform.config}-ld"
]
| 23:53:39 |
| sterni | this is in the gcc configure flag thing | 23:54:19 |
| sterni | John Ericson: can we get rid of that (🔼) somehow? It's kind of terrible that gcc(-unwrapped) inspects targetPackages.stdenv and thus bypasses the wrapper later completely | 23:55:41 |
| sterni | Specifically this breaks pkgsLLVM.gccStdenv atm since it'll be configured to use the llvm-as which doesn't understand some flags gcc's configure script will inevitably pass to it | 23:56:24 |
| sterni | hm the gcc derivation seems to assume that the next stage also uses gcc as its default compiler in general | 23:58:05 |
| 19 Sep 2021 |
 John Ericson | sterni can't talk much now, but you could take the gccNG patch I made that causes it to look up prefixed binaries in -B directories. Then we can get rid of those two --with flags altogether I believe. | 00:35:52 |
| sterni | interesting, I also wonder why it started to become a problem just now, since that used to work | 18:51:54 |
| sterni | e. g. pkgsLLVM.libgcc etc. was possible to compile iirc | 18:52:09 |
| 20 Sep 2021 |
| Alyssa Ross | Has anybody ever come across a better solution than this when dealing with the combination of pkgsStatic, C++, and libtool? https://github.com/NixOS/nixpkgs/pull/103270/files | 15:41:11 |
| Alyssa Ross | cc sternenseemann Ericson2314 | 15:41:15 |
| John Ericson | I do not know | 15:45:46 |
| John Ericson | maybe after gccNg I will know more about these things :/ | 15:45:59 |
| Alyssa Ross | I've hit this sort of issue twice today | 15:46:24 |
| Alyssa Ross | the first package also offered a CMake build so I just switched it to CMake | 15:46:33 |
| John Ericson | i have no yet had to learn just how libtool is so crazy yet | 15:48:08 |
| John Ericson | * i have no yet had to learn just how libtool is so crazy | 15:48:13 |
| Alyssa Ross | tbh I think this might be a problem we introduce in our own libtool modifications | 15:51:46 |
| Alyssa Ross | Hmm, I was sure we modified libtool to make it use absolute paths, but I can't find it now | 15:55:02 |
| Alyssa Ross | oh no I'm thinking of gobject-introspection | 15:55:22 |
| John Ericson | the other fun one :) | 15:58:34 |
 Rick (Mindavi) | Still waiting on upstream to review the patches... | 16:01:24 |
| Alyssa Ross | libtool is my second least favourite thing to debug after cmake | 16:44:19 |
| Alyssa Ross | if a cmake-based package doesn't cross-compile i usually just give up | 16:44:47 |
| Rick (Mindavi) | CMake doesn't really have a concept for mixed arch compilation | 16:52:30 |
