Monday, December 3, 2007
KDE and gamin
In the Ports builds of KDE 3.5.8, I enabled FAM (with gamin) support in kdelibs. Unfortunately, the tradeoff has been excessive CPU usage by gam_server, much more than is normal with GNOME. Some googling showed that this may not be unique to Cygwin, but can happen on Linux as well. While I'd be interested to hear if anyone has noticed any positive effects from the FAM support, at this point, I think I'm going to have to rebuild kdelibs without it.
SECURITY: link-grammar
A security vulnerability has been announced for link-grammar. A version bump to fix this is in CVS, and will be included in the next upload.
Thursday, October 11, 2007
PHP on Cygwin
Efforts to bring PHP to Cygwin have waxed and waned over the years. One of the big problems, at least with PHP5, was dealing with shared extensions, as discussed last year in this thread. Unfortunately the sources mentioned there are no longer available, so unfortunately I didn't even have that to start with.
PHP consists of multiple interpreters (called SAPIs) which serve different purposes, e.g. a command-line interface, a CGI interface, Apache modules, etc., together with dozens of extensions written in C, which can either be built in to the interpreter or can exist as loadable modules. Additional C extensions are also available on PECL, which must be built as shared modules, as they are installed after building the runtime.
PHP extensions require symbols that would normally be (on Linux) in the interpreters, but that doesn't work for Cygwin because all symbols must be resolved at link time. But if an extension is linked against one SAPI but loaded by another, a segfault will result.
The solution is, as is done with MSVC, is to build almost all the core sources into a shared library, then link the SAPIs (with just their SAPI-specific code) and the extensions against the library. Implementing this within the autotool framework took a lot of work to get right, but it looks promising so far: both the CLI and CGI load all the modules, PECL extensions can be built, and even better, PHP-GTK is working.
This solution does require a few minor changes to the build procedure for PECL extensions, hence I've added php.cygclass to cygport for this purpose; in most cases, a one-liner 'inherit php' is enough.
PHP, PHP-GTK, and several other sample PECL extensions are now in CVS; the PHP .cygport is heavily commented, which should help make sense of what was needed to make this work, for those who are interested. PHP, with separate packages for each of the standard extensions, as well as PHP-GTK, will be available in binary form with the next upload.
BTW, at this point I have no intention of packaging PEAR (pure PHP extension) libraries, as they require no compilation; instead, just install php-pear and install them as on any other platform.
If anyone is running Apache, then I would like to hear if those SAPIs are working; please post a comment below or to the mailing list.
Enjoy!
PHP consists of multiple interpreters (called SAPIs) which serve different purposes, e.g. a command-line interface, a CGI interface, Apache modules, etc., together with dozens of extensions written in C, which can either be built in to the interpreter or can exist as loadable modules. Additional C extensions are also available on PECL, which must be built as shared modules, as they are installed after building the runtime.
PHP extensions require symbols that would normally be (on Linux) in the interpreters, but that doesn't work for Cygwin because all symbols must be resolved at link time. But if an extension is linked against one SAPI but loaded by another, a segfault will result.
The solution is, as is done with MSVC, is to build almost all the core sources into a shared library, then link the SAPIs (with just their SAPI-specific code) and the extensions against the library. Implementing this within the autotool framework took a lot of work to get right, but it looks promising so far: both the CLI and CGI load all the modules, PECL extensions can be built, and even better, PHP-GTK is working.
This solution does require a few minor changes to the build procedure for PECL extensions, hence I've added php.cygclass to cygport for this purpose; in most cases, a one-liner 'inherit php' is enough.
PHP, PHP-GTK, and several other sample PECL extensions are now in CVS; the PHP .cygport is heavily commented, which should help make sense of what was needed to make this work, for those who are interested. PHP, with separate packages for each of the standard extensions, as well as PHP-GTK, will be available in binary form with the next upload.
BTW, at this point I have no intention of packaging PEAR (pure PHP extension) libraries, as they require no compilation; instead, just install php-pear and install them as on any other platform.
If anyone is running Apache, then I would like to hear if those SAPIs are working; please post a comment below or to the mailing list.
Enjoy!
Monday, October 8, 2007
SECURITY: libsndfile
The Gentoo Security team has announced a security vulnerability in all versions of libsndfile. I have rebuilt libsndfile with their patch, as well as for the new FLAC API. This is now in CVS, and will be included in the next upload.
Sunday, October 7, 2007
Pidgin and SILC
I just finished building Pidgin 2.2.1 with SILC support. But I came across an interesting problem:
SILC can either use GNU MP or its own code for multiple-precision arithmetic, and that causes the problem, because "silcmp.h" begins with:
For Pidgin, I just worked around this by adding -DSILC_MP_GMP to CPPFLAGS, but there should be a better solution:
Now you understand why the first solution is much better. But does anyone know how other distros deal with this? Comments Thoughtfully Considered.
SILC can either use GNU MP or its own code for multiple-precision arithmetic, and that causes the problem, because "silcmp.h" begins with:
#ifdef SILC_MP_GMPOnly one of those "mp_*.h" headers will be installed, depending on which MP is enabled. But that means that anything building against SILC needs to know if GMP was used or not; if it was, and you don't #define SILC_MP_GMP, then you obviously get errors at compile time (since mp_tma.h is not installed in that case).
#include "mp_gmp.h"
#else
#include "mp_tma.h"
#endif
For Pidgin, I just worked around this by adding -DSILC_MP_GMP to CPPFLAGS, but there should be a better solution:
- The best solution would be for SILC to add this flag to silc.pc via an AC_SUBST.
- Otherwise, Pidgin (and other software depending on SILC) should be calling in configure.ac:
CFLAGS_save="$CFLAGS"
CFLAGS="$CFLAGS $SILC_CFLAGS"
AC_CHECK_HEADER(mp_gmp.h, silc_mp_gmp=yes)
CFLAGS="$CFLAGS_save"
if test "x$silc_mp_gmp" = "xyes"; then
AC_DEFINE(SILC_MP_GMP, 1, [Define if SILC uses GNU MP])
fi
Now you understand why the first solution is much better. But does anyone know how other distros deal with this? Comments Thoughtfully Considered.
New blog
As it seems that blogging is becoming more common among open source projects, I decided it's only fitting that Cygwin Ports should join the club. Don't expect long essays here, but I will try to share my experiences from building and maintaining a wide variety of software on a not-so-common platform.
Also, this isn't meant to be a support forum; keep using the cygwin-ports-general mailing list for that.
Also, this isn't meant to be a support forum; keep using the cygwin-ports-general mailing list for that.
SECURITY: xfs
X.org has announced that xfs (<1.0.5) contains several security vulnerabilities; an update is already in Ports CVS and will be included in the next upload.
Subscribe to:
Posts (Atom)