You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by sh...@us.ibm.com on 1999/01/11 15:24:11 UTC
Re: 1.3.4 Tarball
The 1.3.4 tarball compiles fine on Solaris 7
and AIX 4.3.2.
Shane Owenby shaneo@us.ibm.com
Re: 1.3.4 Tarball
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> > Ok, but what I meant was that the check in ap_add_module() should have
> > seen the discrepancy between the MODULE_MAGIC_NUMBER_MAJOR in the new
> > Apache binary vs. the MODULE_MAGIC_NUMBER_MAJOR compiled into the module
> > when it was compiled.
>
> But this check works only on the "struct module_struct" (which is in
> mod_php3.c which in turn _was_ recompiled). But the request_rec
> is part of the libmodphp3.a which is compiled at a totally different
> directory.
Ah.. Right. libmodphp3.a (and thus libphp3.a) does pull in the Apache
headers when it is compiled. It would be simple to have mod_php3.c call a
function in the library to verify that at least the
MODULE_MAGIC_NUMBER_MAJOR versions match. We'd obviously only want this
during the module initializer (php3_init_handler). As people slowly
migrate to Apache 1.3.4 I can see people getting hit by this. In fact,
now that I think about it, I had a weird SEGV as well that I blamed on
some code I was hacking. After a make clean of both trees and a cvs
update it fixed itself. Anyway, do you think that would be an appropriate
safeguard to toss in?
-Rasmus
Re: 1.3.4 Tarball
Posted by Martin Kraemer <ma...@mch.sni.de>.
On Mon, Jan 11, 1999 at 11:26:00PM -0500, Rasmus Lerdorf wrote:
> > > You didn't get a module version complaint from Apache?
> >
> > No. mod_php3.c was recompiled alright. But the knowledge about the
> > request_rec structure is also compiled into, say, functions/head.c
>
> Ok, but what I meant was that the check in ap_add_module() should have
> seen the discrepancy between the MODULE_MAGIC_NUMBER_MAJOR in the new
> Apache binary vs. the MODULE_MAGIC_NUMBER_MAJOR compiled into the module
> when it was compiled.
But this check works only on the "struct module_struct" (which is in
mod_php3.c which in turn _was_ recompiled). But the request_rec
is part of the libmodphp3.a which is compiled at a totally different
directory.
So what I meant was that people should be made aware of the fact that
with 1.3.4, they MUST throw their earlier compiled libraries in the
trashcan (this dependency is unusual for libraries which tend to be the
version independent part of a software component).
>
> fprintf(stderr, "Please contact the vendor for the correct version.\n");
>
> This annoying message has popped up for me a few times lately when I have
> linked an old libphp3.a into a newer Apache.
I wish I had seen such a message. Would have saved me several hours ;-)
Martin
--
<Ma...@Mch.SNI.De> | Siemens Information and
Phone: +49-89-636-46021 | Communication Products
FAX: +49-89-636-47816 | 81730 Munich, Germany
Re: 1.3.4 Tarball
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> On Mon, Jan 11, 1999 at 03:55:34PM -0500, Rasmus Lerdorf wrote:
> > > > [...] PHP3 [...] *MUST* be recompiled or
> > > > bad things(TM) will happen. I only realized this after a couple of
> > > > SEGV's.
> >
> > You didn't get a module version complaint from Apache?
>
> No. mod_php3.c was recompiled alright. But the knowledge about the
> request_rec structure is also compiled into, say, functions/head.c
> which directly set request_rec->content_type. All these assignments
> are bogus after a structure change.
Ok, but what I meant was that the check in ap_add_module() should have
seen the discrepancy between the MODULE_MAGIC_NUMBER_MAJOR in the new
Apache binary vs. the MODULE_MAGIC_NUMBER_MAJOR compiled into the module
when it was compiled.
This check:
if (m->version != MODULE_MAGIC_NUMBER_MAJOR) {
fprintf(stderr, "%s: module \"%s\" is not compatible with this "
"version of Apache.\n", ap_server_argv0, m->name);
fprintf(stderr, "Please contact the vendor for the correct version.\n");
exit(1);
}
This annoying message has popped up for me a few times lately when I have
linked an old libphp3.a into a newer Apache.
-Rasmus
Re: 1.3.4 Tarball
Posted by Martin Kraemer <ma...@hyperreal.org>.
On Mon, Jan 11, 1999 at 03:55:34PM -0500, Rasmus Lerdorf wrote:
> > > [...] PHP3 [...] *MUST* be recompiled or
> > > bad things(TM) will happen. I only realized this after a couple of
> > > SEGV's.
>
> You didn't get a module version complaint from Apache?
No. mod_php3.c was recompiled alright. But the knowledge about the
request_rec structure is also compiled into, say, functions/head.c
which directly set request_rec->content_type. All these assignments
are bogus after a structure change.
Martin
--
Martin Kraemer <Ma...@apache.org>
Re: 1.3.4 Tarball
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
> Oops! mutt lost my mail! This should have read:
>
> > One thing we should *DEFINITELY* mention on the Announcement is the
> > fact that all 3rd party libraries with "knowledge" about the layout
> > of the request_rec structure (notably, PHP3!!) *MUST* be recompile or
> > bad things(TM) will happen. I only realized this after a couple of
> > SEGV's.
You didn't get a module version complaint from Apache?
-Rasmus
Re: 1.3.4 Tarball
Posted by Martin Kraemer <ma...@mch.sni.de>.
On Mon, Jan 11, 1999 at 06:37:23PM +0100, Martin Kraemer wrote:
<nothing>
Oops! mutt lost my mail! This should have read:
> One thing we should *DEFINITELY* mention on the Announcement is the
> fact that all 3rd party libraries with "knowledge" about the layout
> of the request_rec structure (notably, PHP3!!) *MUST* be recompile or
> bad things(TM) will happen. I only realized this after a couple of
> SEGV's.
>
> Martin
--
<Ma...@Mch.SNI.De> | Siemens Information and
Phone: +49-89-636-46021 | Communication Products
FAX: +49-89-636-47816 | 81730 Munich, Germany
Re: 1.3.4 Tarball
Posted by Rasmus Lerdorf <ra...@lerdorf.on.ca>.
1.3.4 tarball looks ok on StrongArm Linux 2.0.36 (Corel Netwinder) with
PHP-3.0.7-dev + SNMP + IMAP + LDAP + XML + shared mem and semaphores.
-Rasmus