[PATCH] Re: [perl #25239] Platform-specific files not granular enough
Leopold Toetsch
> Hopefully in time to make the feature freeze, here's an effort at solving this problem.
Looks really good. I've applied it here (with little tweaks in
Configure/Step.pm) and it works fine.
> Testing very much requested, most especially on Darwin and Win32.
Yeah. Anyway, I'll apply it if no one hollers. If something will break
on these platforms, it should be fixable easily.
BTW what is aix.s doing? Could you add some comments please.
> Adam
Thanks for this big patch,
leo
Adam Thomason
> From: Leopold Toetsch [mailto:l...@toetsch.at]
> Sent: Thursday, February 19, 2004 1:00 AM
> To: Adam Thomason
> Cc: perl6-i...@perl.org
> Subject: Re: [PATCH] Re: [perl #25239] Platform-specific
> files not granular enough
>
> BTW what is aix.s doing? Could you add some comments please.
It's one of the fixups for JIT under AIX (not actually relevant to this
patch, whoops). Two asm functions (ppc_sync and ppc_dcbf) are required
to guarantee cache goodness. The extra stabs and other junk are from
-g. I'll try to clean it up and document it for the forthcoming AIX
patch. ATM it does nothing since these funcs aren't called in
functional scenarios, i.e. no harm in omitting it for now.
Adam
Leopold Toetsch
Dan Sugalski
>Attached patch is tested on Linux, AIX, and OpenBSD. It does
>twiddle the order of includes and declarations, so there might still
>be problems. Testing very much requested, most especially on Darwin
>and Win32.
I've applied this locally and it's building in the background -- it
looks darned good, and I'm happy to get it applied. If it breaks
Win32 (and I'd bet not) then we can fix it. Definitely gets us in a
really good position, though. Thanks!
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Jonathan Worthington
From: "Dan Sugalski" <d...@sidhe.org>
To: <bugs-...@netlabs.develooper.com>; <perl6-i...@perl.org>
Sent: Thursday, February 19, 2004 3:10 PM
Subject: [PATCH] Re: [perl #25239] Platform-specific files not granular
enough
> At 8:01 PM +0000 2/18/04, Adam Thomason via RT wrote:
> >Attached patch is tested on Linux, AIX, and OpenBSD. It does
> >twiddle the order of includes and declarations, so there might still
> >be problems. Testing very much requested, most especially on Darwin
> >and Win32.
>
> I've applied this locally and it's building in the background -- it
> looks darned good, and I'm happy to get it applied. If it breaks
> Win32 (and I'd bet not) then we can fix it. Definitely gets us in a
> really good position, though. Thanks!
The good news (for Dan) is that he didn't place any money on his bet about
this breaking on Win32. The bad news is that it does break Win32...
src\exceptions.c
exceptions.c
c:\documents and settings\jonathan\desktop\pow\parrot\src\exceptions.c(125)
: error C2065: 'SIGQUIT' : undeclared identifier
NMAKE : fatal error U1077: 'F:\Perl\bin\perl.exe' : return code '0x2'
Stop.
I'll try and take a look later tonight.
Jonathan
Leopold Toetsch
> src\exceptions.c
> exceptions.c
> c:\documents and settings\jonathan\desktop\pow\parrot\src\exceptions.c(125)
> : error C2065: 'SIGQUIT' : undeclared identifier
Seems that dumpcore is used from generic/signal.h
You could try to create an empty win32/signal.h or insert
#undef dumpcore
in a file, that is included after signal.h's code.
> Jonathan
leo
Jonathan Worthington
From: "Leopold Toetsch" <l...@toetsch.at>
To: "Jonathan Worthington" <jona...@jwcs.net>
Cc: <perl6-i...@perl.org>
Sent: Thursday, February 19, 2004 7:06 PM
Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not granular
enough
Creating an empty signal.h works fine, but then I ran into a load of errors
in platform.c. On further inspection, we're coming out with this in
platform.c:-
--
#include "parrot/parrot.h"
/*
** config/gen/platform/win32/begin.c:
*/
#include <windows.h>
--
Somewhere in parrot/parrot.h, something causes winsock.h to be included. I
can't for the life of me find *where*, but it is being. The problem with
this is that it's being included before windows.h is being included, which
means stuff that needs to be defined isn't.
I've attached a patch which causes stuff in begin.c to be put before the
#include "parrot/parrot.h" line, which fixes up this problem. I don't know
if it's the right thing to do, but it's the best one I could think of.
Please create the empty signal.h too - BTW, how should I have gone about
including that in my patch (e.g. what's the flag for cvs diff)?
Thanks,
Jonathan
Adam Thomason
> From: Jonathan Worthington [mailto:jona...@jwcs.net]
> Sent: Friday, February 20, 2004 4:47 PM
> To: perl6-i...@perl.org
> Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not
> granular enough
>
>
I thought this might come up. For non-specific, must-be-first preprocessor directives (like #include <windows.h>), your solution is probably just fine. There aren't terribly many pathological headers like that, so this fix should cover the sane cases. If a platform comes along that is particularly sensitive to ordering w.r.t. #defines and #includes, it might be necessary to let it recommend an ordering for the concatenation relative to each other and #include "parrot/parrot.h".
For example, the extant worrisome case is darwin.c, which used to say:
#include <time.h>
#include <sys/time.h>
#undef environ
#undef bool
#import <mach-o/dyld.h>
#include "parrot/parrot.h"
...
Now it has become:
#include "parrot/parrot.h"
/* in darwin/begin.c */
#undef environ
#undef bool
/* pieces of generic/ */
/* in darwin/dl.c */
#import <mach-o/dyld.h>
...
#include <time.h>
#include <sys/time.h>
Moving the undefs quite possibly could change their effect. If the only intent is for them to be before dyld.h, no problem. OTOH, perhaps they should be before parrot.h as well, which Jonathan's patch will accomplish. (Or maybe dyld.h needs to be before parrot.h, which would require splitting it out of dl.c, yuck.) There doesn't appear to be a tinderbox with this configuration ATM. Can anyone test this?
Adam
Leopold Toetsch
> I've attached a patch which causes stuff in begin.c to be put before the
> #include "parrot/parrot.h" line, which fixes up this problem. I don't know
> if it's the right thing to do, but it's the best one I could think of.
Applied.
> Please create the empty signal.h too
Done.
> ... - BTW, how should I have gone about
> including that in my patch (e.g. what's the flag for cvs diff)?
$ diff -u /dev/null the_file # could be NUL: on Win32
Or touch(1) the file in the unmodified tree, i.e. create an empty one.
> Thanks,
> Jonathan
Thanks to you,
leo
Jonathan Worthington
From: "Leopold Toetsch" <l...@toetsch.at>
To: "Jonathan Worthington" <jona...@jwcs.net>
Cc: <perl6-i...@perl.org>
Sent: Saturday, February 21, 2004 11:51 AM
Subject: Re: [PATCH] Re: [perl #25239] Platform-specific files not granular
enough
D'oh. I forgot I'd had to create an empty signal.c to fix things up on
Win32 (signal.h alone wasn't enough). I've attached a patch to add it.
Sorry 'bout that,
Jonathan