| 26 Mar 2025 |
 K900 | The original version control system | 20:47:56 |
| K900 | CVS to SVN is what SVN is to hit | 20:48:15 |
| K900 | * CVS to SVN is what SVN is to git | 20:48:24 |
| K900 | Roughly | 20:48:26 |
| K900 | But also looks like they have mailing lists | 20:48:32 |
| K900 | https://sourceware.org/newlib/ | 20:48:34 |
| K900 | I don't know how active they are though | 20:48:43 |
 n3tcat | oh no | 20:48:44 |
| n3tcat | How bad would it be to just open a PR to nixpkgs with your patch? I am not sure how much I want to deal with newlib stuff | 20:49:10 |
| K900 | Uhhh | 20:49:44 |
| K900 | I mean you can | 20:49:56 |
| K900 | But generally I think if the upstream is at least somewhat alive, it's worth it to reach out | 20:50:22 |
| K900 | Because it both makes things easier for the commons | 20:50:36 |
| n3tcat | Okay I'll do my best | 20:50:41 |
| K900 | And makes things easier for nixpkgs long term | 20:50:42 |
| K900 | But also especially with those older crustier upstreams it's often easier to talk to people first before you throw a patch over the fence | 20:51:33 |
 emily | SCCS and RCS disliked this post. | 20:57:34 |
| 28 Mar 2025 |
 Kamilla 'ova | Hi, qt6 cross is still not supported? | 15:23:43 |
| Kamilla 'ova | Or maybe there were attempts to fix it? After mine in August 2024 | 15:25:10 |
| K900 | I don't think there have been any | 15:26:21 |
| K900 | 6.9 has some build system changes that might help? | 15:26:28 |
| K900 | But I really don't have the spoons to commit to it | 15:26:43 |
| Kamilla 'ova | If they removed shitty libraries search in qtmultimedia, that would be good | 15:27:55 |
| K900 | I do however have a PR that gets 6.9 building | 15:27:57 |
| K900 | github.com/NixOS/nixpkgs/pull/393655 | 15:27:58 |
| K900 | * https://github.com/NixOS/nixpkgs/pull/393655 | 15:28:02 |
| K900 | (on native) | 15:28:07 |
|  scottytheengineer joined the room. | 18:15:50 |
| n3tcat | K900 Alright this may be a NixOS related cross compiling question but maybe not.
I have a very simple C program that looks like this:
void _start() {
volatile long *a = (long *)0x1FFA0;
volatile long *b = (long *)0x1FFA8;
volatile long *c = (long *)0x1FFB0;
*c = *b / *a;
for(;;) {}
}
This relies on doing software division (the actual hardware instruction can only do 32 bit / 16 bit -> 16 bit or something like that). So it calls __divsi3.
__divsi3 seems to be compiled incorrectly. It tries to use a BSR.L instruction, which doesn't exist on the m68k. It only has the BSR.W and BSR.B instructions. I am wondering what I would need to do to fix this
| 20:16:07 |
| K900 | Maybe you need the right -march? | 20:16:52 |
