| 26 Mar 2025 |
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 |
K900 | And you're just linking an already built newlib | 20:18:58 |
n3tcat | I think they might be? I am not entirely sure what -lgcc and -static-libgcc do - I assume they link into newlib | 20:19:12 |
K900 | No, that's libgcc | 20:19:31 |
K900 | But it could be the same thing | 20:19:45 |
K900 | Uhh there is a setting for this | 20:20:37 |