!ayCRiZriCVtuCUpeLp:nixos.org

Nix Cross Compiling

484 Members
101 Servers

Load older messages

SenderMessageTime
21 Apr 2025
@tealquaternion:matrix.orgtealquaternion joined the room.13:27:04
@emilazy:matrix.orgemily we set PKG_CONFIG etc. variables for cross 13:44:17
@grimmauld:grapevine.grimmauld.deGrimmauld (any/all)https://github.com/NixOS/nixpkgs/pull/400430/files#diff-def63f7c5751b7e899bdb59c3eea509acb9e4bac8a02a281ec588127c37b988cR16-R19 yeah, marcin-serwin saw the issue and i got it fixed13:48:38
@grimmauld:grapevine.grimmauld.deGrimmauld (any/all)Now all of apparmor supports cross, LLVM, and Musl13:49:20
@emilazy:matrix.orgemilypackaging looks clean, nice13:54:56
@grimmauld:grapevine.grimmauld.deGrimmauld (any/all)Thank you, better than whatever this was: https://github.com/NixOS/nixpkgs/blob/nixos-unstable/pkgs/os-specific/linux/apparmor/default.nix But i do expect some review to still come along and request some change because of some oversight. Building my system against this is not viable as it rebuilds systemd and dbus14:05:41
@emilazy:matrix.orgemilythere comes a time in every Nixpkgs contributor's life where they must purchase a Big Computer14:06:20
@9lore:tchncs.de9lore joined the room.15:18:56
@rosssmyth:matrix.orgrosssmyth I have a job that runs my builds against latest unstable each weekend, and this weekend the bump from GCC 14.2.1 20241116 to GCC 14.2.1 20250322 has changed something with relocations as I now get a bunch of dangerous relocation: unsupported relocation. Mainly because relocations are not supported on the target I used (arm-embedded, armv6-m), but I pass in hardeningDisable = [ "all" ];. I expected something to break due to the bump based upon that issue about GCC breakage, but not this. Anyone have any ideas what may have changed? 16:42:03
@rosscomputerguy:matrix.orgTristan Ross
In reply to @rosssmyth:matrix.org
I have a job that runs my builds against latest unstable each weekend, and this weekend the bump from GCC 14.2.1 20241116 to GCC 14.2.1 20250322 has changed something with relocations as I now get a bunch of dangerous relocation: unsupported relocation. Mainly because relocations are not supported on the target I used (arm-embedded, armv6-m), but I pass in hardeningDisable = [ "all" ];. I expected something to break due to the bump based upon that issue about GCC breakage, but not this. Anyone have any ideas what may have changed?
What derivation broke? 		17:17:44
@rosscomputerguy:matrix.orgTristan RossDo you have an easy reproducer?17:17:58
@rosssmyth:matrix.orgrosssmyth

So far I have not been able to make one. All of the unsupported relocations are from libc.a. So functions like memset, memcpy, and such. So they all look something like this

 /nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/7d1fw0l1akklgigbf3kwah5as1bwic1q-arm-none-eabi-gcc-14.2.1.20250322/lib/gcc/arm-none-eabi/14.2.1/libgcc.a(_divsi3.o)(__aeabi_idiv): Unknown destination type (ARM/Thumb) in /build/ccdF1k4g.ltrans0.ltrans.o
       > /build/source/build/../Firmware.cydsn/main.c:285:(.text.main+0x8a): dangerous relocation: unsupported relocation

I'll mess around some more this afternoon to see if I can get a minimal reproducer.

18:02:38
@rosssmyth:matrix.orgrosssmyth *

So far I have not been able to make one. All of the unsupported relocations are from libc.a. So functions like memset, memcpy, and such. So they all look something like this

>  /nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/7d1fw0l1akklgigbf3kwah5as1bwic1q-arm-none-eabi-gcc-14.2.1.20250322/lib/gcc/arm-none-eabi/14.2.1/libgcc.a(_divsi3.o)(__aeabi_idiv): Unknown destination type (ARM/Thumb) in /build/ccdF1k4g.ltrans0.ltrans.o
> /build/source/build/../Firmware.cydsn/main.c:285:(.text.main+0x8a): dangerous relocation: unsupported relocation

I'll mess around some more this afternoon to see if I can get a minimal reproducer.

18:02:51
@trofi:matrix.org@trofi:matrix.org ltrans suggests these are LTO builds. 21:30:03
@trofi:matrix.org@trofi:matrix.org Do you have a reproducer? Chances are ld did not have a correct linker plugin present. 21:30:23
@trofi:matrix.org@trofi:matrix.org * Chances are ld did not have a correct linker plugin present. 21:30:46
@rosssmyth:matrix.orgrosssmyth

Disabling LTO results in less errors. But the build also fails earlier in the build process.

/nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/if1f5yqlmkg278bgv69cn5hr85453jqr-newlib-arm-none-eabi-4.5.0.20241231/arm-none-eabi/lib/libc.a(libc_a-me>
/build/source/build/../Firmware.cydsn/main.c:118:(.text.main+0x46): dangerous relocation: unsupported relocation
21:41:58
@rosssmyth:matrix.orgrosssmyth *

Disabling LTO results in less errors. But the build also fails earlier in the build process.

> /nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/if1f5yqlmkg278bgv69cn5hr85453jqr-newlib-arm-none-eabi-4.5.0.20241231/arm-none-eabi/lib/libc.a(libc_a-memset.o)(memset): Unknown destination type (ARM/Thumb) in Firmware.cydsn/out.elf.p/main.c.o
> Firmware.cydsn/out.elf.p/main.c.o: in function `main':
> /build/source/build/../Firmware.cydsn/main.c:242:(.text.main+0x4e): dangerous relocation: unsupported relocation
21:46:00
@rosssmyth:matrix.orgrosssmyth *

Disabling LTO removes the references to ltrans, but the same errors result.

> /nix/store/brk34m9rvyw1vw94w0k7gadwj4s1lih3-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/if1f5yqlmkg278bgv69cn5hr85453jqr-newlib-arm-none-eabi-4.5.0.20241231/arm-none-eabi/lib/libc.a(libc_a-memset.o)(memset): Unknown destination type (ARM/Thumb) in Firmware.cydsn/out.elf.p/main.c.o
> Firmware.cydsn/out.elf.p/main.c.o: in function `main':
> /build/source/build/../Firmware.cydsn/main.c:242:(.text.main+0x4e): dangerous relocation: unsupported relocation
21:46:47
22 Apr 2025
@trofi:matrix.org@trofi:matrix.org Aha. Can you have a look what relocation is that? arm-none-eabi-objdump -dr should have an entry around .text.main+0x4e 04:56:34
@rosssmyth:matrix.orgrosssmyth 
4e:   f7ff fffe       bl      0 <memset>
                        4e: R_ARM_THM_CALL      memset
13:20:19
@rosssmyth:matrix.orgrosssmythRedacted or Malformed Event13:20:54
@rosssmyth:matrix.orgrosssmyth * 
0000004e R_ARM_THM_CALL    memset
13:22:31
@dramforever:matrix.orgdramforever i think i figured out a possible cause. your code might be defining memset in assembly, but did not specify the symbol type as a function. therefore, the linker is refusing to emit a call to it because some paranoia about mixing arm and thumb functions. 13:51:19
@dramforever:matrix.orgdramforever if that's the case, you need to use .type memset, %function in your assembly code, and possibly all other functions as well 13:51:42
@dramforever:matrix.orgdramforeverthis is a new check added in binutils 2.44 https://github.com/bminor/binutils-gdb/commit/31ed3a9d691493486f6e32357d89a55229dbdc0a#diff-9db1c8e03c72939d28438bba610afca27de21c37dda3d09639a8b531a5610902R1050813:55:20
@dramforever:matrix.orgdramforever

this should reproduce the "issue"

$ cat thm.s
    bl nothing
$ cat nothing.s
    .global nothing
nothing:
$ arm-none-eabi-gcc -march=armv6-m -o thm thm.s nothing.s
/nix/store/[...]-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /nix/store/[...]-newlib-arm-none-eabi-4.5.0.20241231/arm-none-eabi/lib/crt0.o: in function `_mainCRTStartup':
/build/newlib-4.5.0.20241231/arm-none-eabi/libgloss/../.././libgloss/arm/crt0.S:546:(.text+0x10c): undefined reference to `main'
/nix/store/[...]-arm-none-eabi-binutils-2.44/bin/arm-none-eabi-ld: /tmp/cceLKLqP.o(nothing): Unknown destination type (ARM/Thumb) in /tmp/ccAnIzhk.o
/tmp/ccAnIzhk.o:(.text+0x0): dangerous relocation: unsupported relocation
[...]
13:58:21
@dramforever:matrix.orgdramforevermostly unrelatedly, but the worst part about trying to debug this issue is element defaulted to not line wrapping code14:04:10
@rosssmyth:matrix.orgrosssmythThat's interesting. I do not define them in asm, I just use the newlib(-nano) provided ones. I just checked and it seems they do use the correct type for their asm defined functions. 14:17:37
@dramforever:matrix.orgdramforever
In reply to @rosssmyth:matrix.org
That's interesting. I do not define them in asm, I just use the newlib(-nano) provided ones. I just checked and it seems they do use the correct type for their asm defined functions.
are you using pkgsCross.arm-embedded? in that case the nanolib is compiled for arm and would not work for armv6-m 		14:28:08

Show newer messages

Back to Room ListRoom Version: 6