httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Reilly" <trei...@livesoftware.com>
Subject ATTENTION: Please stop breaking DSO compatibility
Date Tue, 23 Mar 1999 23:50:21 GMT

I just checked out 1.3.6 and noticed with great frustration that even
though the module structure hasn't changed a DSO built with 1.3.4 will
not work with 1.3.6.  And a DSO module built with 1.3.6 will not work
with 1.3.4.

I've complained about this before so this time I actually looked at
the code and figured out what is broken.

>From http_config.c:545:

    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 excerpt from http_config.c shows the problem.
MODULE_MAGIC_NUMBER_MAJOR isn't a module stamp as one would think but
it is the date (1.3.4 is 19990108 and 1.3.6 is 19990320).

So with every new release anybody (like my company) that ships a DSO
with their product has to make a new DSO even though the module
structure didn't change.

I propose that the logic here be changed to:

    if (m->magic != MODULE_MAGIC_COOKIE) {

This will allow modules from 1.3.4 to happily work under 1.3.6 and
vice versa.  Then if the module structure is changed again (which
should be avoided if at all possible) just change MODULE_MAGIC_COOKIE
value.  This is what I thought the cookie was for in the first place
and why the breakage in 1.3.3/1.3.4 compatibility didn't bother me so
much.  

Can we please address this?  I like Apache and I'm proud to say that
my company provides precompiled DSO's for our customers but we can't
continue to do so if our DSO modules become obsolete with every new
minor Apache version.

Regards,

--
Tom Reilly
Live Software, Inc
http://www.livesoftware.com

Mime
View raw message