Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
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.orlikow...@alumni.duke.edu wrote: On Jun 20, 2014, at 12:34 PM, Michael Felt mamf...@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.orlikow...@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
On Jun 20, 2014, at 12:34 PM, Michael Felt mamf...@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.orlikow...@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
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.
DB1
apxs::(/opt/httpd/sbin/apxs:525): execute_cmds(@cmds);
DB1 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.
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
On Jun 20, 2014, at 12:35 PM, Michael Felt mamf...@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.orlikow...@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
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 + +++ /var/httpd/build/instdso.sh 2014-06-20 19:13:56 + @@ -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.orlikow...@alumni.duke.edu wrote: On Jun 20, 2014, at 12:35 PM, Michael Felt mamf...@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.orlikow...@alumni.duke.edu instdso.sh.patch Description: Binary data
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
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.orlikow...@alumni.duke.edu wrote: On May 4, 2014, at 5:46 PM, Victor J. Orlikowski victor.j.orlikow...@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.orlikow...@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
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 mamf...@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.orlikow...@alumni.duke.edu wrote: On May 4, 2014, at 5:46 PM, Victor J. Orlikowski victor.j.orlikow...@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.orlikow...@alumni.duke.edu
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 system1049 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
On Sun, May 4, 2014 at 10:57 AM, Michael Felt mamf...@gmail.com wrote: 1) Who should get a bug-report? sounds familiar, usually the complaint is against our instdso.sh
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
On May 4, 2014, at 12:07 PM, Eric Covener cove...@gmail.com wrote: On Sun, May 4, 2014 at 10:57 AM, Michael Felt mamf...@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.orlikow...@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
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.orlikow...@alumni.duke.edu wrote: On May 4, 2014, at 12:07 PM, Eric Covener cove...@gmail.com wrote: On Sun, May 4, 2014 at 10:57 AM, Michael Felt mamf...@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.orlikow...@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
On May 4, 2014, at 3:42 PM, Michael Felt mamf...@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.orlikow...@alumni.duke.edu
Re: Unhappy interactions between AIX, apxs, instdso.sh, apr/build-1/libtool and php
On May 4, 2014, at 5:46 PM, Victor J. Orlikowski victor.j.orlikow...@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.orlikow...@alumni.duke.edu
