Hi Andreas, qui 22 ago 2024 às 11:50:56 (1724338256), andr...@enge.fr enviou: > Am Wed, Aug 21, 2024 at 10:43:05PM +0200 schrieb Ludovic Courtès: > > To me, that’s the last blocker, even though there’s room for improvement > > here and there (for instance, FFmpeg currently fails to build on > > i686-linux). > > Just so that others do not have to repeat my check: ffmpeg fails to find > openal in the configure phase for i686: > ld: /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.o: in function > `check_alGetError': > test.c:(.text+0x1): undefined reference to `alGetError' > collect2: error: ld returned 1 exit status > check_lib openal AL/al.h alGetError -lopenal > check_func_headers AL/al.h alGetError -lopenal > test_ld cc -lopenal > test_cc > BEGIN /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.c > 1 #include <AL/al.h> > 2 #include <stdint.h> > 3 long check_alGetError(void) { return (long) alGetError; } > 4 int main(void) { int ret = 0; > 5 ret |= ((intptr_t)check_alGetError) & 0xFFFF; > 6 return ret; } > END /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.FrPUM7mP/test.c >
This is not the whole story. ffmpeg's configure script tries different library search paths incantations and this error refers to when it tries with no command line arguments. On some other tries it actually finds openal and alGetError, but then it aborts with the following linking error: ld: /tmp/guix-build-ffmpeg-6.1.1.drv-0/ffconf.fLOeyoSu/test.o: non-canonical reference to canonical protected function `alGetError' in /gnu/store/j4qdsqxb95yllkby0w2dx6d9lib24zmn-openal-1.23.1/lib/libopenal.so ld: failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status Searching for it, it seems this was previously a runtime error, that now fails at compile time[1] and is due to the pointer type cast when referencing alGetError on line 5 above and the segmented memory model of x86. Notice that this code snippet is run for all libraries and on the ones I've checked that have no issues linking the protection is default: $ LANG=C readelf -a /gnu/store/3b65jkdm5ip7j9j0xarzpp8iyqfgq0m7-x265-3.5/lib/libx265.so.199 | grep x265_api_get 827: 0009d500 322 FUNC GLOBAL DEFAULT 12 x265_api_get_199 or $ LANG=C readelf -a /gnu/store/8f9irjzk1zcg8z97p4zw239hnqn0plqk-xvid-1.3.7/lib/libxvidcore.so.4.3 | grep xvid_global 33: 00015790 4010 FUNC GLOBAL DEFAULT 12 xvid_global while on openal it is 'protected': $ LANG=C readelf -a /gnu/store/j4qdsqxb95yllkby0w2dx6d9lib24zmn-openal-1.23.1/lib/libopenal.so.1.23.1 | grep alGetErro 000fd45c 0000f001 R_386_32 00026a80 alGetError 240: 00026a80 246 FUNC GLOBAL PROTECTED 12 alGetError Since, however, pointer equality is not needed as the above code only tries to check if it can get a non null pointer to the given function and the code is not meant to be run, I believe it would be safe in this case to bypass this safety check[2] and force configure to succeed (we already now that openal was found). So I've bypassed this check here by adding a 'true' clause and then it configures and builds fine. However, when running tests it fails the checkasm_audiodsp test with the following error: checkasm: using random seed 3387428695 SSE: - audiodsp.audiodsp [OK] SSE2: - audiodsp.audiodsp [OK] SSSE3: audiodsp.vector_clip_int32_ssse3 (audiodsp.c:112) - audiodsp.audiodsp [FAILED] checkasm: 1 of 4 tests have failed threads=1 This _could_ be a hardware error here, but line 112 of audiodsp.c is also doing some pointer comparison and, well it's doing some audio vector thingy so afaik it could also be related. So what I'm tending to now is to create a separate openal-for-ffmpeg package definition, patching its CMakeLists.txt at line 350 whe it tries to check if gcc has protected or default visibility support, remove that setting and conditionaly enable this alternate package when building on i686. Does that make sense? I'll try that and report back if no one shows a better solution[3]. Cheers, 1. https://sourceware.org/bugzilla/show_bug.cgi?id=28875 2. https://sourceware.org/bugzilla/show_bug.cgi?id=29512 3. AKA, is there a similar simple and effetive test for dynamic symbols that does not rely on pointer references?