I'm new to PHP development, so please have some patience with me here.
Once I get the "AH HA", I will be eagerly contributing.
With my PHP-5.2.5 source code installation, I was able to finally able
to use the WIN32*.DSP projects, with some changes as noted in a
previous post, to create a new PHP5TS.DLL file.
Comparing the two image sizes:
4,796,472 php5ts.dll (official 5.2.5 release)
4,763,648 php5ts.dll (new release_ts_inline)
With almost the same size gave me the initial "good news" impression
that I was doing it right.
Replacing the new PHP5DLL.DLL in my official WIn32 binary PHP525
installation, I tested it against many of my PHP extension scripts and
they all seems to work.
However in looking at the exported functions from the official release
binary and new this build, there is drastic different.
A diff of the DUMPBIN.EXE /EXPORTS shows items that were not included
and others included (see attached dumpbin-diff-php5ts.txt).
If someone can give me the skinny on the items in the diff file, what
are do they reflect, why there is a different, I can begin to get a
better handle of this PHP development environment.
This got me to think that I probably do not have a good handle on this
"CONFIGURE.JS" stuff or that the 2003 version of this
README.WIN32-BUILD-SYSTEM file is simply out of date given that there
are *.DSP project files available. I started fresh again with new copy
of PHP-5.2.6 and tried to follow this but I am getting an compiler error
with LIBXML/PARSER.H. I can probably figure this out, but I do have one
question. In this README file, it says in section 1:
You also need:
- bindlib_w32 [http://www.php.net/extra/bindlib_w32.zip]
- win32build [http://www.php.net/extra/win32build.zip]
but it doesn't say where to unzip this. I presume it would be off the
PHP-5.2.6\ folder, but under what folder names expected by the PHP
source code?
I would love to clean this all up for PHP Windows developers so if
someone can give me the "AH HA" behind all this, that would be great.
Once I am able to reproduce the exact official release PHP5TS.DLL image
for Win32, then I know I am on the right track.
TIA
--
Hector Santos
Hector Santos wrote:
...
I would love to clean this all up for PHP Windows developers so if
someone can give me the "AH HA" behind all this, that would be great.
Ok folks, never mind. The web page "Building from Source" at:
http://uk3.php.net/manual/en/install.windows.building.php
is making sense, answering all the questions for me, including this note
regarding the un-maintained/legacy DSW project files:
Building PHP using DSW files [PHP 4]
Compiling PHP using the DSW files isn't supported as of
PHP 5, as a much more flexible system was made available.
Anyway, you can still use them, but keep in mind that they
are not maintained very often, so you can have compiling
problems. To compile PHP 4 for windows, this is the only
available way though.
Once I get the "official maintained" command-line building method worked
out, I will update the Visual Studio project/solution files for both VS
6.0 and VS 2005 (which is what I have). When I cross that bridge, I'll
ask someone to test the VS 2008 Express version.
Thanks
--
Hector Santos
Hi Hector,
Building PHP using DSW files [PHP 4] Compiling PHP using the DSW files isn't supported as of PHP 5, as a much more flexible system was made available. Anyway, you can still use them, but keep in mind that they are not maintained very often, so you can have compiling problems. To compile PHP 4 for windows, this is the only available way though.
PHP4 is dead, any second spent on building it on windows is a wasted second :)
Once I get the "official maintained" command-line building method worked
out, I will update the Visual Studio project/solution files for both VS 6.0
and VS 2005 (which is what I have). When I cross that bridge, I'll ask
someone to test the VS 2008 Express version.
That would not be very useful. Nobody uses them and they are outdated.
The normal and supported way is the cscript + nmake, which works for
all VS (we are working on supporting 2k5/8 these days, incl. the
deps).
As Bjori pointed out, there is also updated information in the wiki,
please consider to read it.
Cheers,
Pierre Joye wrote:
Hi Hector,
Building PHP using DSW files [PHP 4] Compiling PHP using the DSW files isn't supported as of PHP 5, as a much more flexible system was made available. Anyway, you can still use them, but keep in mind that they are not maintained very often, so you can have compiling problems. To compile PHP 4 for windows, this is the only available way though.PHP4 is dead, any second spent on building it on windows is a wasted second :)
Ok, then may I suggest the *.DSP/DSW project files in the PHP5+
distribution either a) removed from the distribution, or b) updated.
Once I get the "official maintained" command-line building method worked
out, I will update the Visual Studio project/solution files for both VS 6.0
and VS 2005 (which is what I have). When I cross that bridge, I'll ask
someone to test the VS 2008 Express version.That would not be very useful. Nobody uses them and they are outdated.
Of course, thats a subjective opinion whether they are useful or not. :-)
I use project files and I am sure if they were made available (and
working) others will use them as well. One reason, and not exclusively
the reason, is that it provides the fast learning method to understand
the PHP model, framework and more especially, the organization of this
source files.
Of course, PHP has evolved with a high focus for consoled-based
configuration preprocessing logic that needs to be done. However, this
can also be done via a PRE-COMPILE and/or a special "CONFIGURE" project
which all other projects are dependent on. This project can use a
pre-compile setup that runs the cscript stuff.
As Bjori pointed out, there is also updated information in the wiki,
please consider to read it.
Which wiki? I found the link I noted in my previous message:
http://uk3.php.net/manual/en/install.windows.building.php
and this is helping. Is this info sufficient or is there more?
Anyway, at this moment I'm moving along and off hand, it appears the
remaining item which is ambiguous is the LIBXML and ICONV stuff. There
is a note about in the above link but doesn't say much about preparation.
I don't understand why the CVS bundle folder has this as dead files, if
they are still required for a build.
Thanks for your input Pierre.
--
Hector Santos
hi Hector,
Ok, then may I suggest the *.DSP/DSW project files in the PHP5+
distribution either a) removed from the distribution, or b) updated.
Removing them sounds like the best option yes.
Of course, thats a subjective opinion whether they are useful or not. :-)
I use project files and I am sure if they were made available (and working)
others will use them as well. One reason, and not exclusively the reason,
is that it provides the fast learning method to understand the PHP model,
framework and more especially, the organization of this source files.
It is not really subjective, it is based on our experiences and
feedbacks from other users. It is already enough work to keep
everything up and running. Project files have no benefit over the
current script. You can still use the VC GUI to debug or develop
without them.
However, I have very good hope that our current evaluation of the
CMake tools will allow anyone to generate them using a common script
(common to all platforms or build tools). But that's another topic :)
As Bjori pointed out, there is also updated information in the wiki,
please consider to read it.Which wiki? I found the link I noted in my previous message:
http://uk3.php.net/manual/en/install.windows.building.php
and this is helping. Is this info sufficient or is there more?
Anyway, at this moment I'm moving along and off hand, it appears the
remaining item which is ambiguous is the LIBXML and ICONV stuff. There is a
note about in the above link but doesn't say much about preparation.
We are also documenting these steps in the wiki. The required
libraries are also available for each VC version (built using these
versions). There is still a lot to do but we are on the right track.
If you like to write a howto for beginners out of your experiences,
you will be more than welcome :-)
I don't understand why the CVS bundle folder has this as dead files, if
they are still required for a build.
Which CVS bundle folder?
Cheers,
Pierre Joye wrote:
Ok, then may I suggest the *.DSP/DSW project files in the PHP5+
distribution either a) removed from the distribution, or b) updated.Removing them sounds like the best option yes.
I hope not. :-)
It is not really subjective, it is based on our experiences and
feedbacks from other users.
It still subjective. :-) Besides, I would venture the negative
experiences were based on the fact they never updated so people were
having "headache causing" issues. Based on what I seen so far, compiling
via current method is like pulling teeth. :-)
It is already enough work to keep everything up and running.
Sure, so the more automation "out the box" the better. Anyway, IMV,
you will never let go the need to support smart frontends.
Project files have no benefit over the current script.
Well, I don't see why not. You can do the same thing via project files
- see the "Custom Build", "Pre-Link", "Post-Build" tabs. In fact, I am
going to prove it when I can the chance. (BTW, I program almost
exclusively under a console, so its not "windows-users" thing.)
If you like to write a howto for beginners out of your experiences,
you will be more than welcome :-)
I have started this and my first test of instructions and new batch
files was perfect for php 5.2.5, however re-running it for PHP 5.2.6
errored out on an unresolved link for:
xmlXPathCompiledEvalToBoolean
Removing this from the release_ts\php5ts.dll.def allowed it to
successfully link.
I have not deeply stupid why yet, but I did noticed in the Changelog
comments related to this function:
2006-09-07 Rob Richards <rrichards@ctindustries.net>
* (PHP_5_2)
ext/libxml/php_libxml2.def:
MFH: fix def file for 2.6.26 (xmlXPathCompiledEvalToBoolean
required in .27)
* ext/libxml/php_libxml2.def:
fix def file for 2.6.26 (xmlXPathCompiledEvalToBoolean
required in .27)
I don't understand why the CVS bundle folder has this as
dead files, if they are still required for a build.Which CVS bundle folder?
http://cvs.php.net/viewvc.cgi/php-src/
--
Hector Santos
Hi Hector,
It is not really subjective, it is based on our experiences and
feedbacks from other users.It still subjective. :-) Besides, I would venture the negative experiences
were based on the fact they never updated so people were having "headache
causing" issues. Based on what I seen so far, compiling via current method
is like pulling teeth. :-)
What is hard in:
- mkdir c:\phpw32
- extract a php release in c:\phpw32\php-5.y.z
- extract the dependencies in c:\phpw32\php_builds
- run:
buildconf.bat
configure.bat [option your like to have}
nmake
It is already enough work to keep everything up and running.
Sure, so the more automation "out the box" the better. Anyway, IMV, you
will never let go the need to support smart frontends.
Smart? We do not support them whether they are smart or not is not the point ;)
Project files have no benefit over the current script.
Well, I don't see why not. You can do the same thing via project files -
see the "Custom Build", "Pre-Link", "Post-Build" tabs. In fact, I am going
to prove it when I can the chance. (BTW, I program almost exclusively under
a console, so its not "windows-users" thing.)
My point is to focus on what we actually need or work on. I will not
try to stop you on your attempt to fix the VC project files but it is
not what we need.
If you like to help us in the windows build process then there is
numerous ways to do it:
- help us to document the process
- help us to build more dependencies as well porting some of them to
Windows (and Visual c++ 6/2005/2008) - test our builds
The other reasons why projects file are useless for us is their static
nature. Unless we write a sln generator, it makes little sense to use
them when you work with php, PECL and your own extensions. And that's
we do for the PHP releases and our developments.
If you like to write a howto for beginners out of your experiences,
you will be more than welcome :-)I have started this and my first test of instructions and new batch files
was perfect for php 5.2.5, however re-running it for PHP 5.2.6 errored out
on an unresolved link for:xmlXPathCompiledEvalToBooleanRemoving this from the release_ts\php5ts.dll.def allowed it to successfully
link.I have not deeply stupid why yet, but I did noticed in the Changelog
comments related to this function:
Have you read the wiki? :) Please fetch the libxml we use for 5.2.6 here:
http://pecl2.php.net/downloads/php-windows-builds/php-libs/ (use the
right version with your compiler)
I don't understand why the CVS bundle folder has this as
dead files, if they are still required for a build.Which CVS bundle folder?
That's the main PHP CVS module.
Cheers,
Pierre Joye wrote:
Based on what I seen so far, compiling via current method
is like pulling teeth. :-)What is hard in:
- extract the dependencies in c:\phpw32\php_builds
Summarize, define dependencies.
I have not deeply stupid why yet, but I did noticed in the Changelog
comments related to this function:Have you read the wiki? :) Please fetch the libxml we use for 5.2.6 here:
Been there. But I'll check it out again later. The best success was
getting the EDIN zip and use this for all the extras. But there might
be issue with 5.2.6. I'll check that out later too.
Which CVS bundle folder?
That's the main PHP CVS module.
And what does that mean? Why are the bundle files dead? Is this related
to the idea that LIBXML is now part of the core?
--
Hector Santos
Been there. But I'll check it out again later. The best success was
getting the EDIN zip and use this for all the extras. But there might be
issue with 5.2.6. I'll check that out later too.
No, it's libxml. You need to update it. Same with many other things on the
link Pierre gave you, which replaces the old zip.zip because Edin no longer
has enough hours in the day to keep that updated.
And what does that mean? Why are the bundle files dead? Is this related
to the idea that LIBXML is now part of the core?
Someone (Sterling?) bundled it a million years ago and it was unbundled
later, you just can't build PHP without it. ext/libxml is a wrapper, not the
library itself.
- Steph
Pierre Joye wrote:
Based on what I seen so far, compiling via current method
is like pulling teeth. :-)What is hard in:
- extract the dependencies in c:\phpw32\php_builds
Summarize, define dependencies.
The libraries required by PHP. Like libxml2, iconv, etc. We should be
done with all PHP core dependencies soon (for vc6, 2k5 and 2k8).
I have not deeply stupid why yet, but I did noticed in the Changelog
comments related to this function:Have you read the wiki? :) Please fetch the libxml we use for 5.2.6 here:
Been there. But I'll check it out again later. The best success was
getting the EDIN zip and use this for all the extras. But there might be
issue with 5.2.6. I'll check that out later too.
Use the libxml2 from pecl2 will solve this exact issue. I also
recommend to fetch zlib and iconv. And Openssl if you need the
ext/openssl extension.
Which CVS bundle folder?
That's the main PHP CVS module.
And what does that mean? Why are the bundle files dead? Is this related to
the idea that LIBXML is now part of the core?
The only libraries that are bundled in the PHP sources (what you have
in cvs and in the source releases) are pcre and gd (for the extensions
enabled by default). There may be other in optional extensions (like
in mbstring).
LibXml2 is not part of the php sources and you have to use the same
version (or at least compatible with) the version we used.
Cheers,
Pierre
What is hard in:
- mkdir c:\phpw32
- extract a php release in c:\phpw32\php-5.y.z
- extract the dependencies in c:\phpw32\php_builds
- run:
buildconf.bat
configure.bat [option your like to have}
nmake
What is hard in it is that this is pretty alien for someone used to working
with .dsp files or whatever. Also, under Windows you need to bring the MS
headers into play, which means running vcvars. (vc32vars.bat, whatever.) The
same thing happens when you use Visual Studio, but you don't see it there
because it's disguised as Tools/Options/Directories and obviously is 'just
called'. In our setup it needs to be called explicitly, unless the MS
headers are already in your PATH. You'll also need to add the path to your
PHP libs and headers to vcvars.bat, you can do this via MSVC or manually.
configure.bat has been in 5_3 only for the last few weeks, so that part
depends on the PHP version you're building. But buildconf will tell you what
to do next anyway.
- Steph
Steph Fox wrote:
What is hard in:
- mkdir c:\phpw32
- extract a php release in c:\phpw32\php-5.y.z
- extract the dependencies in c:\phpw32\php_builds
- run:
buildconf.bat
configure.bat [option your like to have}
nmakeWhat is hard in it is that this is pretty alien for someone used to
working with .dsp files or whatever. Also, under Windows you need to
bring the MS headers into play, which means running vcvars.
(vc32vars.bat, whatever.) The same thing happens when you use Visual
Studio, but you don't see it there because it's disguised as
Tools/Options/Directories and obviously is 'just called'.
That's why I usually just tell people to run the shortcut in their start
menu that sets this up (Visual Studio Command Prompt) and then cd to the
php source ;)
In our setup
it needs to be called explicitly, unless the MS headers are already in
your PATH. You'll also need to add the path to your PHP libs and headers
to vcvars.bat, you can do this via MSVC or manually.
Err- no you don't steph :) you can use the --php_build="path" switch to
tell our configure system where to look for the libs, or just put them
in a library called php_build parallel to your php5 source, don't make
things harder then they have to be ;)
configure.bat has been in 5_3 only for the last few weeks, so that part
depends on the PHP version you're building. But buildconf will tell you
what to do next anyway.
- Steph