|Building php modules with cygwin/mingw|
Build a win32 module for php, which depends on another library
First of all, sorry if it's the wrong forum, I feel like being brainwashed after all the problems (trying to solve them, searching on the web, downloading packages, configuring packages, compiling, linking, etc)... And I'd like to apologize for the long post too :-p
I've spent long hours (and some nights) on making a php module called php_paradox working on win32, the module itself I could compile with visual studio (lucky me I had developed an another module recently, so I did not had to do from the beginning), but this php module uses a shared library called pxlib, and pxlib uses some other packages, like libiconv an libintl.
First (and the only time I succeeded), I used the binary distribution of pxlib (dll, lib and h files included), only had to compile iconv (visual studio needed the header files), but I could only do that with mingw. Then I compiled the php module with visual studio. So far so good, but there were some problems:
- the php module requires the dlls of iconv and pxlib to be present in the target system, otherwise it will fail to load
- the size of the iconv.dll was far bigger than normal (1.5Mb)
- last but not least, the binary distribution of pxlib contains a bug (see Footnote #2)
So I wanted to recompile everything on cygwin (see Footnote #1);
First the configure of pxlib failed on several places, I could correct those (some missing dependency and so), then the compiling failed because of corrupt includes in the source (maybe configure went wrong? - din't noticed then), but finally I could compile it. As a result I got the cygwin binaries (lib.a and lib.la), but then I have no idea how to turn these into a windows dll (well finally I found out I could do that with gcc, but the resulting dll was huge again), but I could not figure out how to make the lib files needed for visual studio, and that the header files generated by configure can be used for the (non existing) lib file or not. And I'm also afraid of being dependent on the cygwin dll's, that I'll need to keep them along the generated dll...
Then I thought to compile php from scratch (with cygwin), but I have no idea how to make the mod_paradox module compiled with the whole package (but as a shared library), or that is there a way to compile only one extension with the php's build system, not the whole thing?
To summarize (some) dark areas of my knowledge: How to build proper, distributable win32 shared libraries (dlls) with .lib and .h files using cygwin?
Any advice are welcome!
Tried to compile pxlib with mingw too, but tons of packages were not present, like perl, and within that several perl packages like html::parser, and that I could not install into mingw, upon compiling I get long lines of c syntax errors (while the code looks okay).
All of this are caused by a stupid printf(stderr,'...') line in pxlib, which fills the error log with debug messages when using certain functions in php...
Run it on linux.
Why bash your head against a wall?
Sure WAMP works out of the box on Windows. But the further you get from the well-tested core set of programs (i.e. Apache and it's common modules, PHP and it's common modules, MySQL) the more trouble you are going to have.
Why not run this stuff on the platform it was designed to run on?
Cygwin != Linux. Windows, outside of the Cygwin box, moreso.
lol, you are right.
From what i have written, you should already understand that I'm not a linux fellow, there are times when i feel tempted to install one and start experimenting, but this is not one of those moments, esp. not after those "dark" hours :-) And to be honest, I'm running several windows servers (with varying role), and I'm quite happy with that, every time I see a linux sysadmin working on a problem I feel pity for them (typing 10 lines of code to do a simple task). Sure it has some exaggeration in it (and me too), but this is how I feel (when it is not one of "those times"). So running linux is not an option - yet.
One more thought/question; I have been requested to develop a simple tool which reads data from paradox databases (on a win32 server, but let's ignore that). To make this in php, I need the paradox php module enabled - and that's not part of the distribution, but downloadable as a PECL module. So suppose I develop this tool on my linux box, I take the php source with me, then at the customer's site (suppose they have linux too) I have to rebuild their php completely to make this small tool working?
Anyway, my original question remains, how to build a proper win32 dll (with .h and .lib files) for later linking?
|every time I see a linux sysadmin working on a problem I feel pity for them (typing 10 lines of code to do a simple task). |
And every time I see a Windows sysadmin working on a problem, I feel pity for them, downloading 10 different GUI packages that don't quite do the job, when they could have done it in one line of piped command-line programs in Linux... ;)
|I have been requested to develop a simple tool which reads data from paradox databases |
That's still around?!
Sorry, I hadn't caught that. It's been so long since I've seen Paradox in the wild, that I assumed you were talking about something else.
Why? Does this have to be a web app?
I'd find whatever is most commonly used for this. ObjectPal?
OK, no, I wouldn't do this on Linux, since Paradox isn't a Linux app - it's a Windows app. I just don't know that I'd try to force-fit it into PHP.
Sounds like there is a PHP module for it that is buggy - another good reason to try to find another way to do it, rather than trying to fix the buggy module.
|As a result I got the cygwin binaries (lib.a and lib.la), but then I have no idea how to turn these into a windows dll |
You can't. They are different library formats for different operating systems. You can't convert one to the other. Libraries that are meant to build on both Windows and Linux have different build processes for each, and almost always conditionally-compiled code as well. (So, the code is different in some details for each OS.)
A Linux .so is similar to a Windows .dll, but there's no way to convert one to the other. A .a is just a static library similar with a windows .lib. A .la is a file needed by the linker to link references to .so shared libraries.
Ever see that TV commercial?
You got your marshmallows in my peanut butter!
No, you got your peanut butter in my marshmallows!
Well you are right in your first point, but don't forget that once the windows sysyadmin found the right one, the "job" can be done with a few mouse clicks ;-)
Yes, paradox is still around (was surprised too) and I tried to make it with delphi first, but there I could only do with BDE (which I don't like, but ODBC didn't work, and could not found a native driver), and even then I had issues with codepages. Then I remembered that php has something for paradox, so I went to investigate that option, and I could set it up and running relatively quick, so I put my vote for php then (and actually I like it much more compared to other languages). But after I made it working, I discovered this silly printf() thing, so there was no turning back (unless starting all over again), so instead I bypassed the problem with a nasty freopen(). But anyway;
The silly thing is, that the php module works well, the library it uses (pxlib) also working well, only the developer forgot to take away his/her debug stuff. All I would need to do is to recompile the library, but I can;t get past of this soundstobe simple thing :-/
My phrasing was wrong, it's not the binaries what I want to make it go on windows, but build the library so at the end I get windows binaries. Sure it's possible, there are tons of libraries made for cross platform, and both the pxlib thing and the php module is like that for sure. The only problem is me, the one who don't know (almost) nothing about gnu c and the tools needed for this, the one without any knowledge of the build process (even the makefiles are quite mysterious for me - for example how do I know what targets are defined in a makefile?).
I feel so dumb when it's up to compiling "linux style" software, I don't have the slightest experience and I always end up on www.google.com when something goes wrong.
So let me rephrase my question; If a library is known to be made for cross-platform, how I can (figure out the necessary steps to) make it build windows binaries using cygwin (and have the .h and .lib files generated with them)?
Ps.: Peanut butter is not my favorite, the other one is missing from my dictionary (yeah, that's lacking some knowledge too), so I go for the first one: Peanut butter can not be much worse than it is already whatever happens to be in it :-)
|So let me rephrase my question; If a library is known to be made for cross-platform, how I can (figure out the necessary steps to) make it build windows binaries using cygwin (and have the .h and .lib files generated with them)? |
Although, technically, you probably can, I wouldn't recommend it.
This would be termed "cross-compiling".
Generally, cross-platform packages are intended to be built in the native environment of the target.
That is, a cross-platform package that is designed to be built for either Windows or Linux is intended to be built with make/Gnu C for Linux or Visual C++ for Windows. It will come with both a make file and a Visual C++ project file.
You want to build a Linux package with Visual C++ (not sure if this is even possible) or a Windows package with make/Gnu C, you're on your own!
Cross-compiling under Gnu C is commonly done only for firmware - for example for the ARM processor. Gnu C won't do that out-of-the-box, though. You need to obtain or build a version of Gnu C that runs on your development platform but targets the execution platform. (Not all combinations are available in binaries.)
Now, Linux and Windows (typically) share the same hardware architecture. But not the same library and object formats. At minimum, you'd need an alternate linker and library builder.
I wouldn't try it. If you need to build a Windows app or library, use Visual C++. Or use a Windows Gnu C (not real common).