Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 10848 invoked by uid 6000); 24 Mar 1999 00:47:32 -0000 Received: (qmail 10838 invoked from network); 24 Mar 1999 00:47:30 -0000 Received: from unknown (HELO urizen.livesoftware.com) (209.125.2.254) by taz.hyperreal.org with SMTP; 24 Mar 1999 00:47:30 -0000 Received: (qmail 2583 invoked by uid 10003); 23 Mar 1999 23:50:22 -0000 From: "Thomas Reilly" To: new-httpd@apache.org Subject: ATTENTION: Please stop breaking DSO compatibility Mime-Version: 1.0 (generated by tm-edit 7.106) Content-Type: text/plain; charset=US-ASCII Date: 23 Mar 1999 16:50:21 -0700 Message-ID: Lines: 48 X-Mailer: Gnus v5.5/Emacs 20.3 Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org 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