----- Original Message ----- From: "Mark Dootson" <mark.doot...@znix.com> To: "Sisyphus" <sisyph...@optusnet.com.au> Cc: "perl-win32-users" <perl-win32-users@listserv.ActiveState.com> Sent: Wednesday, March 14, 2012 1:14 AM Subject: Re: Why can't linker find CreateJobObjectA ?
> Hi, > > On 11/03/2012 23:52, Sisyphus wrote: > >> An afterthought or two: >> It's a bug, right ? (It smells like a bug to me.) >> Is it a bug in perl ? >> I'm thinking that CORE/win32.h should be assigning the value associated >> with the actual OS on which perl is running, rather than just assigning >> the minimum supported value. >> >> Cheers, >> Rob > > I'm not so sure. > Perl has to define the minimum it needs and it is really up to the coder > to define the minimum they need. I think what Perl does is reasonable. Yeah, I'm still not sure either :-) It just seems odd to me that it's up to the coder to know about this and take appropriate action - especially in this day and age, when things are supposed to just work. And, I still find myself thinking that the CORE/win32. h assertion that _WIN32_WINNT == 0x0400 is just an out-and-out lie (on this Vista box). It certainly misleads the mingw.org (gcc-4.5.2) compiler. > I think It would also be quite standard to put > > #define _WIN32_WINNT 0x0501 > > before any includes if you needed capability not included until XP. > If Perl on Windows Vista defined a minimum of 0x0600 (or whatever it is) > then anything compiled that linked to libperl would possibly not run on a > Windows XP machine which would cause much more unexpected grief I think. > > The way things are, failures are up front at compilation time. If the > person doing compilation needs an explicit win version, they are fully > aware of the limits they are introducing. Done as #define _WIN32_WINNT = > current platform would cause many more failures at end user time. On > Windows, end users very often just get binaries. Those are fair points, I think. Perhaps they demonstrate that either: a) Windows users should be compiling themselves, rather than relying on pre-built binaries; or b) suppliers of binaries should be providing separate binaries for the different Windows flavours; but I really don't want to be the one who pushes *either* of those alternatives :-) > For Inline::C you do of course want the opposite so I think your solution > on Windows is to either prepend #define _WIN32_WINNT 0x0NNN to the code > being compiled or pass a -D_WIN32_WINNT=0x0NNN to the compiler. Yes, it's actually the latter that's currently needed. The former still places the #define (too late) *after* the inclusion of perl.h - which is perhaps something that Inline::C ought to address. (I'm thinking Inline::C ought really provide some option that enables one to place C code *before* the inclusion of EXTERN.h, perl.h and XSUB.h in the generated XS file.) Thanks, Mark. I don't intend to pursue this "bug" any further - for now, at least. Cheers, Rob _______________________________________________ Perl-Win32-Users mailing list Perl-Win32-Users@listserv.ActiveState.com To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
