Re: Merging ‘core-updates’ real soon

[André Batista]

Hi Andreas,

qui 22 ago 2024 às 11:50:56 (1724338256), andreas@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?