Return-Path: Delivered-To: apmail-new-httpd-archive@apache.org Received: (qmail 78708 invoked by uid 500); 4 Apr 2000 13:19:32 -0000 Mailing-List: contact new-httpd-help@apache.org; run by ezmlm Precedence: bulk X-No-Archive: yes Reply-To: new-httpd@apache.org list-help: list-unsubscribe: list-post: Delivered-To: mailing list new-httpd@apache.org Received: (qmail 78692 invoked from network); 4 Apr 2000 13:19:31 -0000 From: "William A. Rowe, Jr." To: Subject: RE: ap_cleanup_fn_t Date: Tue, 4 Apr 2000 08:19:24 -0500 Message-ID: <000001bf9e38$66bb95b0$345985d0@corecomm.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 In-reply-to: <000901bf9dfe$3a9f36b0$345985d0@corecomm.net> Importance: Normal X-Spam-Rating: locus.apache.org 1.6.2 0/1000/N > > (See the Windows dll linkage warnings on ap_opt* variables in > > APR. It's just blind luck it works at all the way it is) > > Actually, it isn't :~) > > Since it's both export and import, the linker resolves to export > for APR, since it can't be both. Of course, this raises 8 errors > (the months and days as well). On the client side, it strictly > sees the import (the export side buried in the .c declarations). > So - it works. But anyone using those variables within the APR > dll itself resolves themselves through their very own module's > fixup table (talk about roundabout!) Did I say Linker? The compiler resolves that discrepancy. That's why it works.