Return-Path: Delivered-To: new-httpd-archive@hyperreal.org Received: (qmail 12406 invoked by uid 6000); 4 Apr 1998 16:28:07 -0000 Received: (qmail 12385 invoked from network); 4 Apr 1998 16:27:58 -0000 Received: from slarti.muc.de (193.174.4.10) by taz.hyperreal.org with SMTP; 4 Apr 1998 16:27:58 -0000 Received: (qmail 15867 invoked by uid 66); 4 Apr 1998 16:26:05 -0000 Received: by en1.engelschall.com (Sendmail 8.8.8) for new-httpd@apache.org id SAA04065; Sat, 4 Apr 1998 18:26:17 +0200 (MET DST) Message-Id: <199804041626.SAA04065@en1.engelschall.com> Subject: Re: building with mod_so To: new-httpd@apache.org Date: Sat, 4 Apr 1998 18:26:17 +0200 (MET DST) From: rse@engelschall.com (Ralf S. Engelschall) Organization: Engelschall, Germany. X-Home: http://www.engelschall.com/ X-Mailer: ELM [version 2.4ME+ PL39 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org In article <9804041605.AA13117@gensym1.gensym.com> you wrote: > I have been building with mod_so configured out. > If I enable it, then it fails on: hp9000s700, hp9000s800, and mips. > On the mips, and hp9000s800 it then complains about how perl is missing. > Is perl part of what we require of all users? - ben hyde >[...] > ** FAILURE: Sorry, no shared object support available. > ** Either compile all modules statically (use AddModule instead > ** of SharedModule in the Configuration file) or at least provide > ** us with the apropriate compiler and linker flags via the > ** CFLAGS_SHLIB, LDFLAGS_SHLIB and LDFLAGS_SHLIB_EXPORT entries > ** in the Configuration file. A few facts: 1. mod_so cannot be used under HP/UX because this system has no dlopen() function. So, the definitive list of supported platforms is in Configuration.tmpl. Any other platform which has dlopen() could be used, but only because... 2. when a platform is used for which we have no explicit knowledge about shared object support but Configure sees that shared object support is wanted (because you use SharedModule or at least compile with mod_so), he usually had to fail. But instead of failing immediately, we give the platform a second chance. We look for an existing Perl interpreter and if one exists and _already uses dlopen_ we guess the shared object compilation flags from it and instead of failing with an error we proceed with just a warning. If no Perl exists, we fail immediately, of course. So, Perl is not needed. Configure just tries to use its knowledge for shared object support before failing instead of failing immediately. In other words: You can only use mod_so on platforms which have the dlopen-style interface. And when the platforms is already configured by us for shared object support, all is fine. If not, we try the second Perl-based chance. And if this no success we finally fail. Just one thing is confusion: The error from the Perl test which confuses people like it confused you. But I don't know how I can get rid of it. It is the line: if [ ".`perl -V:dlsrc 2>/dev/null | grep dlopen`" != . ]; then it works correctly, of course, but on failure case with this confusion "perl: not found". Even with the 2>/dev/null above. What else have to be arranged to avoid this confusion error message? Any hints? Ralf S. Engelschall rse@engelschall.com www.engelschall.com