Matching proxyauth.so version to PHP Zend API version - php

This is the error every time I start up php:
Unable to load dynamic library '/usr/lib/php/extensions/no-debug-non-zts-20100525/proxyauth.so' - dlopen(/usr/lib/php/extensions/no-debug-non-zts-20100525/proxyauth.so, 9)
I have two older versions of the proxyauth.so in no-debug-non-zts-20060613 and no-debug-non-zts-20090626, but neither is compatible with a module API compatible with 20100525, so symlinking doesn't solve the problem.
I've Googled my best and have no idea where proxyauth comes from, and therefore can't make a new one with the compatible API. There doesn't appear to be an extension in the php ext directory, so I have no idea what to do next.
Thoughts?
Thanks,
Bill

If the warning is the only problem - meaning your code itself runs fine - then the extension isn't required anymore by your application. Why not out-commenting the extension=proxyauth.so?

Related

TYPO3 PHP Runtime Deprecation Notice:

i have a problem with some old TYPO3 stuff, i tried to make a old TYPO3 Website run on my Ubuntu system.
And sorry if somethings are not clear to understand for me, i am new in CMS's and i am forced to change some stuff on a old page.
Problems are:
1.
Backend seems working, half. If i enable the ext. TemplaVoila my be Page module shows me a white page.
On TV disable,
Page module, seems working but it gives me some strange error messages inside the content fields.
if i try to look at the front-end it gives me this exception:
1: PHP Runtime Deprecation Notice: Non-static method tx_ttnews_div::getSubCategories() should not be called statically,
assuming $this from incompatible context in
/var/www/projectfolder/projectfolder-typo3/typo3conf/ext/tt_news/pi/class.tx_ttnews.php
line 3740
Just apart from this, i read about a removed php feature in update 5.6 i was using currently.
Things i checked already:
-Correct PHP -v
-Database import correct
-LocalConf correct (took from live server and changed for my localhost)
-Checked install-tool and rm -rf * inside typo3temp folder
Thanks for you help
Your PHP version combined with the versions of TYPO3 and extensions seems to be incompatible. You either need to use a different PHP version or upgrade TYPO3 and/or the extensions being used. FYI, the method being called is from a very old extension so although you don't say which version you're using, I assume your TYPO3 version is very old (either 6.x or even 4.x versions).
The normal recommendation would be to upgrade TYPO3 and any extensions. The less recommended alternative would be to use a different PHP version. But please be aware that remaining on older TYPO3 versions means your site may not be patched for security issues and may not be compatible with modern browsers.

Failed installation of zend-escaper with Composer

I'm trying to install zend-escaper but I'm getting this error:
This is strange as my PHP version (from phpinfo()) is 5.5.19, the message claims it is 5.3.5(!) which should satisfy the requirement anyway.
My ZF version is 1.12.13
I'm using PHP Storm
Can anyone help please?
Thanks
Tomasz
The PHP version on the command line can be a different executable than the PHP running inside the web server. It also can use a different pho.ini configuration file.
So if Composer states the PHP it is using is 5.3.5, this is correct because Composer is directly asking the PHP it is running on for its version. The problem is when this PHP version on the command line is way older then the PHP version in the web server.
Try to update your command line PHP.
Some more things to say: the version 5.3.5 is lower than the required 5.3.23, because the last number in the version is 5 compared with 23, and 5 is less than 23. So the version you are using is below the minimum requirement for zend escaper - at least in the version 2.5.1 you try to use. Such an old PHP was last supported in the 2.2 framework versions, so you might as well try to depend on ~2.2. However this will simply be a workaround for the old cli version.
One other note: You are in the process of installing a zend framework 2 component - don't expect your installed zend framework 1 to support any fancy stuff on its own. It is possible to mix classes with namespaces and without, and even use zf2 things together with zf1, but zf1 won't offer any automatic functionality to use these.

Mismatch between Php and Extension module

I am trying to install the following php extension. Microsoft Drivers for SQL Server for PHP.
I have tried both versions of the driver but both seem to mismatch the version of php i am running. I looked around and it appears I have to recompile the modules in order to match the php api version. But I don't have any idea how to do this.
Any ideas on how to make this work? Or maybe a simpler way to use PHP 5.4.7 to access SQL.
You can do it with some tricks, its not recommended but it will work fine and in my case, it has not crashed yet :)
Check your phpinfo() page for:
1-PHP extension API Number
2-Thread safe or non-thread safe version
3-(Windows) compiler version
1-For building your extension you need php.lib. It is in your PHP-server dev directory.
2-You need PHP header files for compiling your extension, after including PHP header files, go to PHP/Zend directory and open zend_modules.h file and change the #define ZEND_MODULE_API_NO 20060613to your PHP extension API number for example change it to #define ZEND_MODULE_API_NO 20090626.
3- If you use windows based servers the compiler version is important(VC8 - VC10), if your PHP was compiled with VC8, build the extension in VS2008 or use VC8 for building your project.
If you encounter any wired error just comment it. I spent 3 months to make this worked ;)

php_monetdb.dll

I need the php_monetdb.dll for php 5.4. I've found that by building the monetDB with the HAVE_PHP=1 option on windows will create the dll, but the build procedure fails at numerous points. I am using the monetdb source from sourceforge which is a little outdated one. The newer version has problems in the .msc files itself so proceeding to the build itself is a pain. The older version that I am trying on is atleast passing the nmake step but failing on the nmake install step. The reasons vary from component to component. One states that the devenv /build does not exist. For this I copied the vcexpress and renamed it to devenv. I am not sure if this is right but when I run it from the command prompt it seems to work ok with a few warning alerts shown. During other make installs, the header files seem to be missing. Could anyone please help me with this. Also please let me know if there is any other alternative for this approach of getting php_monetdb.dll.
P.S: I am using windows 7, MSVC 10 express, PHP 5.4.4
For the build questions, see http://bugs.monetdb.org/show_bug.cgi?id=3121
For php_monetdb.dll, see
http://sourceforge.net/mailarchive/forum.php?thread_name=20120717145132.GU49719%40cwi.nl&forum_name=monetdb-developers
http://sourceforge.net/mailarchive/forum.php?thread_name=500581D5.8030808%40acm.org&forum_name=monetdb-developers

Why does PHPinfo have a header version and library version? What are the differences?

I have an inconsistency, and I could not align their versions properly, so I just wanted to remove the library version. Can I do this? Is the header version for PHP while the library is from my distro? Can I upgrade PHP's library version? If so, how? I am using PHP 5.4.4
For example,
Is the header version for PHP while the library is from my distro?
It means it was compiled against the 1.0.1 headers, but is now dynamically linking against 0.9.8. So you are using an older version than what was used when PHP was compiled.
Many libraries store the version in the header files. So when a program uses the library, it can do something like int HEADER_FOO_VERSION = LIBRARY_VERSION, which embeds that version number into the program (e.g., php). Now when that program runs, it links dynamically against the library, which may be a different one than was on the host system.
That library may have a function call, say int get_library_version(). So the program (PHP) can check if HEADER_FOO_VERSION == get_library_version(). If it's different, then there could be a compatibility issue. (Of course, it doesn't have to be assign to a local variable... I'm just trying to drive home the point that the header version number can be compiled into php, and remains constant no matter which version of the library is being used at run time.)
Whether or not it is a problem depends on if the two versions are compatible.
Usually if the library is > than the header, you are okay. It's definitely more likely to be a problem if the library is older than the version it was linked against. Of course, this is because it's impossible to know what changes future versions may have.
So in your case, I would try to update your system's SSL libraries via apt-get, yum, etc, to match the version PHP is expecting.
To check which version php is using on Linux:
$ ldd `which php` | grep ssl
libssl.so.1.0.0 => /lib/i386-linux-gnu/libssl.so.1.0.0
Note that which php is just a short-cut to find the full path. You can hard code any executable you'd like to check: ldd /usr/sbin/httpd.
I dont know the answer myself, but when searched on google some nice resources explaining the same.....
What's the difference between a header file and a library?
The version of the files are the one mentioned in the phpinfo used to create a library.
Hope it helps, there are lot of resource available if searched on google.
Still will like to hear from someone in great details about the question
The header version is the functionality version, whereas the library version is the code version.
The header defines the interface - it tells you what functions are within the library. If a header gets updated, then you need to check to make sure all the functions are the same, and see if any are added or subtracted.
But if a library gets updated, and not the header, it means all the function calls are the same, but some of the code may be changed (eg, bug fixes).
In your example, PHP is seeing functionality for OpenSSL 1.0.1, but the actual version of the source code that OpenSSL is loading is 0.9.8o
This is commonly seen on updated versions of openssl. What happens is the newer versions for the libraries are stored in different folder. The original folder located at /usr/bin/openssl would need a symbolic link to the new folder /usr/local/bin/openssl. That would get both to be the same version or just show OpenSSL Version _(Whatever)
Normally there is no concern for this, since it still works the way it is intended. This is seen a lot on shared servers.
EDIT:
The information in this post is generic and can be different if you are running
CentOS, RedHat, Ubuntu, or another Linux/BSD version. Check documentation or man
pages for the best information
If you do update your OpenSSL, some versions of *nix Require for you to rebuild PHP and Apache for it to update
If you are rebuilding PHP from source, I have found another possible reason for a mismatch. It's so simple yet if you are not familiar with building from source on Linux, not knowing it can cost you a lot of time.
The answer is here: https://serverfault.com/a/567705/305059 - unfortunately I cannot up-vote it over the not-so-useful answer, so if you have the reputation there, please do.
You need to run "make clean" before "make" in order for it to rebuild all binaries. Strangely, without this step I was getting an updated library version, but the old header version - so I think it must have rebuilt something, but not everything. My rebuild involved linking to a version of curl in another location (built with ssl), which might be the reason behind it.
Anyway, I hope this helps someone. Thank you to #velcrow on serverfault.

Categories