Quoting Alexandre Rossi (2020-06-08 20:15:32)
> > > > Sorry, I was too fast - indeed we don't do the above (we do not
> > > > probe for and tie to a specific package version) - but I am
> > > > confused: why is it not reliable to use the provided ABI?
> > >
> > > The uwsgi-plugin-php is a sort o
Maybe keep the patch until the PHP-defaults migrates and then you can drop
it? The migration is getting stuck on various different autopkgtests, so I
actually don’t know why it hasn’t migrated yet.
Ondrej
On Mon, 8 Jun 2020 at 20:18, Alexandre Rossi wrote:
> Hi,
>
> > > > Sorry, I was too fast
Hi,
> > > Sorry, I was too fast - indeed we don't do the above (we do not
> > > probe for and tie to a specific package version) - but I am
> > > confused: why is it not reliable to use the provided ABI?
> >
> > The uwsgi-plugin-php is a sort of special case, as the phpapi-
> > can be resolved
Quoting Ondřej Surý (2020-06-05 17:13:00)
> On 5 Jun 2020, at 17:06, Jonas Smedegaard wrote:
> > Sorry, I was too fast - indeed we don't do the above (we do not
> > probe for and tie to a specific package version) - but I am
> > confused: why is it not reliable to use the provided ABI?
>
> The
> On 5 Jun 2020, at 17:06, Jonas Smedegaard wrote:
>
> Sorry, I was too fast - indeed we don't do the above (we do not probe
> for and tie to a specific package version) - but I am confused: why is
> it not reliable to use the provided ABI?
The uwsgi-plugin-php is a sort of special case, as the
[ sent again, 2 mails merged with 7bit headers to please Debian MTAs ]
Hi Ondřej,
Quoting Ondřej Surý (2020-06-05 16:20:21)
> Hi Alex,
>
> you can depend on libphp-embed and then prepare the substvars like this:
>
> echo "libphp-embed:Depends=libphp$(phpquery -V | head -1)-embed“ >
> debian/uw
Hi Alex,
you can depend on libphp-embed and then prepare the substvars like this:
echo "libphp-embed:Depends=libphp$(phpquery -V | head -1)-embed“ >
debian/uwsgi-plugin-php.substvars
and then in debian/control you would use
Depends: ${libphp-embed:Depends}
instead of
Depends: libphp-embed
A
> > I do not have much experience with shared object libraries, but as
> > libphp7.3.so and libphp7.4.so declare the same soname libphp7.so, I could
> > not find a way for uwsgi-plugin-php to explicitely reference libphp7.4.so :
> > passing -lphp7.4 to the linker still goes back to linking to libph
Quoting Alexandre Rossi (2020-06-05 12:24:12)
> > > The problem seems to be that the PHP plugin is compiled against PHP7.4
> > > and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in
> > > sid.
> > >
> > > $ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php
> > > libphp7.so =>
> > The problem seems to be that the PHP plugin is compiled against PHP7.4
> > and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in sid.
> >
> > $ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php
> > libphp7.so => /usr/lib/libphp7.so (0x7f4b8ca48000)
> > $ ls -l /usr/lib/
Quoting Alexandre Rossi (2020-06-04 16:08:26)
> The problem seems to be that the PHP plugin is compiled against PHP7.4
> and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in sid.
>
> $ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php
> libphp7.so => /usr/lib/libphp7.so (0x000
The problem seems to be that the PHP plugin is compiled against PHP7.4
and is linked with libphp.so which points to 7.3 in bullseye and 7.4 in sid.
$ ldd /usr/lib/uwsgi/plugins/php_plugin.so | grep php
libphp7.so => /usr/lib/libphp7.so (0x7f4b8ca48000)
$ ls -l /usr/lib/libphp7.so
lrwxrwxrwx 1
Package: uwsgi-plugin-php
Version: 2.0.18+20200523+1+0.0.8
Severity: normal
Hi,
CI fails in bullseye. The relevant part of the log[1] is:
!!! uWSGI process 13224 got Segmentation Fault !!!
*** backtrace of 13224 ***
uwsgi(uwsgi_backtrace+0x2a) [0x55f6838d06aa]
uwsgi(uwsgi_segfaul
13 matches
Mail list logo
