| 6 Feb 2024 |
 Sandro 🐧 |
Some packages will certainly break on i686 when symbols change.
How? We don't need to maintain ABI compability. What am I missing?
| 18:22:57 |
 aloisw | In reply to @sandro:supersandro.de
Some packages will certainly break on i686 when symbols change.
How? We don't need to maintain ABI compability. What am I missing?
Except for the tons of binaryNativeCode packages… | 18:26:36 |
| Sandro 🐧 | ohhh 🤔 | 18:31:13 |
 trofi | tpm2-tss overrides read(), but not read64(). File offset bits just break it's build. | 19:18:08 |
| trofi | https://github.com/tpm2-software/tpm2-tss/blob/e637b842322b1a64f9ad10af66af43d2d9328564/test/unit/tcti-device.c#L153 | 19:23:14 |
| trofi | As it goes via "-Wl,-wrap" linker hack it completely bypasses "#define read read64". | 19:24:55 |
| trofi | I would expect binary packages in less of a danger (unless there are common libraries that export unsized "off_t" and friends) | 19:26:11 |
| trofi | * tpm2-tss overrides read(), but not read64(). File offset bits just break it's tests as overrides does not happen any more. | 19:30:56 |
| 7 Feb 2024 |
|  Sean Link set a profile picture. | 20:08:43 |
| 8 Feb 2024 |
 raitobezarius | does anyone has an opinion on enabling frame pointers by default? | 16:04:15 |
| raitobezarius | I have been thinking about it for a while and Jon Seager told me about it recently and talked about it recently: https://fosdem.org/2024/events/attachments/fosdem-2024-3513-what-s-possible-in-observability-when-we-have-frame-pointers/slides/22782/2024-02_-_FOSDEM_-_frame_pointers_xaPhw1N.pdf | 16:04:42 |
| trofi | nixpkgs does not seem to focus on producing fast binaries anyway (-fPIC, -fstack-protector-strong, -fno-strict-overflow and more to be added by default: all are stealing bytes on stack, registers to manage and inxtra instructions to handle by CPU), thus might be fine :) | 16:17:57 |
| raitobezarius | neat :-) | 16:18:46 |
| raitobezarius | is it just a matter of inserting -fno-omit-frame-pointer in the stdenv, right? | 16:18:59 |
| trofi | Yeah | 16:20:00 |
| trofi | Better guard it behind an off-switch to be able to repare rare users that expect inlining and sibling call optimizations to work (like glibc early ld.so code or linux kernel's boot code). | 16:21:09 |
| aloisw | There already is https://github.com/NixOS/nixpkgs/pull/216341 btw | 18:04:02 |
| raitobezarius | yeah but it's not doing the change in cc-wrapper | 18:04:56 |
| aloisw | It should probably also be discussed how useful frame pointers are when the debug symbols have already been lost, as is seemingly very common. | 18:05:23 |
| raitobezarius | well i wouldn't make frame pointers dependent on debug symbols | 18:09:43 |
| raitobezarius | we can make frame pointers now | 18:09:49 |
| raitobezarius | and still work towards dsyms no? | 18:09:53 |
| aloisw | I wasn't saying frame pointers are useless without debug info, you can probably still get some results from the symbol table alone. | 18:12:19 |
