Re: Pre-ITP: apache/mod_php

[Brian Dessent <brian at dessent dot net>]

Igor Pechtchanski wrote:

> > B) Compiled in cygphp4.dll (bundled libs) / won't work shared:
> > bcmath, calendar, dba (gdbm, cdb, cdb_make, inifile, flatfile), dbase,
> > dbx, dio, exif, filepro, ftp, mysql, pcre, xml
> 
> This may be a naive question, but why can't they work as shared libs?
> I've found that the main problem with dlopen()ing shared libs that depend
> on other shared libs is that the other shared libs have to be in the PATH.
> Is there anything beyond that that's required?

I had thought of that one.  All the extension DLLs are linked against
the main cygphp4.dll, which itself is not in the path; it lives in
/usr/lib/apache/.  I tried adding that to the path of the service using
cygrunsrv, but I still got the errors.  I suppose I never tried putting
/usr/lib/php4/20020429/ (the dir where the extensions are stored) in the
path - but doesn't the Windows .DLL search order go: "cwd, directory of
.dll, path"?

> > Note also: Currently gd is picking up the X11 libXpm, but with some work
> > it could be told to find the noX version (and add dependency on that
> > package instead.)  That would at least eliminate a dependency on libX11
> > for the -gd package, which could save considerable hassle if someone
> > didn't want any of the xorg stuff.  Or *gulp* I suppose it might be
> > possible to offer both, I think Debian does this.
> 
> Umm, frankly, I see no reason to have apache (a daemon serving external
> clients) depend on X.  Does gd use libXpm for anything other than image
> conversion?  If not, I'd go with the noX version.

Yes, that's all it uses it for.  And I agree about not pulling in X11
server :-).  I think the reason it stuck in my mind must have been that
some distros wrestle with having both the X11 / noX flavors of Xpm, but
since the noX lib is packaged seperately in Cygwin and can coexist with
xorg packages, there's no reason not to just require that regardless of
presence/lack of libX11.

> Since setup doesn't support subcategories, an artificial grouping using
> the "apache-" prefix is preferable (unless the package truly is
> independent).  I'd also prefer "apache-mod_php4" to "apache-php4", since
> it reflects what other distributions call it, and allows a separate
> distribution of command-line php4 with CGI bindings for apache as
> "apache-php4".  Since setup is now resizable, don't worry too much about
> longer package names.

Yes, I do like the idea of having all the related packages grouped
together with the Apache prefix, so I think I agree that
"apache-mod_php4", "apache-mod_ssl", and so on are good choices.  Good
point also about leaving "apache-php4" for a CGI version.

> It would certainly be easier to have this setup with apache2 (which pulls
> in separate config files from a given directory, rather than having a
> monolithic httpd.conf).  For apache 1.3 I'd say it's not worth the bother.

You can actually do "Include /etc/apache/conf.d" with 1.3 and it will
include all the files in the directory - Debian uses this for their
modular config.  But, the PHP module activation/deactivation would
actually be done in php.ini and would probably be the same regardless of
Apache version.

> I think setup is about due for a subcategory patch...  Any volunteers? ;-)

Heh, if we start going down the line of "wouldn't it be nice if
setup.exe had <X>" then we'll never return to on-topic discussion.  :-)

Brian