You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Michael Felt <ma...@gmail.com> on 2014/05/04 16:57:45 UTC
Unhappy interactions between AIX, apxs, instdso.sh,
apr/build-1/libtool and php
This is what I am starting with after php make completes
root@x102:[/data/prj/php/php-5.2.17]ls -l .libs
total 15696
-rwxrwxr-- 1 root system 8110795 Dec 6 15:47 libphp5.a
-rwxrwxr-- 1 root system 94542 Dec 6 15:47 libphp5.exp
lrwxrwxrwx 1 root system 13 Dec 6 15:47 libphp5.la -> ../libphp5.la
-rwxrwxr-- 1 root system 1049 Dec 6 15:47 libphp5.lai
-rwxrwxr-- 1 root system 7846586 Dec 6 15:47 libphp5.so
The end result of make install is:
root@x102:[/data/prj/php/php-5.2.17]make V=0 install
INSTALL_ROOT=/var/tmp/root/php-5.2.17.0
Installing PHP SAPI module: apache2handler
/data/prj/php/php-5.2.17/build/shtool mkdir -p
'/var/tmp/root/php-5.2.17.0/opt/httpd/libexec' &&
/data/prj/php/php-5.2.17/build/shtool mkdir -p
'/var/tmp/root/php-5.2.17.0/var/httpd/etc' && /opt/httpd/sbin/apxs -S
LIBEXECDIR='/var/tmp/root/php-5.2.17.0/opt/httpd/libexec' -S
SYSCONFDIR='/var/tmp/root/php-5.2.17.0/var/httpd/etc' -i -a -n php5
libphp5.la
/var/httpd/build/instdso.sh SH_LIBTOOL='/var/apr/build-1/libtool'
libphp5.la/var/tmp/root/php-5.2.17.0/opt/httpd/libexec
rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
/var/apr/build-1/libtool --mode=install cp
libphp5.la/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
libtool: install: cp .libs/libphp5.a
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
libtool: install: cp .libs/libphp5.lai
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
libtool: install: warning: remember to run `libtool --finish
/data/prj/php/php-5.2.17/libs'
## added command to list contents of TARGETDIR after libtool command
/usr/bin/ls -l /var/tmp/root/php-5.2.17.0/opt/httpd/libexec
total 15864
-rwxr-xr-- 1 root system 8110795 May 04 14:53 libphp5.a
-rwxr-xr-- 1 root system 1049 May 04 14:53 libphp5.la
chmod 755 /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
chmod: cannot access
`/var/tmp/root/php-5.2.17.0/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.
Stop.
I am wondering if the error is in APR and the way it creates or uses the
libtool command - or is it a problem with libtool - as some files get
copied, but not the .so file which exists.
1) Who should get a bug-report?
2) Suggestions for correction - other that just hard coding a hack: cp
.libs/libphp5.so $TARGETDIR
regards,
Michael Felt
Re: Unhappy interactions between AIX, apxs, instdso.sh,
apr/build-1/libtool and php
Posted by Michael Felt <ma...@gmail.com>.
on vacation. will test later. however, I have looked at the svn sources
and consider it a weakness to assume that the expected target exists.
never getting that message, at the least, has made understanding what I
need to correct very difficult.
I do not know either libtool or apr well enough to know if the root cause
is in instdso.sh. imho the root cause is elsewhere (question: why is the
target not installed?). Without having studied the content of the .la file
I suspect a real structural solution comes from correcting what is wrong or
missing there.
peeked at .la file, says dlname=libphp5.so
If that is then intended target then that may be pointing more at apr as
root cause. however that may be a misunderstanding on my part.
in short, while I feel a warning about a missing target is what instdso.sh
really needs - other changes constitute correcting errors from
other/previous instructions and that it would be better to correct errors
earlier in the build/install process.
On Jun 22, 2014 6:58 AM, "Victor J. Orlikowski" <
victor.j.orlikowski@alumni.duke.edu> wrote:
> On Jun 20, 2014, at 12:34 PM, Michael Felt <ma...@gmail.com> wrote:
>
> Here is the patch - as text, and a file (not sure what normal is, but
> since it is small doing both).
>
>
> So - I looked at what you did here, and then compared it both against
> what’s in httpd-2.4.x and httpd-trunk.
>
> What happens when you use the instdso.sh from httpd-trunk, rather than
> what you have in your patch?
> You can get it from here:
> https://svn.apache.org/repos/asf/httpd/httpd/trunk/build/instdso.sh
>
> Looks to me that the instdso.sh from trunk performs the same function,
> except for multiple DSO names, and has some accomodations for AIX.
>
> If that works - it makes sense to me to pull the instdso.sh from trunk
> back to 2.4.x and 2.2.x.
>
> Best,
> Victor
> --
> Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
>
>
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Jun 20, 2014, at 12:34 PM, Michael Felt <ma...@gmail.com> wrote:
> Here is the patch - as text, and a file (not sure what normal is, but since it is small doing both).
So - I looked at what you did here, and then compared it both against what’s in httpd-2.4.x and httpd-trunk.
What happens when you use the instdso.sh from httpd-trunk, rather than what you have in your patch?
You can get it from here: https://svn.apache.org/repos/asf/httpd/httpd/trunk/build/instdso.sh
Looks to me that the instdso.sh from trunk performs the same function, except for multiple DSO names, and has some accomodations for AIX.
If that works - it makes sense to me to pull the instdso.sh from trunk back to 2.4.x and 2.2.x.
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh,
apr/build-1/libtool and php
Posted by Michael Felt <ma...@gmail.com>.
Here is the patch - as text, and a file (not sure what normal is, but since
it is small doing both).
I moved $DLNAME != $TARGET_NAME test up because it seems more logical to
try and let this bit resolve
any issue before testing for the existance of $TARGET_NAME
Then, if $TARGET_NAME is still missing, try and guess/hope that it is
./libs and copy from there.
Set exit status to the exit status of the copy, and exit with that value at
the end.
I am wondering if the root cause is being corrected though. Perhaps apr is
in error, or the instructions for creating the .la file (would that
indicate libtool?). In any case, I hope this, even as a "hack" resolves the
recurring problems I have with getting php to install in a DESTDIR aka
INSTALL_ROOT.
*As an aside for anyone else attempting to package php, rather than install
on top of an installed httpd - there is a an additional moment that goes
wrong when installing to an installation directory: the configuration file
(httpd.conf) is, basically by definition, missing.*
*I would also like to see the apxs warn and skip, rather than fail when
apxs has been asked to add LoadModule (*
*(i.e. -S SYSCONFDIR='$(INSTALL_ROOT)/etc/httpd' ... -S (-a or -A or -e)
configuration file (i.e., $SYSCONFDIR/httpd.conf) is missing rather than
failing. I think this would be more graceful.Currently I resolve this by
editing the php Makefile and remove the '-a' argument from the INSTALL_IT
definition.*
Back to the 'patch' proposal:
root@x093:[/data/prj/apache/httpd/httpd-2.2.27]diff -u ./build/instdso.sh
/var/httpd/build/instdso.sh
--- ./build/instdso.sh 2006-07-12 03:38:44 +0000
+++ /var/httpd/build/instdso.sh 2014-06-20 19:13:56 +0000
@@ -72,6 +72,20 @@
exit 0
fi
+if test "$DLNAME" != "$TARGET_NAME"
+then
+ mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME
+fi
+
+# at this point $TARGETDIR/$TARGET_NAME should exist
+# if not, let's hope it is in .libs and copy it to $TARGET_DIR
+status=0
+if ! test -e $TARGETDIR/$TARGET_NAME
+then
+ cp -p .libs/$TARGET_NAME $TARGETDIR/$TARGET_NAME || exit 1
+ status = $?
+fi
+
if test -n "$LIBRARY_NAMES"
then
for f in $LIBRARY_NAMES
@@ -80,14 +94,9 @@
done
fi
-if test "$DLNAME" != "$TARGET_NAME"
-then
- mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME
-fi
-
rm -f $TARGETDIR/$DSOARCHIVE_BASENAME
rm -f $TARGETDIR/$DSOBASE.a
rm -f $TARGETDIR/lib$DSOBASE.a
rm -f $TARGETDIR/lib$TARGET_NAME
-exit 0
+exit $status
On Fri, Jun 20, 2014 at 7:22 PM, Victor J. Orlikowski <
victor.j.orlikowski@alumni.duke.edu> wrote:
> On Jun 20, 2014, at 12:35 PM, Michael Felt <ma...@gmail.com> wrote:
>
> At least, I am assuming this to be the problem - because I am assuming the
> expectation is that $TARGET_NAME has been installed - unless DLNAME !=
> TARGET_NAME - because in that case DLNAME gets moved.
>
> Unfortunately, what has been installed is $LIBRARY_NAMES and that has
> already been removed!
>
>
> Yeah - I noticed that, when I glanced at it.
> Nice detective work!
>
> Send the patch on, and I’ll be glad to review/commit it.
>
> Best,
> Victor
> --
> Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
>
>
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On Jun 20, 2014, at 12:35 PM, Michael Felt <ma...@gmail.com> wrote:
> At least, I am assuming this to be the problem - because I am assuming the expectation is that $TARGET_NAME has been installed - unless DLNAME != TARGET_NAME - because in that case DLNAME gets moved.
>
> Unfortunately, what has been installed is $LIBRARY_NAMES and that has already been removed!
Yeah - I noticed that, when I glanced at it.
Nice detective work!
Send the patch on, and I’ll be glad to review/commit it.
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh,
apr/build-1/libtool and php
Posted by Michael Felt <ma...@gmail.com>.
Revisiting.
First I looked at apxs using perl debug mode:
Getting to the core: it looks like apxs is working fine:
It gets to where it calls instdso.sh and the second command (chmod) fails.
DB<1>
apxs::(/opt/httpd/sbin/apxs:525): &execute_cmds(@cmds);
DB<1> x @cmds
0 '/var/httpd/build/instdso.sh SH_LIBTOOL=\'/var/apr/build-1/libtool\'
libphp5.la /var/tmp/root/php-5.2.17.0/opt/httpd/libexec'
1 'chmod 755 /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so'
/var/httpd/build/instdso.sh SH_LIBTOOL='/var/apr/build-1/libtool' libphp5.la
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec
rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
/var/apr/build-1/libtool --mode=install cp libphp5.la
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
libtool: install: cp .libs/libphp5.a
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
libtool: install: cp .libs/libphp5.lai
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
libtool: install: warning: remember to run `libtool --finish
/data/prj/php/php-5.2.17/libs'
chmod 755 /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
chmod: /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so: A file or
directory in the path name does not exist.
apxs:Error: Command failed with rc=65536
.
Debugged program terminated. Use q to quit or R to restart,
use O inhibit_exit to avoid stopping after program termination,
h q, h R or h O to get additional info.
So, now to look deeper at instdso.sh
ksh -x /var/httpd/build/instdso.sh SH_LIBTOOL=/var/apr/build-1/libtool
libphp5.la /var/tmp/root/php-5.2.17.0/opt/httpd/libexec
+ test 3 != 3
+ + sed -e s/^SH_LIBTOOL=//
+ echo SH_LIBTOOL=/var/apr/build-1/libtool
SH_LIBTOOL=/var/apr/build-1/libtool
+ DSOARCHIVE=libphp5.la
+ + basename libphp5.la
DSOARCHIVE_BASENAME=libphp5.la
+ TARGETDIR=/var/tmp/root/php-5.2.17.0/opt/httpd/libexec
+ + sed -e s/\.la$//
+ echo libphp5.la
DSOBASE=libphp5
+ TARGET_NAME=libphp5.so
+ + uname -s
SYS=AIX
+ test AIX = AIX
+ CMD=rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
+ echo rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
+ CMD=/var/apr/build-1/libtool --mode=install cp libphp5.la
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
+ echo /var/apr/build-1/libtool --mode=install cp libphp5.la
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
/var/apr/build-1/libtool --mode=install cp libphp5.la
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
+ /var/apr/build-1/libtool --mode=install cp libphp5.la
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
libtool: install: cp .libs/libphp5.a
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
libtool: install: cp .libs/libphp5.lai
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
libtool: install: warning: remember to run `libtool --finish
/data/prj/php/php-5.2.17/libs'
+ test AIX = OS/2
+ + sed -n /^dlname=/{s/.*='\([^']*\)'/\1/;p;}
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
DLNAME=libphp5.so
+ + sed -n /^library_names/{s/library_names='\([^']*\)'/\1/;p;}
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
LIBRARY_NAMES=libphp5.a libphp5.a
+ + sed -e s/ *libphp5.so//g
+ echo libphp5.a libphp5.a
LIBRARY_NAMES=libphp5.a libphp5.a
+ test -z libphp5.so
+ test -n libphp5.a libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ test libphp5.so != libphp5.so
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/liblibphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/liblibphp5.so
+ exit 0
root@x093:[/data/prj/php/php-5.2.17]
Actually, looking at the source code, it all seems to be right - the key
lines are here:
DLNAME=`sed -n "/^dlname=/{s/.*='\([^']*\)'/\1/;p;}"
$TARGETDIR/$DSOARCHIVE_BASENAME`
LIBRARY_NAMES=`sed -n
"/^library_names/{s/library_names='\([^']*\)'/\1/;p;}"
$TARGETDIR/$DSOARCHIVE_BASENAME`
LIBRARY_NAMES=`echo $LIBRARY_NAMES | sed -e "s/ *$DLNAME//g"`
if test -z "$DLNAME"
then
echo "Warning! dlname not found in $TARGETDIR/$DSOARCHIVE_BASENAME."
echo "Assuming installing a .so rather than a libtool archive."
exit 0
fi
if test -n "$LIBRARY_NAMES"
then
for f in $LIBRARY_NAMES
do
rm -f $TARGETDIR/$f
done
fi
if test "$DLNAME" != "$TARGET_NAME"
then
mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME
fi
rm -f $TARGETDIR/$DSOARCHIVE_BASENAME
rm -f $TARGETDIR/$DSOBASE.a
rm -f $TARGETDIR/lib$DSOBASE.a
rm -f $TARGETDIR/lib$TARGET_NAME
exit 0
The problem is here:
CMD="$SH_LIBTOOL --mode=install cp $DSOARCHIVE $TARGETDIR/"
echo $CMD
$CMD || exit $?
At least, I am assuming this to be the problem - because I am assuming the
expectation is that $TARGET_NAME has been installed - unless DLNAME !=
TARGET_NAME - because in that case DLNAME gets moved.
Unfortunately, what has been installed is $LIBRARY_NAMES and that has
already been removed!
What has actually been installed - been staring at me for years is:
root@x093:[/data/prj/php/php-5.2.17]/var/apr/build-1/libtool --mode=install
cp libphp5.la /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
libtool: install: cp .libs/libphp5.a
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
libtool: install: cp .libs/libphp5.lai
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
libtool: install: warning: remember to run `libtool --finish
/data/prj/php/php-5.2.17/libs'
root@x093:[/data/prj/php/php-5.2.17]ls -l
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
total 46488
-rw-r--r-- 1 root system 23790199 Jun 20 15:58 libphp5.a
-rw-r--r-- 1 root system 1239 Jun 20 15:58 libphp5.la
The possible inputs are here:
root@x093:[/data/prj/php/php-5.2.17]ls -l .libs
total 92512
-rw-r--r-- 1 root system 23790199 Jun 19 18:14 libphp5.a
-rw-r--r-- 1 root system 127631 Jun 19 18:14 libphp5.exp
lrwxrwxrwx 1 root system 13 Jun 19 18:14 libphp5.la -> ../
libphp5.la
-rw-r--r-- 1 root system 1239 Jun 19 18:14 libphp5.lai
-rwxr-xr-x 1 root system 23433546 Jun 19 18:14 libphp5.so
So, now back to what happens:
As instdso.sh cleans up this is what it does:
+ /var/apr/build-1/libtool --mode=install cp libphp5.la
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/
libtool: install: cp .libs/libphp5.a
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
libtool: install: cp .libs/libphp5.lai
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
libtool: install: warning: remember to run `libtool --finish
/data/prj/php/php-5.2.17/libs'
+ test AIX = OS/2
+ + sed -n /^dlname=/{s/.*='\([^']*\)'/\1/;p;}
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
DLNAME=libphp5.so
## This DLNAME or TARGET_NAME is what the chmod command wants to act on
later
+ + sed -n /^library_names/{s/library_names='\([^']*\)'/\1/;p;}
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
## I assume this is correct
LIBRARY_NAMES=libphp5.a libphp5.a
+ + sed -e s/ *libphp5.so//g
+ echo libphp5.a libphp5.a
LIBRARY_NAMES=libphp5.a libphp5.a
+ test -z libphp5.so
# This is expected, continue
+ test -n libphp5.a libphp5.a
# And here we delete what was installed!!!
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ test libphp5.so != libphp5.so
# DLNAME == TARGET_NAME, so no move command
### none of these (except the first) exist
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/liblibphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/liblibphp5.so
# And now, everything is gone
+ exit 0
So, my quick hack is:
...
DLNAME=`sed -n "/^dlname=/{s/.*='\([^']*\)'/\1/;p;}"
$TARGETDIR/$DSOARCHIVE_BASENAME`
LIBRARY_NAMES=`sed -n
"/^library_names/{s/library_names='\([^']*\)'/\1/;p;}"
$TARGETDIR/$DSOARCHIVE_BASENAME`
LIBRARY_NAMES=`echo $LIBRARY_NAMES | sed -e "s/ *$DLNAME//g"`
if test -z "$DLNAME"
then
echo "Warning! dlname not found in $TARGETDIR/$DSOARCHIVE_BASENAME."
echo "Assuming installing a .so rather than a libtool archive."
exit 0
fi
## move block up to move DLNAME to TARGET_NAME before testing for existence
if test "$DLNAME" != "$TARGET_NAME"
then
mv $TARGETDIR/$DLNAME $TARGETDIR/$TARGET_NAME
fi
# if doesn't exist, then try copying from .libs directly - $CMD above
missed, sigh
if ! test -e $TARGETDIR/$TARGET_NAME
then
cp -p .libs/$TARGET_NAME $TARGETDIR/$TARGET_NAME
fi
if test -n "$LIBRARY_NAMES"
then
for f in $LIBRARY_NAMES
do
rm -f $TARGETDIR/$f
done
fi
rm -f $TARGETDIR/$DSOARCHIVE_BASENAME
rm -f $TARGETDIR/$DSOBASE.a
rm -f $TARGETDIR/lib$DSOBASE.a
rm -f $TARGETDIR/lib$TARGET_NAME
exit 0
And the result is:
libtool: install: cp .libs/libphp5.a
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
libtool: install: cp .libs/libphp5.lai
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
libtool: install: warning: remember to run `libtool --finish
/data/prj/php/php-5.2.17/libs'
+ test AIX = OS/2
+ + sed -n /^dlname=/{s/.*='\([^']*\)'/\1/;p;}
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
DLNAME=libphp5.so
+ + sed -n /^library_names/{s/library_names='\([^']*\)'/\1/;p;}
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
LIBRARY_NAMES=libphp5.a libphp5.a
+ + sed -e s/ *libphp5.so//g
+ echo libphp5.a libphp5.a
LIBRARY_NAMES=libphp5.a libphp5.a
+ test -z libphp5.so
+ test libphp5.so != libphp5.so
+ test -e /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
+ cp -p .libs/libphp5.so
/var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.so
+ test -n libphp5.a libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.la
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/libphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/liblibphp5.a
+ rm -f /var/tmp/root/php-5.2.17.0/opt/httpd/libexec/liblibphp5.so
+ exit 0
Will submit a diff -u output later - need to reinstall the original - sigh,
forgot to copy before editing.
On Mon, May 5, 2014 at 8:17 AM, Michael Felt <ma...@gmail.com> wrote:
> I see I did not read far enough - as you found the reference to slibclean.
> In it's defense I expect the IBM install program is using slibclean during
> it's installation of files - or, the files are being moved to something
> like /usr/lpp/lpp.name/save (it has been a long long time since I have
> studied how the installp recover option works) and the remove is only
> actually performed after the new files have been put into position.
>
>
> On Mon, May 5, 2014 at 8:14 AM, Michael Felt <ma...@gmail.com> wrote:
>
>> Well, my patch is at the end, leaving the rm in place. However, I could
>> examine looking at using slibclean (shared library clean) - which is the
>> program to remove outstanding (loaded, but not active) shared library code.
>>
>> And - thinking through - if the remove is not done, and the .so file is
>> not copied - the old .so copy remains - but you "expect" it to be updated.
>> For these cases, rather than remove I would move the file to a dated pid
>> (mv $TARGET $TARGET.$today.$$) - and if all fails move it back, otherwise
>> remove (and slibclean again, for certainty). I have been quite perturbed in
>> the past when I was installing "live" and it failed. My previous installed
>> php was now broken.
>>
>> re: slibclean - the program has been around "forever" - at least since
>> since AIX 4.X (starting in 1994-1995). No idea if it has been tested before
>> for php and/or instdso.sh.
>>
>> However, to work, slibclean still needs the previous version to be
>> stopped. I assume that is the same as unlink() of a file - the inode is not
>> actually cleared until both the link count is 0 and there are no open
>> connections to the inode. That is, I do not expect that slibclean is
>> removing "open" routines - but it might.
>>
>> Finally, In my case, as I am "packaging" to a temp directory (installing
>> to $INSTALL_ROOT/*) this should never be an issue. The other issue I run
>> into is the -a argument - because when packaging (
>>
>>
>> On Sun, May 4, 2014 at 11:54 PM, Victor J. Orlikowski <
>> victor.j.orlikowski@alumni.duke.edu> wrote:
>>
>>> On May 4, 2014, at 5:46 PM, Victor J. Orlikowski <
>>> victor.j.orlikowski@alumni.duke.edu> wrote:
>>>
>>> My only comment to that would be: has AIX resolved the issue wherein it
>>> is required that the file backing a previously-loaded module has to be
>>> rm’d, in order to ensure that the in-memory copy is released?
>>>
>>>
>>> Responding to myself, after a quick consult with the Googlemonster:
>>> Seems you need to call a utility called slibclean, to remove the memory
>>> references to the shared object.
>>>
>>> And, sometimes, that still doesn’t work - so you have to rm it anyway. :/
>>>
>>> Anyhoo - it seems to me that the real problem is that we’re deleting the
>>> newly generated .so, rather than the *target* into which we’re trying to
>>> copy (which is what would be what has the in-memory references).
>>>
>>> Best,
>>> Victor
>>> --
>>> Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
>>>
>>>
>>
>
Re: Unhappy interactions between AIX, apxs, instdso.sh,
apr/build-1/libtool and php
Posted by Michael Felt <ma...@gmail.com>.
I see I did not read far enough - as you found the reference to slibclean.
In it's defense I expect the IBM install program is using slibclean during
it's installation of files - or, the files are being moved to something
like /usr/lpp/lpp.name/save (it has been a long long time since I have
studied how the installp recover option works) and the remove is only
actually performed after the new files have been put into position.
On Mon, May 5, 2014 at 8:14 AM, Michael Felt <ma...@gmail.com> wrote:
> Well, my patch is at the end, leaving the rm in place. However, I could
> examine looking at using slibclean (shared library clean) - which is the
> program to remove outstanding (loaded, but not active) shared library code.
>
> And - thinking through - if the remove is not done, and the .so file is
> not copied - the old .so copy remains - but you "expect" it to be updated.
> For these cases, rather than remove I would move the file to a dated pid
> (mv $TARGET $TARGET.$today.$$) - and if all fails move it back, otherwise
> remove (and slibclean again, for certainty). I have been quite perturbed in
> the past when I was installing "live" and it failed. My previous installed
> php was now broken.
>
> re: slibclean - the program has been around "forever" - at least since
> since AIX 4.X (starting in 1994-1995). No idea if it has been tested before
> for php and/or instdso.sh.
>
> However, to work, slibclean still needs the previous version to be
> stopped. I assume that is the same as unlink() of a file - the inode is not
> actually cleared until both the link count is 0 and there are no open
> connections to the inode. That is, I do not expect that slibclean is
> removing "open" routines - but it might.
>
> Finally, In my case, as I am "packaging" to a temp directory (installing
> to $INSTALL_ROOT/*) this should never be an issue. The other issue I run
> into is the -a argument - because when packaging (
>
>
> On Sun, May 4, 2014 at 11:54 PM, Victor J. Orlikowski <
> victor.j.orlikowski@alumni.duke.edu> wrote:
>
>> On May 4, 2014, at 5:46 PM, Victor J. Orlikowski <
>> victor.j.orlikowski@alumni.duke.edu> wrote:
>>
>> My only comment to that would be: has AIX resolved the issue wherein it
>> is required that the file backing a previously-loaded module has to be
>> rm’d, in order to ensure that the in-memory copy is released?
>>
>>
>> Responding to myself, after a quick consult with the Googlemonster:
>> Seems you need to call a utility called slibclean, to remove the memory
>> references to the shared object.
>>
>> And, sometimes, that still doesn’t work - so you have to rm it anyway. :/
>>
>> Anyhoo - it seems to me that the real problem is that we’re deleting the
>> newly generated .so, rather than the *target* into which we’re trying to
>> copy (which is what would be what has the in-memory references).
>>
>> Best,
>> Victor
>> --
>> Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
>>
>>
>
Re: Unhappy interactions between AIX, apxs, instdso.sh,
apr/build-1/libtool and php
Posted by Michael Felt <ma...@gmail.com>.
Well, my patch is at the end, leaving the rm in place. However, I could
examine looking at using slibclean (shared library clean) - which is the
program to remove outstanding (loaded, but not active) shared library code.
And - thinking through - if the remove is not done, and the .so file is not
copied - the old .so copy remains - but you "expect" it to be updated. For
these cases, rather than remove I would move the file to a dated pid (mv
$TARGET $TARGET.$today.$$) - and if all fails move it back, otherwise
remove (and slibclean again, for certainty). I have been quite perturbed in
the past when I was installing "live" and it failed. My previous installed
php was now broken.
re: slibclean - the program has been around "forever" - at least since
since AIX 4.X (starting in 1994-1995). No idea if it has been tested before
for php and/or instdso.sh.
However, to work, slibclean still needs the previous version to be stopped.
I assume that is the same as unlink() of a file - the inode is not actually
cleared until both the link count is 0 and there are no open connections to
the inode. That is, I do not expect that slibclean is removing "open"
routines - but it might.
Finally, In my case, as I am "packaging" to a temp directory (installing to
$INSTALL_ROOT/*) this should never be an issue. The other issue I run into
is the -a argument - because when packaging (
On Sun, May 4, 2014 at 11:54 PM, Victor J. Orlikowski <
victor.j.orlikowski@alumni.duke.edu> wrote:
> On May 4, 2014, at 5:46 PM, Victor J. Orlikowski <
> victor.j.orlikowski@alumni.duke.edu> wrote:
>
> My only comment to that would be: has AIX resolved the issue wherein it is
> required that the file backing a previously-loaded module has to be rm’d,
> in order to ensure that the in-memory copy is released?
>
>
> Responding to myself, after a quick consult with the Googlemonster:
> Seems you need to call a utility called slibclean, to remove the memory
> references to the shared object.
>
> And, sometimes, that still doesn’t work - so you have to rm it anyway. :/
>
> Anyhoo - it seems to me that the real problem is that we’re deleting the
> newly generated .so, rather than the *target* into which we’re trying to
> copy (which is what would be what has the in-memory references).
>
> Best,
> Victor
> --
> Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
>
>
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On May 4, 2014, at 5:46 PM, Victor J. Orlikowski <vi...@alumni.duke.edu> wrote:
> My only comment to that would be: has AIX resolved the issue wherein it is required that the file backing a previously-loaded module has to be rm’d, in order to ensure that the in-memory copy is released?
Responding to myself, after a quick consult with the Googlemonster:
Seems you need to call a utility called slibclean, to remove the memory references to the shared object.
And, sometimes, that still doesn’t work - so you have to rm it anyway. :/
Anyhoo - it seems to me that the real problem is that we’re deleting the newly generated .so, rather than the *target* into which we’re trying to copy (which is what would be what has the in-memory references).
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On May 4, 2014, at 3:42 PM, Michael Felt <ma...@gmail.com> wrote:
> Yes, I have been commenting there since 2007. I shall add an easier to read patch later. -- The meet of it will be:
Huh. Guess I should have looked beyond the issue described, and paid attention to the folks involved. ;)
Fair enough, re: the new patch.
My only comment to that would be: has AIX resolved the issue wherein it is required that the file backing a previously-loaded module has to be rm’d, in order to ensure that the in-memory copy is released?
Otherwise, I’m on-board.
Best,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh,
apr/build-1/libtool and php
Posted by Michael Felt <ma...@gmail.com>.
Yes, I have been commenting there since 2007. I shall add an easier to read
patch later. -- The meet of it will be:
rm -f $TARGETDIR/$DSOARCHIVE_BASENAME
rm -f $TARGETDIR/$DSOBASE.a
rm -f $TARGETDIR/lib$DSOBASE.a
rm -f $TARGETDIR/lib$TARGET_NAME
if test "$SYS" = "AIX"
then
if ! test -e $TARGETDIR/$TARGET_NAME
then
CMD="cp -p .libs/$TARGET_NAME $TARGETDIR/$TARGET_NAME"
echo $CMD
$CMD || exit -1
fi
fi
exit 0
Besides the size (the .a file is larger on my box, what other difference is
there between a .so and a .a?
The patch from 2008 moved the .a file to .so, while I see that in .libs I
have both a .a archive and a .so file
On Sun, May 4, 2014 at 7:12 PM, Victor J. Orlikowski <
victor.j.orlikowski@alumni.duke.edu> wrote:
> On May 4, 2014, at 12:07 PM, Eric Covener <co...@gmail.com> wrote:
> > On Sun, May 4, 2014 at 10:57 AM, Michael Felt <ma...@gmail.com> wrote:
> >> 1) Who should get a bug-report?
> >
> > sounds familiar, usually the complaint is against our instdso.sh
>
> Sigh:
>
> https://issues.apache.org/bugzilla/show_bug.cgi?id=43012
>
> I don’t have an AIX box to test against, anymore - but you might try the
> patch that’s suggested in bugzilla.
>
> Hope that helps,
> Victor
> --
> Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
>
>
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
Posted by "Victor J. Orlikowski" <vi...@alumni.duke.edu>.
On May 4, 2014, at 12:07 PM, Eric Covener <co...@gmail.com> wrote:
> On Sun, May 4, 2014 at 10:57 AM, Michael Felt <ma...@gmail.com> wrote:
>> 1) Who should get a bug-report?
>
> sounds familiar, usually the complaint is against our instdso.sh
Sigh:
https://issues.apache.org/bugzilla/show_bug.cgi?id=43012
I don’t have an AIX box to test against, anymore - but you might try the patch that’s suggested in bugzilla.
Hope that helps,
Victor
--
Victor J. Orlikowski <> victor.j.orlikowski@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh,
apr/build-1/libtool and php
Posted by Eric Covener <co...@gmail.com>.
On Sun, May 4, 2014 at 10:57 AM, Michael Felt <ma...@gmail.com> wrote:
> 1) Who should get a bug-report?
sounds familiar, usually the complaint is against our instdso.sh