Re: CPAN Upload: A/AB/ABERGMAN/ponie-2.tar.gz - Ponie Development Release 2

On Tue, Mar 23, 2004 at 04:21:53PM +0000, Steve Hay wrote:
> Nicholas Clark wrote:
> 
> >On Tue, Mar 23, 2004 at 12:42:41PM +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?
But with both the .c and .o files in the top level directory?

> 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.

> I changed them all to "../../perl/<filename.h>".  Is that right, or 
> should I have directed it towards the headers of the installed perl 
> (i.e. the one that I ran parrot's Configure.pl with)?  It complained 
> again, of course, because I haven't got a perl/config.h...

No, it needs to be the perl headers supplied with ponie, as they have some
edits made to them. I think you'll need to cheat somehow and copy your
win32 config.h into the same directory as the other .h files. Oh:

> So then I copied perl/win32/config_H.vc to perl/config.h, but now it 
> whines about missing arpa/inet.h which perl.h includes.  Grr.  It really 
> isn't going to work unless an -I flag gets set properly somewhere when 
> building parrot.

Try running parrot's configure by hand as
Configure.PL "--ccflags= :add{ -I../perl}"
?

> 
> I see that parrot/classes has its own Makefile, so I reset the #include 
> lines that I'd changed and instead appended " -I..\..\perl 
> -I..\..\perl\win32 -I..\..\perl\win32\include" to the CFLAGS in it.

except that what I've described would be the near-automated way of getting
to the point you're at here:

> 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.

Nicholas Clark