Regarding the last question, I just realized that it can't be so, since the CRT version would make a double compensation then.
Considering the statement that
* [...] The values are supposedly in system time
FileTimeToSystemTime() should never adjust the time on any OS.
I would like to see the usage of __loctotime_t removed. I seem to recall that usage beeing one of the major problems with the MinGW port of Pike. I don't know if Nilsson has solved this in a better way than I did, but I failed terrible.
The root of my problems was that MinGW didn't expose that function if I recall correctly. There were also some other things used in Pike that weren't exposed in MinGW. I think a lot of the win32 stuff could use a clean-up.
Personally, I'm in favour of dropping support for pre-Win95 or even pre-W98 if needed to get a good codebase. I don't think anyone is using pike under Win95 or 98 so it wouldn't really hurt. (If someone is, they are probably running 7.4 anyway, so...)
Doesn't MinGW provide its own CRT? In that case it's probably more accurate to assume that it does not _have_ a __loctotime_t function at all, rather than just not expose it. Which seems like a good reason not to use that function anyway.
True. That is a more acurate description of the situation. However, when I noticed the problem, I did some research on the __loctotime_t function and if I recall correctly, had great difficulties finding out how it worked, so I couldn't contribute it to MinGW.
To be honest, I don't remember exactly which function that caused the greatest problem, there were a couple that MinGW didn't have. I just remember that __loctotime_t was one of them. Since Nilsson is in the middle of an effort to make Pike compile with MinGW, it might be a good time to ask the question I never got around to last time:
What does Pike use internally for time, ie what are times in Pike relative to?
Don't overemphasize me in this. I've spent most time on Nettle and other things.
Oh well, you are the one with the MinGW w32 buildtree at the moment... ;)
What is the status on your work btw? Have you done any fixes to make it compile and are the fixes in CVS?
A thought is to branch Pike so that you, me and perhaps some others can roam the code and fix things without having to worry about the other platforms right now.
It compiles fine up until interpret.c where gcc for some unresearched reason fails to parse the file correctly.
Why not create an MinGW-win32 branch and I'll have a look at it later today?
I've checked in all my changes in the main branch, I think.
Ok. Then I'll install MinGW tonight and see what happens...
To get Nettle to compile you have to rename __argc and __argv in tools/getopt.h to e.g. _argc and _argv. You'll also have to fix all the x86/*asm files so that global identifiers have one more underscore. E.g. in sha1-compress.asm, add one line .globl __nettle_sha1_compress and one line __nettle_sha1_compress: next to the existing similar lines.
Easiest is to compile without nettle of course.
Do you know why __ doesn't work or have you just found the workaround? Seems a bit strange if __symbol is illegal...
__symbol isn't illegal. __argc and __argv is. (Or rather, they are used for something I haven't bother researched)
Same thing in this case.. :)
Have you discussed this with Nisse and what was his response? Will he rename those symbols in Nettle or is he waiting for a patch from you?
__symbol is reserved for the compiler. The C standard does not allow you to use them for your own purposes.
Ah, there we go. That was new to me.
Then Nisse should rename the symbols in Nettle ASAP.
pike-devel@lists.lysator.liu.se
-
Marcus Agehall (PacketFront) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum