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
On Jun 20, 2014, at 12:34 PM, Michael Felt 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
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 miss
On Jun 20, 2014, at 12:35 PM, Michael Felt 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 instal
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/bu
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
studie
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
c
On May 4, 2014, at 5:46 PM, Victor J. Orlikowski
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, afte
On May 4, 2014, at 3:42 PM, Michael Felt 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
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 $TA
On May 4, 2014, at 12:07 PM, Eric Covener wrote:
> On Sun, May 4, 2014 at 10:57 AM, Michael Felt 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 bo
On Sun, May 4, 2014 at 10:57 AM, Michael Felt wrote:
> 1) Who should get a bug-report?
sounds familiar, usually the complaint is against our instdso.sh
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 -> ../libp
13 matches
Mail list logo