ID: 21973
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: *Configuration Issues
Operating System: Solaris 8
PHP Version: 4.3.0
New Comment:
Back to dba:
I tried several combinations and having problems with
shared dba earlier than 3.3. I did some fixes and
disallowed buildng shared dba with those versions for now.
However i got a short reply from sleepycat that they do
not have any idea how to explain what is happening.
Back to general linking:
I made a configure function which allows me to
handle all libraries required by gd and dba extension.
Since those are the most complicated cases i suppose we
could easily expand that function to handle all external
libraries. If that is done we may even add automatic
detection support for your directory structure.
I will post that function here and as a diff on php-dev
during the week ....
Previous Comments:
------------------------------------------------------------------------
[2003-02-01 01:08:15] [EMAIL PROTECTED]
> Anyway, in what version of PHP did LDAP configure
> work without any patches?
The CVS tag is php_4_3_0pre2. I've done a fresh checkout
with that tag and can verify that the 'configure' script
generated by my copies of autoconf, etc, works. I tried
the following successful combinations:
- autoconf 2.52, automake 1.5, libtool 1.4
- autoconf 2.57, automake 1.7.2, libtool 1.4.3
- flex 2.5.4 and bison 1.75 were used in all cases.
Compiler was gcc 3.2.1 for Sun UltraSPARC v9 using
Sun's CCS assembler Sun's CCS linker (typical scenario).
Notes:
- first, I applied my int/long correctness patches
(fortunately, these do not influence the configure step).
- ldap configures and compiles with no warnings or
errors. BUT I have to induce -lldap myself (other modules,
such as database modules, seem to pick up their libraries
okay, though). So really, ldap configuration wasn't
entirely working in pre2 but the fault had a different
manifestation than in the release, and had obvious
output/cause/workaround.
- the gd module configures with errors but I commented out
the 'exit' commands and configure completes.
- the ldap and gd modules then appear work fine with Apache.
- I had to comment out _LT_AC_TRY_DLOPEN_SELF when using
the second lot of auto tools.
But when I do a buildconf, configure, make with php_4_3_0, I
get the problem "Cannot find ldap libraries in $LDAP_LIBDIR."
Notes:
- first, I applied my int/long correctness patches
(fortunately, these do not influence the configure step).
- I can work around the gd & ldap problems by manually
deleting the 'exit' commands in the configure
script or inserting the sparcv9 path element into the
configure script, in which case the ldap module then
picks up -lldap by itself.
- the _LT_AC_TRY_DLOPEN_SELF problem has disappeared
in 4.3.0 release.
- the ldap and gd modules then appear work fine with Apache.
> Is the only problem really that we check that the actual
> library _file_ exists? Better way of course would be to
> use PHP_CHECK_LIBRARY macro always and not do the
> filesystem checks at all, like Marcus suggested..?
Yes, in my understanding.
------------------------------------------------------------------------
[2003-01-31 07:55:59] [EMAIL PROTECTED]
I misunderstood the problem apparently, sorry for that.
Anyway, in what version of PHP did LDAP configure
work without any patches?
Is the only problem really that we check that the actual library _file_
exists? Better way of course would be to use PHP_CHECK_LIBRARY macro
always and not do the filesystem checks at all, like Marcus
suggested..?
------------------------------------------------------------------------
[2003-01-31 06:19:33] [EMAIL PROTECTED]
> we would have to change all configure files.
Maybe huge rafts of PHP use the lib name convention,
but for some reason it doesn't matter -- those parts
of PHP work in my context anyway.
And yes, some modules compile and some don't.
Some used to and now they don't.
>From my point of view:
A) Why it would be okay that a module like ldap worked
two/three months ago but does not configure correctly
today. Surely this would considered to be regression.
B) Why other software doesn't stumble during configuration
but PHP does. Surely this is a problem with PHP. Maybe
it's a case of "gosh, this is extensively wrong", but
that doesn't make the problem bogus.
C) I suspect that PHP would compile and run correctly if I
comment out the 'exit' commands in configure. Then, if
the ONLY reason that PHP doesn't compile is that
configure stumbles -- not that any libraries are
missing or can't already be found by the compiler
-- surely that is because the implementation of
'configure' is wrong. It's as though...configure
doesn't need to be made to work differently in as
much as it may be sufficient if it just stopped
exiting prematurely.
After doing some experimentation with this, maybe I
have to resubmit this bug for each affected module?
Gah. Alternatively, maybe I can post to php-dev and
an existing developer can pick up this matter in
general (which is what I'd hoped would happen with
this report)?
------------------------------------------------------------------------
[2003-01-31 05:28:14] [EMAIL PROTECTED]
If you want support your environment we would have to change all
configure files. We would have to change all
lines of the form .../lib/... with ../$LIB_DIR/... and
add some configure magic to determine what $LIB_DIR should be (in your
case it would be sparcv9).
------------------------------------------------------------------------
[2003-01-31 05:11:00] [EMAIL PROTECTED]
Re: [EMAIL PROTECTED]
[Sorry, didn't get around to reading your new message until after
sending the followup that I started prior to you message.]
Woah! Is this part of a concerted effort to eliminate support for
modern platforms? Is that why LP64 64-bit compatibility is so
broken and the Zend engine and PHP modules are drifting away from
C-code portability? Is this part due to a move by Zend to only
support commercially-associated hardware or something? Some
missing details here.
I'm not sure what status to believe this bug is at. I think
"Open". It's been changed to "Bogus" twice but from what you've
said, it sounds like "Won't Fix" (I don't have that option in the
bug tracking interface, perhaps you do?).
Of 147 packages that I compile on the same architecture, and
who-knows-how-many-more that come in packages, why is PHP
avoiding support? Won't it be detrimental if operating system
vendors have to heavily patch/port PHP in order to keep it
working on their platforms (in order to maintain viability of
those platforms)? Is there an arbitration board or core
developer group that I can speak to about this? Sounds like
an off-list matter to begin with.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/21973
--
Edit this bug report at http://bugs.php.net/?id=21973&edit=1
