| 26 Mar 2025 |
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 |
n3tcat | I'm using -m68000 and I've tried playing around with the -march flags. It seems like my actual code compiles just fine but it's almost like the __whatever helpers are being compiled for the wrong CPU | 20:17:27 |
n3tcat | test.bin: test.o Linker.ld
m68k-unknown-none-elf-gcc -T Linker.ld -o test.bin -O2 -m68000 -Wall -Wextra -nostdlib test.o -ffreestanding -lgcc
%.o: %.c
m68k-unknown-none-elf-gcc -m68000 -c $< -o $@ -ffreestanding -nostdlib -O0 -Wall -Wextra -fno-PIC -static-libgcc
Here's my makefile btw | 20:17:43 |
K900 | Oh | 20:18:27 |
K900 | Yeah that could be it | 20:18:31 |
K900 | If those are coming from newlib | 20:18:37 |
K900 | And newlib is using a wrong -march too | 20:18:44 |