rabark

Solved: The server admin was working on another problem and restarted Tomcat. Somehow that caused Apache/PHP to behave itself and the extension dir now matches what's in the php.ini file.

Hello All, Got a weird problem on my unix web server. The phpinfo() function claims that my extension_dir is /opt/hpws/apache/php/lib/php/extensions/no-debug-zts-20060613 (this folder doesn't exist on the server, btw). However, the php.ini file specified in "Configuration File" contains the following line: ; Directory in which the loadable extensions (modules) reside. extension_dir = "/opt/hpws/apache/php/lib/php/extensions" This folder does exist. When I stop and restart Apache though, this folder does not get set as the extension_dir. Any ideas on why this might be occurring? Is there perhaps something outside php.ini that could be overwriting the extension_dir value? -Bob

Hello again, For some time now, my PHP scripts having been throwing an error: PHP Warning: Unknown(): Invalid library (maybe not a PHP library) 'sockets.sl' in Unknown on line 0 PHP Warning: Unknown(): (null): Unable to initialize module Module compiled with module API=20041030, debug=0, thread-safety=1 PHP compiled with module API=20020429, debug=0, thread-safety=1 These options need to match in Unknown on line 0 PHP Warning: Unknown(): Invalid library (maybe not a PHP library) 'ldap.sl' in Unknown on line 0 Obviously, PHP and the above extensions are running on compilations that are out of sync. Is there anyway I can find out what PHP version is associated with API 20041030?

Hello, Recently my System Administrator and I have been trying to get LDAP working with PHP. At first we had configure errors being thrown about not being able to find ldap libraries (or sometimes it complained about the ldap.h file). Well, we tried installing another ldap and this time the configure command worked fine with no errors. However, when the make command was run, this error was thrown: Google searches turned up a little information on this, but nothing pertaining to a "db" library. Any idea what this "db" library is that the server seems to be missing?

We got Apache to recognize the reconfiguration! Apparently you are supposed to have stopped Apache *before* you run the configure, make, and make install commands. Now everything is workign great. Except for LDAP We've tried pointing '--with-ldap=' to all kinds of locations, but no matter what, we always get this error: A find command reveals that indeed there is no ldap.h file anywhere on the server (although all the other ldap files are in the folder where the ldap.h file should be). It would seem then that we need to reinstall and recompile LDAP I'm guessing?. That seems strange though since the LDAP extension was working fine before. Could the reconfiguring of PHP possibly removed the ldap.h file or something?

Hmm, that might be possible. I ran a "php --version" command and got this: PHP Warning: Unknown(): (null): Unable to initialize module Module compiled with module API=20041030, debug=0, thread-safety=1 PHP compiled with module API=20020429, debug=0, thread-safety=1 These options need to match in Unknown on line 0 PHP Warning: Unknown(): Invalid library (maybe not a PHP library) 'ldap.sl' in Unknown on line 0 PHP 4.4.8 (cli) (built: Mar 13 2008 19:24:40) Copyright © 1997-2008 The PHP Group Zend Engine v1.3.0, Copyright © 1998-2004 Zend Technologies I'm fairly certain the ldap part of the error is being caused because we didn't reconfigure with the '--with-ldap[=DIR]' configuration option. However, does the "PHP 4.4.8 (cli)" part indicate that only the CLI version was installed?

Recently, I created a PHP page that makes use of executing file_get_contents() on a URL. The URL happened to be a https URL, and it was determined PHP needed to be reconfigured with the option '--with-openssl' in order for file_get_contents() to work. The sysadmin has reconfigured PHP, and upgraded PHP from 4.3.8 to 4.4.8 while at it. My script works great when run from the command line, but when run from a browser, phpinfo() shows the previous version and compilation of PHP in effect, thus my page throws a file_get_contents related error. Apache was restarted twice after the reconfiguration, but it seems it didn't quite get the memo. Any idea what might be wrong?

Java Web Service. At least I think that's what it is; I'd have to get in touch with the developers of the Web service to verify it. What I'm trying to read is the output of mymethod which is in XML format.

Thank you for the quick replies To my knowledge, the page is not restricted in any way. Also, I am able to copy and paste the URL from the warning message to the address bar and access the page (a bunch of XML) just fine. My previous theory was that https doesn't work with file methods. My current theory is that the problem lies somewhere on the server or network since I'm able to use it on some URLs but not others and I am sending emails back and forth to the administrator. For what it's worth however, here is the code of interest (URL has been censored for privacy, but its structure is the same): $url = "https://some.host.com:1234/directory/WebService.jws/mymethod?arg1=value1&arg2=value2&arg3=value3&"; $xml = file_get_contents($url); print "This is what was returned:<br><br>"; print nl2br($xml);

I'm trying to open a URL via the file_get_contents method, but it's not working (throws the "failed to open stream: No such file or directory " message). The phpinfo method shows that PHP has been configured with allow_url_fopen set to "On". It should be noted however that I'm trying to access a "https" URL. Does file_get_contents() work with https?

It's already in there as: extension=oci8.sl Is that wrong? -Robert

Nope, doesn't show up in the file. -Robert

According to the online documentation, it looks like most if not all of the OCI8 functions are only supported on PHP 5. The server I'm working on uses PHP 4, but it has the OCI8 extension installed. However, the OCI8 functions throw "undefined function" when called. So is this because the server isn't using PHP 5, or because OCI8 was probably installed improperly? -Robert

Does anyone else have some suggestions? I did some Google searches and consistently saw a different suffix used after "oci8" in quite a few of the returned hits. Could the ".sl" have anything to do with this? Also talked to the system admin, but she doesn't know PHP -Robert

Yes, the oci8.sl file is in the extension_dir folder listed in phpinfo(). -Robert