ID: 21973 Comment by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: *Configuration Issues Operating System: Solaris 8 PHP Version: 4.3.0 New Comment:
I've run into a similar problem with --with-java switch. Assuming $PHP_JAVA is set to "/usr/java" with the --with-java=/usr/java switch... The "libjava.so" library is looked for in $PHP_JAVA/lib/ but the file is not there (j2se 1.4.1_01). This may however be a different/new bug, since the file being looked for by configure isn't even in that part of the java tree. It resides in: $PHP_JAVA/jre/lib/sparc/ and $PHP_JAVA/jre/lib/sparcv9/ The rest of the files looked for by configure are found by using: --with-java=/usr/java For it to find this library file, even if there weren't separate architectures, it would have to be: --with-java=/usr/java/jre which would make it so the other java files looked for are not found. Off to sym-link... Previous Comments: ------------------------------------------------------------------------ [2003-02-04 11:52:45] [EMAIL PROTECTED] Yes, you have to install libpng if you don't have it. The download URL is in the manual, <http://www.php.net/manual/en/ref.image.php>. ------------------------------------------------------------------------ [2003-02-04 06:23:30] [EMAIL PROTECTED] Hello there, I'm having a similar problem as this one. I'm using a Sun Cobalt Qube 3 server on which I try to install PHP 4.3 I have searched for libpng on the harddisk but can't find it anywhere. So how can I install GD when I don't have libpng on the server ?? Do I have to install libpng first, if yes then where can I get it?? I guess this is the only problem I'm having right now, first I had a problem because the qube requires php 4.0.6. for it's admin functionality, but I managed to create a workaround for that problem. When I finally have installed php 4.3 I can write a how-to so other Qube users can update their php too. Sun doesn't support updating PHP on a Qube just because they don't want to. ------------------------------------------------------------------------ [2003-02-02 18:50:10] [EMAIL PROTECTED] 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 .... ------------------------------------------------------------------------ [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..? ------------------------------------------------------------------------ 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
