Mailing-List: contact apreq-dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <432165FB.2060604@uk.radan.com>
Date: Fri, 09 Sep 2005 11:37:47 +0100
From: Steve Hay <steve.hay@uk.radan.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
MIME-Version: 1.0
To: Steve Hay <steve.hay@uk.radan.com>
CC: Randy Kobes <randy@theoryx5.uwinnipeg.ca>, apreq-dev@httpd.apache.org,
        dev@perl.apache.org
Subject: Re: [PATCH] Win32 doesn't have link()
References: <43203654.9040100@uk.radan.com>
 <Pine.LNX.4.63.0509082335030.10108@theoryx5.uwinnipeg.ca>
 <43213DD4.8040706@uk.radan.com>
In-Reply-To: <43213DD4.8040706@uk.radan.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Steve Hay wrote:

>Having looked a little closer, I now think that I was wrong in saying 
>that PerlLIO_link() is simply mapped to link().  I said that because the 
>Param DLL affected failed to link with a linker error regarding the 
>unresolved external "link".  When I ran Param.c through the C 
>preprocessor I found that "PerlLIO_link" had become "link".
>
>However, when I build the attached Foo module (using the same Perl, of 
>course) I find no such problems, and the CPP shows PerlLIO_link() is 
>mapped to win32_link() already.
>
>I'm struggling to figure out why PerlLIO_link() comes out differently 
>within the libapreq build.  Any ideas why this might happen?
>
OK, having looked much more closely I've now figured out what the 
problem is.  I'm not sure what to do about it, though.

First, a quick explanation of my (limited) understanding of how 
PerlLIO_link() is setup.

In the case where PERL_IMPLICIT_SYS is defined (as per ActivePerl 
configurations), perl's iperlsys.h has:

    #define PerlLIO_link(oldname, newname)                    \
        (*PL_LIO->pLink)(PL_LIO, (oldname), (newname))

which basically resolves to a call to this in perl's perlhost.h:

    int
    PerlLIOLink(struct IPerlLIO* piPerl, const char*oldname, const char 
*newname)
    {
        return win32_link(oldname, newname);
    }

Note that the symbol "link" isn't involved in any of that, which is why 
perls with PERL_IMPLICIT_SYS work OK.

However, in the case where PERL_IMPLICIT_SYS is not defined (as per my 
perl configuration), perl's iperlsys.h instead has:

    #define PerlLIO_link(oldname, newname)    link((oldname), (newname))

Also, note that perl's win32.h does *not* set WIN32IO_IS_STDIO in this 
case, which means that win32io.h does this:

    #define link            win32_link

Thus, in my case, we have the chain: PerlLIO_link => link => win32_link.

Now for the fun bit.  The Param.xs file in libapreq that I sent a 
(inappropriate) patch for includes "apreq_xs_postperl.h" after pulling 
in the Perl headers.  That post-perl header in turn includes mod_perl's 
"modperl_perl_unembed.h" [hence I'm Cc'ing the mp dev list], which 
contains this:

/* these three clash with apr bucket structure member names */
#undef link
#undef read
#undef free

The first of those breaks the chain described above, leaving me with 
just PerlLIO_link => link, which isn't defined in the Win32 CRT, hence 
my linker error.

Phew.

Now the question is:  What do we do about it?

I can't think of a good answer myself right now, but I'll be very happy 
to test anything that others come up with.  (I'm away next week; back on 
the 19th.)  I'll keep scratching my head for ideas too.

- Steve


------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.