[Buildroot] [PATCH 3/3] package/php: enable opcache jit

[Arnout Vandecappelle]

On 05/08/2021 18:27, Arnout Vandecappelle wrote:
> 
> 
> On 05/08/2021 16:47, Pascal de Bruijn wrote:
>> Hey,
>>
>>>     > In ed355dec (PATCH 2/3) the following line is what makes opcache actually
>>>     work:
>>>
>>>     What is ed355dec ? I don't have any commit with that reference in
>>>     Buildroot. If it's the reference of the commit of PATCH 2/3 in your
>>>     Buildroot Git repository, then it doesn't make sense to reference it,
>>>     as this commit won't have the same hash when we'll apply your patch,
>>>     i.e ed355dec means nothing expect just to you locally.
>>
>> I know, which is why I referenced both. So I'm referencing the second of three
>> patches in my recently submitted series regarding package/php.
>>
>>>     > PHP_CHECK_LIBRARY(rt, shm_unlink,
>>>     [PHP_ADD_LIBRARY(rt,1,OPCACHE_SHARED_LIBADD)])
>>>
>>>     And what is this doing ? Again shm_unlink() is no longer in librt, it's
>>>     in libc since glibc 2.17 (if I remember correctly).
>>
>> PHP_CHECK_LIBRARY(rt, shm_unlink, [PHP_ADD_LIBRARY(rt,1,OPCACHE_SHARED_LIBADD)])
>> is executed for non-cross-compiles, and with my patch also executes for
>> cross-compiles.
>>
>> Though I haven't looked deeply into the PHP specific autotools macros...
>> https://github.com/php/php-src/blob/PHP-8.0.9/build/php.m4#L1507
> 
>  This bit is indeed useless with modern glibc, but all libc still install an
> (empty?) librt for backward compatibility, so it doesn't hurt either.

 But now I think more about it: how does this patch make it succeed at runtime?
Unless you are indeed using an ancient glibc, it should do exactly nothing. Or
is it the define of HAVE_SHM_MMAP_POSIX (also added by patch 2/3) that makes the
difference?

 Regards,
 Arnout