We have a PHP-based website that has been in operation since 2005. We have just added a new developer. We have each developer install a local apache stack for debugging. When he executes the site on his workstation, there is an error message having to do with a name conflict with one function.
Specifically, we have a function called GetText which takes 5 parameters. On his system he gets a message saying the the function cannoot be redeclared. It is conflicting with a function which appears to be named gettext (note the different in capitalization) which is said to take one variable.
We do not get this conflict on any of our other instances. The other instances include our production website and three development websites. All of these instances are running on FreeBSD unix. We have developers running os OS X and in various Windows machines. The developer in question is running on Windows 7.
We do not see any such "gettext" function in our code base, including Pear libraries. As a temporary workaround we have renamed our function to "XGetText". That cures the problem.
Where is this conflict coming from?
That developer has the gettext extension active on his PHP install, which defines the function gettext. Capitalisation doesn't matter to PHP. He'll either have to deactivate the extension in his php.ini if possible, or recompile PHP to exclude the gettext extension (in which case I'd suggest using a virtual machine to install a custom PHP version).
BTW, gettext is a pretty popular and often used extension, naming your userland function GetText is a bad choice.
PHP has a built-in gettext function (in both PHP 4 and PHP 5), and PHP function names are case insensitive. Presumably, your PHP is not compiled with the --with-gettext flag and his is.
Disable the Gettext extension, as I'm sure you're not going to use it in your project
This is how it's done in WAMP:
Related
I have a tedious setup and have ended up with multiple versions of PHP on Mac OSX Yosemite, and now it has become confusing.
So, I managed to have gettext working with PHP for localization, and it works for Apache. But now when I have installed PHPStorm, I get:
Call to undefined function bindtextdomain()
indicating the gettext isn't supported. I understand that php.ini is also telling this isn't enabled and infact, there are different phpinfo() outputs for when I run the same file using apache and then using built-in server with PHPStorm.
Is there a way to be able to know which PHP is currently being used by apache and replicate the exact functionality with PHPStorm ? I wished that it will make debugging faster, but instead the setup has me stuck.
I have been struggling with installing the ImageMagick module to my XAMPP installation for my Typo3 application. The PHP is 5.4.19, x86, MSVC9. I have tried different versions of IM and IM module, always with different errors on Apache startup including
%1 is not a valid win32 application
php5.dll is missing
The procedure entry point MagickGetImageMatte could not be located in the dynamic CORE_RL_wan_.dll
The last of the errors was with the PHP 5.4 thread safe x86 module and the ImageMagick-6.8.8-7-Q16-x86-dll.exe ImageMagick installation. I then tried to copy the CORE dlls, which the module archive contained, into the ImageMagick folder (replacing the original ones). The error went away, the Apache starts without any errors, the imagick module finally appears in phpinfo, however it says
ImageMagick number of supported formats: 0
ImageMagick supported formats no value
and in Typo3 the associated functionalities suggest it still is not working properly. What can be done to make it work?
If I was you, I wouldn't try to use the ImageMagick PHP module any more.
This is not really necessary.
I am not even sure if TYPO3 can handle this module at all since I never tried it.
Since many years I just point the TYPO3 to the binary folder of ImageMagick where all the tools (convert, composite, identify) are located.
PHP must be able to call those binaries of course (exec() function must be anabled and this folder must be within open_basedir if used). It works this way since ever :-)
I recall the very few times I used WAMP environment I had no issues with it either.
Simply download the windows binary of ImageMagick and install it.
Inside the installation folder must be a folder called /bin.
The tools needed must be there as exec-files.
Now just set the TYPO3 configuration to point to this folder including the trailing slash.
For windows it must be something like this as I recall.
$TYPO3_CONF_VARS['GFX']['im_path'] = 'C:\\programs\\imagemagick\\bin\\';
You can use the binaries of GraphicsMagic instead of ImageMagick as well.
They are easier to find and perform very well.
I'm writing a web app on my system using PHP5, but the app needs to be compatible with PHP4. Is there any way to emulate PHP4, or at least issue warnings?
Thanks.
As a general rule, if you avoid functions and arguments that were added in PHP5 (as shown in the documentation for each function), then it should work just fine with PHP4. PHP is good at backwards-compatibility like that.
There is no way to emulate PHP4 that I'm aware of. You need to run your code in a real PHP4 environment. Here's what I'd suggest:
Grab an old distro which includes a PHP4 package. Apparently, Ubuntu Dapper (6.06) does.
Install it into a VM (VirtualBox or VMWare) on your box.
Create a shared directory for the VM which points to your app dir on the real box.
Inside your VM, create a symlink from the webroot to the mount point of the shared directory.
Once that is done, you can more or less forget about the VM. All you need to do is keep it running. Change your code in your app dir as before. You can run it from your browser with the IP of the virtual machine.
(Perhaps you could even install an old version of XDebug in the VM and do proper remote debugging from within your IDE. But I don't know if XDebug is compatible with PHP4 at all.)
No, there isn't. You will have to install PHP 4 on the machine to provide the runtime environment. Or, even better, convince the client that PHP 4 in 2012 is... outdated.
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.
I've been given an existing PHP application that was originally deployed on a LAMP host.
Because most of our team are .Net developers, our boss wants it deployed in a windows environment.
Is it madness to expect this to just work?
Here's some additional info of the LAMP host:
Linux 2.4.32
PHP 5.2.6
No non-default modules
In my experience, it can be done and works fine.
The most important things I'd keep in mind are:
Use Apache on Windows, don't use IIS (even if it's possible)
Make sure you use unix style slashes for directories. Those work on both platforms.
Be very careful with case sensitivity. Since Windows is not case sensitive (though it is case preserving), if you include a file and spell it with the wrong case, it will work on Windows and fail on Linux.
Heck even just migrating from one hosted server to a different one usually requires SOME tweaking and adjustments. I don't imagine having to do it in a Windows environment would be much different. I was invloved in the migration of a large PHP app just last week and we (3 people) were able to get things going in about half a day.
It depends what's being done in the application. Two areas to look into though are where the app looks for files in the file system (using Linux specific paths?) and finding windows builds of any php modules (from PECL in particular).
Be very careful that at no point is exec called. A lot of extremely lazy code is written that will use this, and for obvious reasons it may not port well.
Some what i've experienced over the years:
Too old/new DB driver for PHP
Path problems
Change from 32 bit to 64 bit system or vice versa affects PHP internal integer handling (bit calculations returns weird results suddenly)
Locale and localization issues
Missing functions (manual have usually notes that it won't work or behaves differentially in windows)
File name casing
And always check and double check that Apache modules and PHP modules are atleast the same version as in old system.
It's also not too bad to run GNU/Linux virtualized on top of Windows with for example VMWare if code doesn't seem to like running in Windows.