| 16 Jan 2024 |
 raitobezarius | it cross compiled from x86_64-linux to your platform | 03:52:25 |
| raitobezarius | because you don't want a native evaluation | 03:52:30 |
| raitobezarius | you want a cross evaluation | 03:52:33 |
| raitobezarius | so my localSystem is x86_64-linux | 03:52:37 |
 samueldr | plausible | 03:52:41 |
| raitobezarius | that's why I had to fiddle with a lot of stuff | 03:52:50 |
| raitobezarius | because you don't have a bootstrap on your platform, do you? | 03:52:56 |
| raitobezarius | so if I tried a native evaluation, everything would fail | 03:53:00 |
| raitobezarius | because you don't even have Nix on your thing | 03:53:04 |
| samueldr | oh right... I looked at attr, not name | 03:53:08 |
| raitobezarius | yep | 03:53:12 |
| raitobezarius | you can see the outPath | 03:53:18 |
| raitobezarius | it contains your target system | 03:53:22 |
| samueldr | yeah, it's my bad | 03:53:33 |
| raitobezarius | but Hydra setup will be much better than all those hacks, so I advise you to do it nonetheless | 03:53:37 |
| samueldr | did you offer just an eval or is there a build following on? | 03:53:44 |
| raitobezarius | it was just a nix-eval-jobs :P | 03:53:56 |
| samueldr | (no worries either way) | 03:54:00 |
| raitobezarius | dispatching them to the builder would be kinda annoying tbh | 03:54:09 |
| raitobezarius | I'd need to push the curses and I'm not confident they would carry onto the build | 03:54:18 |
| raitobezarius | (because hydra will have a different way of doing the evaluation) | 03:54:29 |
| raitobezarius | don't hesitate to poke me later if you need stuff | 03:55:36 |
|  jshcmpbll joined the room. | 07:18:48 |
| 17 Jan 2024 |
| samueldr | I've been thinking about B-right/V and how to help it out a bit produce working things... so one of the main "issues" is that it is not a unix, so many assumptions fail in programs...
... but it does have a unixemu runtime / alternative set of libraries implementing a lot of unixness.
so the main problem(s) I'm seeing here is as follows:
- I need the produced gcc to work either with the default libg (their libc) or with unixemu
- the produced gcc needs to links to something to work... but I guess it's fine if it links to
unixemu stuff? (see follow-ups)
- using the
specs files to fix default linking might not be the proper solution here
that is because I would like to, somehow, have:
- The default
stdenv assume linking with unixemu things (just a few CFLAGS/LDFLAGS
- A
brightv.sdkStdenv that turns of that knob and adds the "non-unixemu" flags
so I guess I need to find a way to get the cross gcc built without patching in the "brightv-flavoured" environment, and without somehow tainting the stdenvwtih whatever workarounds that implies using | 21:17:41 |
| samueldr | * I've been thinking about B-right/V and how to help it out a bit produce working things... so one of the main "issues" is that it is not a unix, so many assumptions fail in programs...
... but it does have a unixemu runtime / alternative set of libraries implementing a lot of unixness.
so the main problem(s) I'm seeing here is as follows:
- I need the produced gcc to work either with the default libg (their libc) or with unixemu
- the produced gcc needs to links to something to work... but I guess it's fine if it links to
unixemu stuff? (see follow-ups)
- using the
specs files to fix default linking might not be the proper solution here
that is because I would like to, somehow, have:
- The default
stdenv assume linking with unixemu things (just a few CFLAGS/LDFLAGS
- A
brightv.sdkStdenv that turns of that knob and adds the "non-unixemu" flags
so I guess I need to find a way to get the cross gcc built without patching in the "brightv-flavoured" environment, and without somehow tainting the stdenv with whatever workarounds that implies using | 21:17:52 |
| samueldr | is there anything in there that sounds incorrect? | 21:18:25 |
| samueldr | * I've been thinking about B-right/V and how to help it out a bit produce working things... so one of the main "issues" is that it is not a unix, so many assumptions fail in programs...
... but it does have a unixemu runtime / alternative set of libraries implementing a lot of unixness.
so the main problem(s) I'm seeing here is as follows:
- I need the produced gcc to work either with the default libg (their libc) or with unixemu
- the produced gcc needs to links to something to work... but I guess it's fine if it links to
unixemu stuff? (see follow-ups)
- using the
specs files to fix default linking might not be the proper solution here
that is because I would like to, somehow, have:
- The default
stdenv assume linking with unixemu things (just a few CFLAGS/LDFLAGS
- A
brightv.sdkStdenv that turns off that knob and adds the "non-unixemu" flags
so I guess I need to find a way to get the cross gcc built without patching in the "brightv-flavoured" environment, and without somehow tainting the stdenv with whatever workarounds that implies using | 21:20:26 |
| 25 Jan 2024 |
|  @axolotl:the-apothecary.club joined the room. | 05:52:37 |
| 27 Jan 2024 |
|  Jack changed their display name from Jack to Jackoe. | 01:59:36 |
|  @lehmanator:gnulinux.club removed their profile picture. | 16:53:48 |
