Re: CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2
[email protected] (Steve Hay) Fri, 26 Mar 2004 12:34:26 +0000
| Newsgroups | perl.ponie.dev |
|---|---|
| Message-ID | <[email protected]> |
Nicholas Clark wrote:
>On Tue, Mar 23, 2004 at 04:21:53PM +0000, Steve Hay wrote:
>
>
>>>>Sadly win32 doesn't start out with a config.h (neither parrot's one, nor
>>>>perl's one (which actually resides in win32/ on Win32)).
>>>>
>>>>
>>>>
>>>>
>>>So how does win32 make a config.h?
>>>
>>>
>>>
>>It's copied from win32/config_H.vc -- see .\config.h target in
>>win32/Makefile.
>>
>>
>
>OK. So I guess that means that on win32 ponie's configure needs to run this
>makefile target (in the appropriate win32 makefile)
>
>On win32 is the regular perl build run from inside the win32 directory?
>
Yes.
>But with both the .c and .o files in the top level directory?
>
Correct, although there are also a few extra .c files in the win32
directory too. (And their object files are written to the win32
directory too.)
>
>
>
>>So now I've copied the 3 .pmc's files into parrot/classes and tried
>>building parrot again. It complains that it can't find the perl header
>>files -- perl5av.c #includes "EXTERN.h", "config.h" and "perl.h", but
>>parrot presumably isn't being compiled with appropriate -I flags to find
>>them.
>>
>>
>
>Yes, I guess so. config.h is generated (on Unix by the shell script
>config_h.SH, on windows from the makefile target you describe) but the
>other two files exist on disk from the start. So I guess that parrot
>isn't being compiled with the appropriate -I flags. ponie's Configure.pl
>runs parrot's Configure.PL like this:
>
> system($^X,'Configure.pl', "--gc=libc",
> "--ccflags= :add{ -I$dir/perl}") && die "error";
>
>so it's adding the -I flag to parrot. You ran parrot's Configure.PL
>directly, didn't you? So that extra -I flag won't be there for you.
>[...]
>
>
>Try running parrot's configure by hand as
>Configure.PL "--ccflags= :add{ -I../perl}"
>?
>
Yes, that's tidier than hacking files. I had to use ../../ rather than
../, though, because it is files in parrot/classes rather than files in
parrot/ which need to find the Perl headers. (The build process
presumably cd's into parrot/classes rather than compiling everything
from the top level parrot/ directory.) I also had to add a couple more
paths:
perl Configure.pl "--ccflags= :add{ -I../../perl -I../../perl/win32
-I../../perl/win32/include}"
otherwise it still couldn't find config.h and arpa/inet.h etc.
>>Now I get the mess at the foot of this mail. I get much the same result
>>if I use the "installed perl"s header files instead (by appending "
>>-IC:/perl/lib/CORE" to the CFLAGS in parrot/classes' Makefile).
>>
>>I'm at a loss what to do to fix this. Looks like I won't be getting a
>>ponie just yet :(
>>
>>
>
>
>
>> C:\perl\bin\perl.exe pmc2c2.pl --dump *.pmc
>>'classes\perl5av.c'
>>perl5av.c
>>c:\progra~1\micros~2\vc98\include\winsock.h(800) : error C2143: syntax
>>error : missing ')' before '.'
>>c:\progra~1\micros~2\vc98\include\winsock.h(800) : error C2143: syntax
>>error : missing '{' before '.'
>>c:\progra~1\micros~2\vc98\include\winsock.h(800) : error C2059: syntax
>>error : '.'
>>c:\progra~1\micros~2\vc98\include\winsock.h(800) : error C2059: syntax
>>error : ')'
>>c:\progra~1\micros~2\vc98\include\winsock.h(804) : error C2143: syntax
>>error : missing ')' before '.'
>>c:\progra~1\micros~2\vc98\include\winsock.h(804) : error C2143: syntax
>>error : missing '{' before '.'
>>c:\progra~1\micros~2\vc98\include\winsock.h(804) : error C2059: syntax
>>error : '.'
>>c:\progra~1\micros~2\vc98\include\winsock.h(804) : error C2059: syntax
>>error : ')'
>>
>>
>
>
>
>>If it helps at all, the relevant lines (797-820) of winsock.h are:
>>
>>=====
>>HANDLE PASCAL FAR WSAAsyncGetServByName(HWND hWnd, u_int wMsg,
>> const char FAR * name,
>> const char FAR * proto,
>> char FAR * buf, int buflen);
>>
>>HANDLE PASCAL FAR WSAAsyncGetServByPort(HWND hWnd, u_int wMsg, int port,
>> const char FAR * proto, char FAR * buf,
>> int buflen);
>>
>>
>
>
>Not hugely clear, but as there as no '.'s or '}' in any of those, there must
>be quite a lot of pre-processor action going on there.
>Are you able to just run the pre-processor for one of those failing PMC
>c files, and find out what it turns those function prototypes into?
>My hunch is that one of
>
>1: parrot + perl includes 1 header too many, that defines another pre-processor
> symbol which is used as a name in one of the above prototypes, and hence
> causes chaos
>2: parrot + perl includes 1 header too few, and something fails to expand
>3: parrot itself defines something that clashes, but it doesn't #include the
> file which causes the problem; that file is included as a side effect of
> perl
>
>is true.
>
>Comparing the pre-processor's output for the above from ponie (where it fails)
>with the pre-processor output for the above section of header when included
>by a perl source file during a regular perl build should give the game away.
>
>On Unix you can get this output easily because the Makefile has a .c.i
>rule to just run the pre-processor, but I don't see the equivalent rule in
>win32/Makefile.
>
Running the preprocessor is easy enough by hand (cl -E instead of cl
-c), but I still can't see what's wrong.
If I try to compile perl5av.c from within parrot/classes using the
compiler command-line that was output at the start of the parrot
compilation:
cl -nologo -Gf -W3 -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT
-I../include -I../../perl -I../../perl/win32 -I../../perl/win32/include
-ZI -I./include -DHAS_JIT -DI386 -c perl5av.c
then I get the same errors as above.
If I now change the "-c" to "-E" to just run the preprocessor (and
redirect the output because it's huge), then I only get the macro
redefinition warnings - no errors - but we can now see the '.' that cl
-c complains about:
HANDLE PASCAL FAR WSAAsyncGetServByName(HWND hWnd, u_int wMsg,
const char FAR * name,
const char FAR * proto,
char FAR * buf, int buflen);
has been expanded to:
HANDLE __stdcall WSAAsyncGetServByName(HWND hWnd, u_int wMsg,
const char * name,
const char * proto,
char * buf, int obj.u._b._buflen);
In fact, just running this:
#include "parrot/parrot.h"
#include "EXTERN.h"
#include "config.h"
#undef HAS_OFF64_T
#include "perl.h"
through the preprocessor expands buflen in the same way. If I just drop
the #include parrot/parrot.h then buflen is not expanded at all and we
just get:
HANDLE __stdcall WSAAsyncGetServByName(HWND hWnd, u_int wMsg,
const char * name,
const char * proto,
char * buf, int buflen);
So your third hunch was correct. (It is perl, rather than parrot, that
#includes winsock.h)
It looks like the buflen expansion comes from this in
parrot/include/parrot/pobj.h:
/* BEGIN DEPRECATED BUFFER ACCESSORS */
/* macros for accessing old buffer members */
#define bufstart obj.u._b._bufstart
#define buflen obj.u._b._buflen
/* END DEPRECATED BUFFER ACCESSORS */
It could do with being more than just deprecated ;)
So I'm stuck until those macros are removed. Just commenting them out
doesn't work because they are currently used in various places. I'll
wait until the issue is resolved rather than wasting time hacking it
around myself.
- 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.