ID: 21973 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment:
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..? Previous Comments: ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ [2003-01-31 05:02:49] [EMAIL PROTECTED] > 1) The patch allows to present the correct error message > without changing anything else yet. I am working on a php > wide patch that solves such problems generically. The output was unchanged. Thanks for the further effort, though. > 2) I knew before what you are trying to. However you got a problem > simply because you wnated to save some bytes... I must have implied that I am doing something unique, here. I'm not. > Try this layout > > .../normal/png/lib > .../normal/png/include > .../sparcv9/png/lib > .../sparcv9/png/include [...] > If you use the layout above you even have no need to configure any > compiler linker configuration before calling ./configure. Right...that's a bit of clutter and post package-install processing that I would rather the world avoid. You would at have to at least mention this workaround in the PHP release notes or documentation. And I'm not in a position to inform Sun, HP, and SGI that they've got it wrong and should travel back in time to change the course of history. Nor am I in a position to contact all users and ask them to change their system settings or symlink all installed packages to accommodate PHP. Nor am I in a position to write to all package maintainers and commercial software developers and inform them to change their releases to accommodate a different file structure. Nor am I in a position to write to all developers in the globe and ask them to change their software because PHP has shown us how it should be done. > What is left could be the fact that you used "libpng12" and > i am not quite sure if we want to search for all versions since there > should be links named libpng. whatever that point to the specific > version (thats different from db-n where we search for a specific > version). libpng chooses libpng12 (as described in its docs). But I do seem to have symlinks using the name libpng rather than libpng12, as you say. Sorry for the confusion! My fault for not being particularly familiar with libpng. Anyway, in my eyes my original bug report stands, including my comment that other configuration steps, such as for LDAP, are broken. Hmm, looking at some live pages right now, LDAP compiled in fine with PHP 4.3.0 pre-release CVS. Although I had to patch PHP extensively to make it install, load, and work correctly, I don't remember having to patch anything in the configure script. Then again, my memory does have many faults. ...pause to wait for fresh copies of PHP to run 'configure'... Yes, 4.3.0 release seems to report an error when trying to find ldap whereas 4.3.0 CVS (unknown date, I could find out though) seems fine. I may have to leave this matter overnight since it is 7pm in my timezone. (Which is extremely different to whatever timezone -- apparently not UTC -- that the bugs.php.net interface seems to use :) ------------------------------------------------------------------------ [2003-01-31 04:18:23] [EMAIL PROTECTED] The way this works, works for 99.99% of users. We're not going to change this. ------------------------------------------------------------------------ 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