| 19 Jan 2024 |
 raitobezarius | not a stdenv person per se but you have my approval | 22:04:54 |
| 20 Jan 2024 |
 ris_ | i may have to just take the merge-and-apologize approach | 16:29:29 |
| raitobezarius | I think so | 16:29:41 |
| 21 Jan 2024 |
| ris_ | merging before i lose my nerve | 13:32:31 |
 hexa | not much review happening among the code owners here 🫠| 14:06:19 |
| hexa | so how can you "own" the code? | 14:06:42 |
| hexa | * so how can you "own" the code then? | 14:06:45 |
| ris_ | next one https://github.com/NixOS/nixpkgs/pull/282638 | 21:20:58 |
| 22 Jan 2024 |
|  stigo joined the room. | 01:37:33 |
 a-n-n-a-l-e-e | not sure if this is the correct room but... I've been looking into some issues with llvm and darwin -- specifically, why libcxx segfaults in older macos and why libcxxabi is not re-exported by libcxx, eg: why -lc++abi is required for linking. according to https://github.com/llvm/llvm-project/issues/78860 building libcxx and libcxxabi separately is unsupported and the root cause of these since llvm-12 (2022). my question is -- what benefit are we getting in separating libcxx and libcxxabi into different components? | 18:23:33 |
| raitobezarius | #compilers:nixos.org seems better but people from there are kinda here too | 18:25:31 |
| raitobezarius | I'd suggest to find who created the separation (if it's not done since the beginning) and ask explicitly this person about this | 18:26:15 |
| raitobezarius | I'd naively believe that separating libcxx / libcxxabi is good practice because those are two different components and they deserve to be two different storepaths | 18:26:36 |
| a-n-n-a-l-e-e | i thought that the llvm components were provided separately but later combined into a monorepo however i may be mistaken -- need to dig a little deeper. | 18:27:39 |
| raitobezarius | the source code is a monorepo | 18:28:09 |
| raitobezarius | but we do fanout all of that in multiple different derivations | 18:28:16 |
| raitobezarius | we do even filter the monorepo to keep only the trees we care about | 18:28:30 |
| raitobezarius | if it makes sense to build libcxxabi altogether:
- all the time
- only for Apple
it's something that can be hacked in the relevant machinery to support it, I'd say?
| 18:29:21 |
| a-n-n-a-l-e-e | i thought that the monorepo happened sometime around llvm11. | 18:29:41 |
| raitobezarius | ah you are talking about the history | 18:30:26 |
| a-n-n-a-l-e-e | yes. | 18:30:33 |
| raitobezarius | It was not clear you were answering to 2nd line | 18:30:39 |
| raitobezarius | but yeah I understand that there were a separation because it was natural | 18:31:43 |
| raitobezarius | I wonder if it still makes sense to keep that separation | 18:31:48 |
| raitobezarius | as in, do anyone get meaningful advantage from overriding libcxxabi without touching the rest | 18:31:58 |
| a-n-n-a-l-e-e | right -- that sums up my question. if i end up combining them for darwin the code would be easier if i could do the same for all platforms. | 18:36:12 |
| raitobezarius | I'm definitely not competent enough to answer it, alas | 18:36:40 |
| a-n-n-a-l-e-e | thanks for chiming in. perhaps it is best if i also create an issue though, except for you approving and merging a backport (thanks), i haven't had any feedback from any llvm maintainers pinged in previous issue or PR, though perhaps that is just due to them being darwin only. | 18:44:41 |
| raitobezarius | Yeah, for Darwin, Reckrenode is more the person for LLVM | 18:47:52 |
| raitobezarius | I prefer to work on the x86/RISC-V/UEFI (lol) aspect of LLVM and I don't have a deep understanding like many other maintainers | 18:48:25 |
