On 2/9/2018 6:02 AM, William A Rowe Jr wrote:
I will continue to work with you on this. The horrors I'm confronting
in other upstream projects... Ugh...
Please delete apr from your post to list. Unless they understand the
purpose of doing so, it is a stupid build chain to reference, an
exusible one is httpd's.
no longer included...
The httpd project is probably the wrong list to address you php concerns,
historically, php has always pointed at httpd - however...
but I'm ok with our helping you once or twice more. Good luck in your
efforts;
I think I figured it out: See https://bugs.php.net/bug.php?id=63182
(opened in 2012!!, and nothing. Older ones as well, but maybe they
closed that one ;)
For the weary: looks like: ancient libtool components (1.5.26, from
2008) and logic that might have almost been correct in 2008 (I have
actually had issues since php-4.0.4, and always libtool related).
My "fix" - while it gets the jobs done (finally) - it does not mean it
is "ASF" caused. My apologies - and thanks! for the hints that got me
looking the right area (over 100k lines in php configure - sigh).
Anyway - issue is closed - here - as far as I am concerned.
Best regards,
Michael
On Feb 8, 2018 4:19 PM, "Michael Felt" <[email protected]
<mailto:[email protected]>> wrote:
On 07-Feb-18 19:40, William A Rowe Jr wrote:
Is the sapi compiled against libtool etc. from httpd? Or is it
using the
configure logic shipped with the php package?
The sapi is compiled using php configure, etc. The install part
uses instdso.sh and apxs, instdso.sh, iirc calls the libtool built
with/by apr.
In any case, asking httpd/apr to conform to the autoconf/libtool
packaging of php, which was built using its own flavor of the
toolchain
seems inconsistent.
As I tried to say, this is something I have been trying to get
understood by whoever.
Going with your idea re: php use of the toolchain - maybe they do
something wrong, read unexpected, in the way the library_name
variable is defined. And I also wonder, new idea, maybe I need to
use the libtool argument (must look it up) to say shared library
is not aix, but svr4 style. That might fix the .la contents.
So, thx for the thoughts!
It seems foolish to ask httpd-apxs to be the install tool of
the libphp5
binary. These are two different packages with two different
sets of
tooling. If you simply fix the make install to point to the
build/install.sh
tool of php, does it all work?
On Wed, Feb 7, 2018 at 8:50 AM, Michael
<[email protected] <mailto:[email protected]>> wrote:
a) It has been a hard climb to get httpd-2.4.29 to build
using the latest
apr and apr-util. Still researching what that is (might be
expat related -
embedded versus external, still searching). Anyway,
working with apr-1.5.2 I
was at least able to get httpd-2.4.29 to build so I could
proceed to my
other "forever" hassle.
b) the forever "hassle": over the years (the first time I
posted "a bug may
be as far back as 2010", not bothering to post before then
(or it was
working??) - was getting "make install" to work for PHP.
c) PHP stated correctly - not them - would be instdso.sh.
Also posted, but
not conclusive. I hacked at instdso - as it knew what to
remove (rm -f) but
did not install. I just hard-wired it to copy the file,
if, at the end, it
was not there. With that, the chmod command that follows
instdso.sh works.
Quick History, better review:
Currently:
root@x065:[/data/prj/php/php-5.3.29]make install-sapi
Installing PHP SAPI module: apache2handler
/data/prj/php/src/php-5.3.29/build/shtool mkdir
-p /opt/bin
if test ! -r
/data/prj/php/php-5.3.29/libs/libphp5.so; then for i
in 0.0.0 0.0 0; do if test -r
/data/prj/php/php-5.3.29/libs/libphp5.so.$i;
then ln -s /data/prj/php/php-5.3.29/libs/libphp5.so.$i
/data/prj/php/php-5.3.29/libs/libphp5.so; break; fi;
done; fi
/data/prj/php/src/php-5.3.29/build/shtool mkdir -p
'/opt/httpd/libexec' &&
/data/prj/php/src/php-5.3.29/build/shtool mkdir -p
'/var/httpd/etc' && /opt/httpd/bin/apxs -S
LIBEXECDIR='/opt/httpd/libexec'
-S SYSCONFDIR='/var/httpd/etc' -i -a -n php5 libphp5.la
<http://libphp5.la>
Use of uninitialized value in concatenation (.) or string at
/opt/httpd/bin/apxs line 222.
/var/httpd/build/instdso.sh
SH_LIBTOOL='/opt/build-1/libtool' libphp5.la
<http://libphp5.la>
/opt/httpd/libexec
rm -f /opt/httpd/libexec/libphp5.so
/opt/build-1/libtool --mode=install install libphp5.la
<http://libphp5.la> /opt/httpd/libexec/
libtool: install: install .libs/libphp5.a
/opt/httpd/libexec/libphp5.a
libtool: install: install .libs/libphp5.lai
/opt/httpd/libexec/libphp5.la <http://libphp5.la>
libtool: install: warning: remember to run `libtool --finish
/data/prj/php/php-5.3.29/libs'
chmod 755 /opt/httpd/libexec/libphp5.so
chmod: /opt/httpd/libexec/libphp5.so: A file or directory
in the path name
does not exist.
apxs:Error: Command failed with rc=65536
.
make: 1254-004 The error code from the last command is 1.
**** I think I have it!! ****
With one small change: (/opt/build-1/libtool apr-1.5.2)
+3403 # See the names of the shared library.
+3404 set dummy $dlname $library_names; shift
root@x065:[/data/prj/php/php-5.3.29]make install-sapi
Installing PHP SAPI module: apache2handler
/data/prj/php/src/php-5.3.29/build/shtool mkdir
-p /opt/bin
if test ! -r
/data/prj/php/php-5.3.29/libs/libphp5.so; then for i
in 0.0.0 0.0 0; do if test -r
/data/prj/php/php-5.3.29/libs/libphp5.so.$i;
then ln -s /data/prj/php/php-5.3.29/libs/libphp5.so.$i
/data/prj/php/php-5.3.29/libs/libphp5.so; break; fi;
done; fi
/data/prj/php/src/php-5.3.29/build/shtool mkdir -p
'/opt/httpd/libexec' &&
/data/prj/php/src/php-5.3.29/build/shtool mkdir -p
'/var/httpd/etc' && /opt/httpd/bin/apxs -S
LIBEXECDIR='/opt/httpd/libexec'
-S SYSCONFDIR='/var/httpd/etc' -i -a -n php5 libphp5.la
<http://libphp5.la>
Use of uninitialized value in concatenation (.) or string at
/opt/httpd/bin/apxs line 222.
/var/httpd/build/instdso.sh
SH_LIBTOOL='/opt/build-1/libtool' libphp5.la
<http://libphp5.la>
/opt/httpd/libexec
rm -f /opt/httpd/libexec/libphp5.so
/opt/build-1/libtool --mode=install install libphp5.la
<http://libphp5.la> /opt/httpd/libexec/
libtool: install: install .libs/libphp5.so
/opt/httpd/libexec/libphp5.so
libtool: install: (cd /opt/httpd/libexec && { ln -s -f
libphp5.so libphp5.a
|| { rm -f libphp5.a && ln -s libphp5.so libphp5.a; }; })
libtool: install: (cd /opt/httpd/libexec && { ln -s -f
libphp5.so libphp5.a
|| { rm -f libphp5.a && ln -s libphp5.so libphp5.a; }; })
libtool: install: install .libs/libphp5.lai
/opt/httpd/libexec/libphp5.la <http://libphp5.la>
libtool: install: warning: remember to run `libtool --finish
/data/prj/php/php-5.3.29/libs'
chmod 755 /opt/httpd/libexec/libphp5.so
[activating module `php5' in /var/httpd/etc/httpd.conf]
**** So, I suspect the actual 'bug' is in libtool (this
embedded version was
2.4.2). FYI, the base statement (where I can fix it) is,
in apr-1.6.2, based
on libtool-2.4.6
/opt/build-1/libtool
+4800 # See the names of the shared library.
+4801 set dummy $library_names; shift
I have no clue whether prefixing $dlname is the right
approach, or that
library_names (in the .la file) is wrong.
FYI: libphp5.la <http://libphp5.la> contents:
root@x065:[/data/prj/php/php-5.3.29]cat .libs/libphp5.la
<http://libphp5.la>
# libphp5.la <http://libphp5.la> - a libtool library file
# Generated by ltmain.sh - GNU libtool 1.5.26
(1.1220.2.492 2008/01/30
06:40:56)
#
# Please DO NOT delete this file!
# It is necessary for linking the library.
# The name that we can dlopen(3).
dlname='libphp5.so'
# Names of this library.
library_names='libphp5.a libphp5.a'
# The name of the static archive.
old_library=''
# Libraries that this one depends upon.
dependency_libs=' -lz -lrt -liconv -lz -lcurl -lrt -lm
-liconv -lm -lcurl
-lssh2 -lssh2 -lz -liconv -lm -lz -lm -liconv -lm -liconv
-lm -liconv -lm
-liconv -lm -L/opt/lib -L/opt/mysql/lib -lz -lrt
-lmysqlclient -liconv
/opt/lib/libfreetype.la <http://libfreetype.la>
/opt/lib/libpng15.la <http://libpng15.la> -lz -lm -lX11
-lXpm -lpng -lz
-ljpeg -lcurl -lrt -lm -liconv -lm -lcurl -lssh2 -lssh2
-lssl -lcrypto -lz
-liconv -lm -lmysqlclient_r -lz -lnsl_r -lm -liconv -lm
-liconv -lm -liconv
-lm /opt/lib/libxml2.la <http://libxml2.la> -lpthread
-liconv -lm -liconv -lm'
# Version information for libphp5.
current=0
age=0
revision=0
# Is this an already installed library?
installed=no
# Should we warn about portability when linking against
-modules?
shouldnotlink=yes
# Files to dlopen/dlpreopen
dlopen=''
dlpreopen=''
# Directory that this library needs to be installed in:
libdir='/data/prj/php/php-5.3.29/libs'
******* So, besides sharing my "finding" that I'll just
apply locally for
php work, my question: Is there any knowledge of others
trying to use
instdso.sh with a "module" that demands a dlopen-able FILE
(as httpd does
not accept the packaging of a dlopen() archive member -
which is what is in
"the library".
root@x065:[/data/prj/php/php-5.3.29]ls -l .libs
total 60000
-rw-r--r-- 1 root 1954 15467005 Feb 06 14:39
libphp5.a
-rw-r--r-- 1 root 1954 134349 Feb 06 14:39
libphp5.exp
lrwxrwxrwx 1 root 1954 13 Feb 06 14:40
libphp5.la <http://libphp5.la> ->
../libphp5.la <http://libphp5.la>
-rw-r--r-- 1 root 1954 1261 Feb 06 14:40
libphp5.lai
-rwxr-xr-x 1 root 1954 15095281 Feb 06 14:39
libphp5.so
root@x065:[/data/prj/php/php-5.3.29]ar tv .libs/libphp5.a
rwxr-xr-x 0/1954 15095281 Feb 06 14:39 2018 libphp5.so
Just showing, in this last bit - that libtool has
'created' all the contents
correctly, but libtool cannot --install it correctly.
Would appreciate APR/APACHE assistance on getting this
'noticed' by GNU
libtool - as in, is it $dlname should be prefixing
$library_names, or should
$library_names be different? I am hoping someone here
(ASF) knows.
Many thanks for taking the time to read and think!
Michael
