I'm stuck with an OS X module problem and -mmacosx-version-min=10.5

[Patrick McManus <mc...@ducksong.com>]

Hi All,

Here's my problem - I have an apache module that has been happily
running on Mac Leopard for quite a while. I installed snow leopard recently.
If I build it on the SL host, it works fine there too.

Of course, the SL binary will not run on 10.5 - I get linker errors when
apache loads it. That's expected (ok, I forgot it, but its normal) - and
then I rebuilt the module with -mmacosx-version-min=10.5.

The linker errors resolved themselves. Hurrah.

However now the module is broken for me. The handler will run and
the right content-body will flow out, but content-type is consistently
text/plain even though ap_set_content_type(r, "text/html") has been
called.

If I remove the version-min-flag the correct content-type comes out (but
of course the binary is not portable anymore).

I tracked it down further to some interactions with filters and the
brigade code.

I have a simple example below which sets up a brigade directly out of
the handler, but it doesn't even do anything with it. (the real code
inserts it as a filter and deals with data streamed in - this change is
made to create a minimal example - the symptoms are identical). If this
brigade could is called and version-min is set - then content-type is
not honored. If EITHER the brigade calls or the version-min is omitted,
then content-type works fine. You'll see nothing is even done with the
brigade, and the HTTP request is a GET anyhow.


#include <unistd.h>
#include <sys/types.h>

#include "httpd.h"
#include "http_config.h"
#include "http_core.h"
#include "http_protocol.h"
#include "http_request.h"
#include "http_connection.h"
#include "http_log.h"

#include "apr_strings.h"
#include "apr_lib.h"            /* for apr_isspace */
#include "apr_base64.h"         /* for apr_base64_decode et al */
#include "apr_file_io.h"


#define MGI_TYPE   "application/mgi"
#define MGI_SCRIPT "mgi-script"


static int mgi_handler(request_rec *r)
{
  if (r->handler == NULL)
    return DECLINED;
  
  if (strcmp(r->handler, MGI_TYPE) && strcmp(r->handler, MGI_SCRIPT))
    return DECLINED;

  {
      apr_status_t rv;
      apr_bucket_brigade *bb;
      
      bb = apr_brigade_create(r->pool, r->connection->bucket_alloc);
      rv = ap_get_brigade(r->input_filters, bb, AP_MODE_READBYTES,
                          APR_BLOCK_READ, HUGE_STRING_LEN);
  }
  
    ap_set_content_type (r,"text/fake");
    ap_rwrite ("foobit", 6, r);
    
    return OK;
}

static void mgi_register_hooks(apr_pool_t *p)
{
    ap_hook_handler (mgi_handler, NULL, NULL, APR_HOOK_MIDDLE);
    return;
}

module AP_MODULE_DECLARE_DATA mgi_module =
{
    STANDARD20_MODULE_STUFF,
    NULL,    /* per-directory config creator */
    NULL,     /* dir config merger */
    NULL,
    NULL,  /* server config merger */
    NULL, // todo mgi_cmds,                 /* command table */
    mgi_register_hooks,       /* set up other request processing hooks
*/
};

Compiled like so (on 10.6  xcode 3.2.1 (and 3.2.0 - same result) using
the apache 2.2.13 distributed on SL)

gcc -Wall -Wno-multichar -fPIC -g -arch x86_64 -arch i386 -arch ppc -mmacosx-version-min=10.5 -I /usr/include/apr-1.0/ -I /usr/include/apr-1/ -I `/usr/sbin/apxs -q INCLUDEDIR` -DAPACHE_MODULE -c -o mod_mgi.o mod_mgi.c
gcc -Wall -Wno-multichar -fPIC -g -arch x86_64 -arch i386 -arch ppc -mmacosx-version-min=10.5 -I /usr/include/apr-1.0/ -I /usr/include/apr-1/ -I `/usr/sbin/apxs -q INCLUDEDIR` -DAPACHE_MODULE -fPIC -shared -flat_namespace -undefined warning -o mod_mgi.so mod_mgi.o


Like I said, either removing that brigade code that doesn't do anything or
removing the compiler flag gets the content-type text/fake that you
would expect.. but this example has been boiled down, the real module of
course needs a useful input filter and its really strange to expect
different output results based on that flag anyhow.

Is there potentially a problem because core apache isn't compiled with
that flag? And if that's the case, how could a 3rd party construct a
module that can run on either revision of the OS? Do I need multiple
binaries that are sorted out by the installer? Yech, hope that isn't the
case.

Thanks again for any help you can muster. I appreciate it.

-Patrick

Re: I'm stuck with an OS X module problem and -mmacosx-version-min=10.5

[Patrick McManus <mc...@ducksong.com>]

William, thanks for the response.

A clearer way of asking my question: "How do I (can I?) build a single
binary module that runs on both OS X 10.5 and 10.6 with the standard
apache package found on those systems - they are 2.2.11 and 2.2.13
respectively". 

Creating such a full executable (unrelated to apache) is easy,
-mmacosx-version-min=10.5 does the trick but that is giving me problems
with a module.

On Mon, 2009-11-16 at 22:18 -0600, William A. Rowe Jr. wrote:
> You mixed up httpd by detecting 10.6, doesn't matter what you told the
> compiler to do after configure.  Try
> 
> CC="gcc -mmacosx-version-min=10.5" ./configure
> 
> or something like that.

This advice applies to the building of the Apache Server itself, not my
module - right? I want to work with the standard apache packages
included in Leopard and Snow Leopard, not build and distribute them
myself.

Re: I'm stuck with an OS X module problem and -mmacosx-version-min=10.5

["William A. Rowe Jr." <wr...@rowe-clan.net>]

Patrick McManus wrote:
> 
> Of course, the SL binary will not run on 10.5 - I get linker errors when
> apache loads it. That's expected (ok, I forgot it, but its normal) - and
> then I rebuilt the module with -mmacosx-version-min=10.5.
> 
> The linker errors resolved themselves. Hurrah.
> 
> However now the module is broken for me. The handler will run and
> the right content-body will flow out, but content-type is consistently
> text/plain even though ap_set_content_type(r, "text/html") has been
> called.

You mixed up httpd by detecting 10.6, doesn't matter what you told the
compiler to do after configure.  Try

CC="gcc -mmacosx-version-min=10.5" ./configure

or something like that.