On 2013-03-31, Scott Vanderbilt <li...@datagenic.com> wrote:
> On 3/31/2013 4:59 AM, Stuart Henderson wrote:
>> On 2013-03-30, Scott Vanderbilt <li...@datagenic.com> wrote:
>>> So I copy all of these libraries into the paths specified by ldd, taking
>>> the chroot into account. Here is where the libraries ended up:
>>
>> Did you copy in ld.so?
>
> I had not, but at your kind suggestion, I copied
>
> /usr/libexec/ld.so
>
> to what is presumably the correct destination:
>
> /var/www/usr/libexec/ld.so
>
> Restarted php-fpm and re-submitted my request. Again, alas, same error.
Aha: by copying the /usr/bin/sqlite3 CLI into /var/www/usr/bin and playing
around with "sudo LD_DEBUG=1 chroot /var/www /usr/bin/sqlite3" I've worked
out what's needed.
You were on the right tracks but the missing piece is that you don't have
/var/run/ld.so.hints inside the chroot. You could copy in ldconfig and
prepare one, but the easiest way is to place all the needed libraries into
/var/www/usr/lib so that when you're inside the jail, they're reachable
in the default library search path.
$ ls /var/www/usr/{lib,libexec,bin}
/var/www/usr/bin:
sqlite3
/var/www/usr/lib:
libc.so.67.0 libgeos.so.7.1 libm.so.8.0
libreadline.so.3.0 libstdc++.so.55.0
libcurses.so.12.1 libgeos_c.so.4.0 libproj.so.6.0
libspatialite.so.0.0
libfreexl.so.0.0 libiconv.so.6.0 libpthread.so.17.0
libsqlite3.so.22.0
/var/www/usr/libexec:
ld.so
... I bet this will work for PHP too. (fwiw I used the script in
/usr/ports/www/horde/chora/files/copywithlibs.sh to copy things
across, in my case running it twice: one for sqlite3, one for
libspatialite.so.0.0).
> This is a complete WAG from someone with zero qualifications to be
> making conjectures, but might it have something to do with a recent
> change I saw posted to openbsd-ports-cvs concerning libtool?
>
> <http://marc.info/?l=openbsd-ports-cvs&m=136385485307326&w=2>
>
> This change would be included in the php packages I have installed.
> Assuming, of course, that it is any way related, which it most likely is
> not. But I am clutching at straws here.
This change is basically a noop. The default value of USE_LIBTOOL in
ports was changed from NO to YES as it's quite widely used, and in
cases where libtool is not used at all it doesn't matter if this is
set to YES, this is done so porters can't forget to set USE_LIBTOOL
when it's needed.
PHP has some special version of libtool and can't be used with the
normal one, so the USE_LIBTOOL=NO setting just makes sure the change
of default doesn't affect the PHP ports.
