[00:03] ahasenack: so there seems to be an issue with the unaligned memory access on arm devices when building gambas3. I found the workaround for this issue: make GCC generate full-length ARM code instead of Thumb/Thumb2 compressed code on armhf [00:03] ... with: export DEB_CFLAGS_MAINT_APPEND = -marm and export DEB_CXXFLAGS_MAINT_APPEND = -marm [00:03] that's way over my head [00:04] and which gcc? gcc-11, or without that change to d/rules, using the normal gcc? [00:04] ahasenack: This works with any version of GCC [00:04] I think you want to use the default GCC (which is GCC 13) [00:04] I would prefer that, yes [00:05] ... because poppler still needs a C++20 capable compiler [00:05] and does armel still need clang then? Or can it use the same trick? [00:06] ahasenack: I am unsure what happened with armel, but I guess it can use the same trick, since Clang generates ARM-mode code by default on Ubuntu [00:08] The full story is this: ARM devices (prior to aarch64), requires aligned memory access (usually needs to be aligned on the "word boundary", in armhf situation, one word = 32 bit). gambas3 has this bright idea where it reads the file using mmap() ... [00:08] but that used to be a runtime error, no? misaligned memory access [00:09] sigbus iirc [00:09] sigbus, depending upon architecture [00:09] I haven't found the build error in the logs [00:09] ahasenack: well, it actually happened during the build, but the make flags hid the errors [00:09] arm it was an implementation choice, some processors could cope, others couldn't, and some could only cope in 32bit or in 64bit mode, something like that .. [00:10] gambas3 used a hack to remove the print out [00:10] in any event, any program doing unaligned access ought to be fixed [00:10] switch pointer assignments to memcpy :( [00:11] ... (cont'd) mmap basically tells the kernel to map the specified file description into memory and treat as a part of the memory space. However, gambas3 read the file by bytes (not by words), which generates an unaligned access [00:12] ... (cont'd) unknown identifier issue was because their Makefile was so bad that did not handle the error correctly and let the build continue [00:12] can we fix that instead? Do you know where it's happening? And how about changing the invocation commands to not hide the errors, and stop when they happen? [00:12] sarnold: In aarch64, ARM provided a way to allow unaligned memory access, so this issue does not exist on arm64 [00:13] liushuyu: I think our builders did sigbus on it though, heh [00:14] (see ARM reference manual ARM DDI 0487F.c ID072120 page E2-4044) [00:16] ahasenack: It's kind of problematic to fix, due to how gambas3 handles file I/O (it expect the kernel to map the file into the memory, and all the downstream functions just operate on the pointer that points to the virtual address [00:18] (If you want to hear another horror story about a certain package, I do have another recent one, mentioned very briefly on my +1 report) [00:19] not really, it's 21h20 here now :) [00:19] that's firmly into weekend territory! [00:19] just that 3.19.0-2ubuntu10 built on armhf before, perhaps with LocutusOfBorg's gcc-11 patch [00:19] https://launchpad.net/ubuntu/+source/gambas3/3.19.0-2ubuntu10 [00:19] and, of course, previous poppler [00:21] ahasenack: I know, it's code generation fengshui, where GCC so happens to not generate a certain instruction that requires hard memory alignment [00:22] ... but newer GCC does generate this instruction (LDRD, Load Register Dual instruction) very often to optimize memory loads (since it can read 8 bytes at a time on a 32-bit system) === stgraber is now known as Guest5653 === stgraber is now known as Guest1191 === Guest1191 is now known as stgraber === JanC is now known as Guest737 === matttbe5 is now known as matttbe