Re: More portability stuff [Re: gettext configuration]
On 10/29/07, Dražen Kačar [EMAIL PROTECTED] wrote: Micah Cowan wrote: AFAIK, _no_ system supports POSIX 100%, AIX and Solaris have certified POSIX support. That's for the latest, IEEE Std 1003.1-2001. More systems have certified POSIX support for the older POSIX release. OTOH, all POSIX releases have optional parts which don't have to be implemented. Yeah, to be POSIX-compliant you just had to document which parts you didn't implement (comply with). T
Re: More portability stuff [Re: gettext configuration]
Micah Cowan wrote: AFAIK, _no_ system supports POSIX 100%, AIX and Solaris have certified POSIX support. That's for the latest, IEEE Std 1003.1-2001. More systems have certified POSIX support for the older POSIX release. OTOH, all POSIX releases have optional parts which don't have to be implemented. -- .-. .-.Yes, I am an agent of Satan, but my duties are largely (_ \ / _) ceremonial. | |[EMAIL PROTECTED]
Re: More portability stuff [Re: gettext configuration]
Micah Cowan [EMAIL PROTECTED] writes: Or getting the definition requires defining a magic preprocessor symbol such as _XOPEN_SOURCE. The man page I found claims that the function is defined by XPG4 and links to standards(5), which explicitly documents _XOPEN_SOURCE. Right. But we set that unconditionally in sysdep.h, Only if you made it so. The config-post.h code only set it on systems where that's known to be safe, currently Linux and Solaris. (The reason was that some systems, possibly even Tru64, failed to compile with _XOPEN_SOURCE set.) Also note that Autoconf tests don't include sysdep.h, so the test could still be failing. It would be worth investigating why curl's Autoconf test passes and ours (probably) doesn't.
Re: More portability stuff [Re: gettext configuration]
On Fri, 26 Oct 2007, Micah Cowan wrote: I very much doubt it does, since we check for it in the curl configure script, and I can see the output from it running on Tru64 clearly state: checking for sigsetjmp... yes Note that curl provides the additional check for a macro version in the configure script, rather than in the source; we should probably do it that way as well. I'm not sure how that helps for this, though: if the above test is failing, then either it's a function (no macro) and configure isn't picking it up; or else it's not defined in setjmp.h. Yes right, I had forgot about that! But in the Tru64 case the extra macro check isn't necessary. I don't remember exactly what system that needs it, but I believe it was some older linux or bsd.
Re: More portability stuff [Re: gettext configuration]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel Stenberg wrote: On Fri, 26 Oct 2007, Micah Cowan wrote: I very much doubt it does, since we check for it in the curl configure script, and I can see the output from it running on Tru64 clearly state: checking for sigsetjmp... yes Note that curl provides the additional check for a macro version in the configure script, rather than in the source; we should probably do it that way as well. I'm not sure how that helps for this, though: if the above test is failing, then either it's a function (no macro) and configure isn't picking it up; or else it's not defined in setjmp.h. Yes right, I had forgot about that! But in the Tru64 case the extra macro check isn't necessary. I don't remember exactly what system that needs it, but I believe it was some older linux or bsd. My Ubuntu 7.04 system appears to need it. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHI4T+7M8hyUobTrERCC2zAJwMcwwmTPVmJmktWZHcAsaz9cYNpgCfd5uT 3gYhllL7gghU7WevsA1Yn0I= =fgDQ -END PGP SIGNATURE-
Re: More portability stuff [Re: gettext configuration]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: Or getting the definition requires defining a magic preprocessor symbol such as _XOPEN_SOURCE. The man page I found claims that the function is defined by XPG4 and links to standards(5), which explicitly documents _XOPEN_SOURCE. Right. But we set that unconditionally in sysdep.h, Only if you made it so. The config-post.h code only set it on systems where that's known to be safe, currently Linux and Solaris. (The reason was that some systems, possibly even Tru64, failed to compile with _XOPEN_SOURCE set.) You're right, of course. It's not unconditional. I can't even begin to fathom why some system would fail to compile in such an event: _XOPEN_SOURCE is a feature request, not a guarantee that you'll get some level of POSIX. Do you happen to remember the system? I'd rather always define it, except for the systems where we know it fails, rather than just define it where it's safe. Also note that Autoconf tests don't include sysdep.h, so the test could still be failing. It would be worth investigating why curl's Autoconf test passes and ours (probably) doesn't. I thought the Autoconf tests were testing merely for the function's linkability... but yeah, maybe adding setjmp.h to the checked headers will mean it's included for the function tests, or something. I'll play around. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHI4WW7M8hyUobTrERCGydAJ9AkzxbwkdvLKrmr1YZNpf+TB2JNACdEFIs j7b6sERHjEJzRyj4WnydKcM= =LUG6 -END PGP SIGNATURE-
Re: More portability stuff [Re: gettext configuration]
Micah Cowan [EMAIL PROTECTED] writes: I can't even begin to fathom why some system would fail to compile in such an event: _XOPEN_SOURCE is a feature request, not a guarantee that you'll get some level of POSIX. Yes, but sometimes the system headers are buggy. Or sometimes they work just fine with the system compiler, but not so well with GCC. I don't know which was the case at the time, but I remember that compilation failed with _XOPEN_SOURCE and worked without it. Do you happen to remember the system? If I remember correctly, the system was a (by current standards) old version of Tru64. The irony. :-) I'd rather always define it, except for the systems where we know it fails, rather than just define it where it's safe. I agree that that would be a better default now that many other programs unconditionally define _XOPEN_SOURCE. At the time I only defined _XOPEN_SOURCE to get rid of compilation warnings under Linux and Solaris. After encountering the errors mentioned above, it seemed safer to only define it where doing so was known not to cause problems.
Re: More portability stuff [Re: gettext configuration]
Micah Cowan [EMAIL PROTECTED] writes: Okay... but I don't see the logic of: 1. If the system has POSIX's sigsetjmp, use that. 2. Otherwise, just assume it has the completely unportable, and not even BSDish, siggetmask. Are you sure siggetmask isn't BSD-ish? When I tested that code on various Unix systems, the only one without sigsetjmp was Ultrix, and it had siggetmask. Linux man page claims siggetmask to belong to the BSD signal API and the headers expose it when _BSD_SOURCE is defined. AFAIK, _no_ system supports POSIX 100%, In case it's not obvious, I was trying to make the code portable to real Unix and Unix-like systems. So, the logic you don't see happened to cover both POSIX and all non-POSIX systems I laid my hands on, or heard of. Wget was ported to *very* strange systems, and I don't remember problems with run_with_timeout. At least sigblock(0) is more portable, What makes you say that? And saying that VMS should implement its own completely separate run_with_timeout just I know nothing of VMS. If it's sufficiently different from Unix that it has wildly different alarm/signal facilities, or no alarm/signal at all (as is the case with Windows), then it certainly makes sense for Wget to provide a VMS-specific run_with_timeout and use it on VMS. Exactly as it's now done with Windows. because it lacks an unportable facility doesn't make sense--esides which, we're talking about a Unix here (Tru64), not VMS (yet). Do you say that Tru64 lacks both sigsetjmp and siggetmask? Are you sure about that?
Re: More portability stuff [Re: gettext configuration]
On Sat, 27 Oct 2007, Hrvoje Niksic wrote: Do you say that Tru64 lacks both sigsetjmp and siggetmask? Are you sure about that? That is the only system we are currently talking about. I find it hard to believe that Tru64 lacks both of those functions; for example, see http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/MAN/MAN3/0707.HTM It is quite possible that the Autoconf test for sigsetjmp yields a false negative. I very much doubt it does, since we check for it in the curl configure script, and I can see the output from it running on Tru64 clearly state: checking for sigsetjmp... yes (available here for another ten days or so: http://curl.haxx.se/auto/log.cgi?id=20071026080956-25212)
Re: More portability stuff [Re: gettext configuration]
Micah Cowan [EMAIL PROTECTED] writes: I know nothing of VMS. If it's sufficiently different from Unix that it has wildly different alarm/signal facilities, or no alarm/signal at all (as is the case with Windows), then it certainly makes sense for Wget to provide a VMS-specific run_with_timeout and use it on VMS. Exactly as it's now done with Windows. Not when we can use a more portabile facility to make both systems happy. That's why I said *if* it's sufficiently different from Unix It obviously isn't if it only differs in the way that signal masks need to be restored after longjmping from a signal handler. Doesn't have siggetmask() nor sigsetjmp() != wildly different alarm/signal facilities. Of course. I simply wasn't aware of such a case when I was writing the code. I'm not claiming the current code is perfect, I'm just trying to explain the logic behind it. because it lacks an unportable facility doesn't make sense--esides which, we're talking about a Unix here (Tru64), not VMS (yet). Do you say that Tru64 lacks both sigsetjmp and siggetmask? Are you sure about that? That is the only system we are currently talking about. I find it hard to believe that Tru64 lacks both of those functions; for example, see http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/MAN/MAN3/0707.HTM It is quite possible that the Autoconf test for sigsetjmp yields a false negative.
Re: More portability stuff [Re: gettext configuration]
Daniel Stenberg [EMAIL PROTECTED] writes: It is quite possible that the Autoconf test for sigsetjmp yields a false negative. I very much doubt it does, since we check for it in the curl configure script, Note that I didn't mean in general. Such bugs can sometimes show in one program or test system, but not in another, depending on previously run tests (which influence headers included by test programs), version of Autoconf, or issues with the tester's installation. and I can see the output from it running on Tru64 clearly state: checking for sigsetjmp... yes It is my understanding that Steven got an error stating that siggetmask is nonexistent, and siggetmask is used only if not HAVE_SIGSETJMP. Since, according to your test, Tru64 indeed does have sigsetjmp, it only confirms my suspicion that Autoconf gets it wrong, at least for that particular combination of Wget and the tester's Tru64 installation.
Re: More portability stuff [Re: gettext configuration]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Daniel Stenberg wrote: On Sat, 27 Oct 2007, Hrvoje Niksic wrote: Do you say that Tru64 lacks both sigsetjmp and siggetmask? Are you sure about that? That is the only system we are currently talking about. I find it hard to believe that Tru64 lacks both of those functions; for example, see http://h30097.www3.hp.com/docs/base_doc/DOCUMENTATION/V51_HTML/MAN/MAN3/0707.HTM It is quite possible that the Autoconf test for sigsetjmp yields a false negative. I very much doubt it does, since we check for it in the curl configure script, and I can see the output from it running on Tru64 clearly state: checking for sigsetjmp... yes Thanks, Daniel. Looking at my own config.h (on GNU/Linux), I see: /* Define to 1 if you have the `sigsetjmp' function. */ /* #undef HAVE_SIGSETJMP */ In utils.c, I see this workaround: #ifndef HAVE_SIGSETJMP /* If sigsetjmp is a macro, configure won't pick it up. */ # ifdef sigsetjmp # define HAVE_SIGSETJMP # endif #endif (on my system, this results in HAVE_SIGSETJMP being set.) I'm not sure how Steven's environment managed not to get HAVE_SIGSETJMP set, then. Steven? Note that curl provides the additional check for a macro version in the configure script, rather than in the source; we should probably do it that way as well. I'm not sure how that helps for this, though: if the above test is failing, then either it's a function (no macro) and configure isn't picking it up; or else it's not defined in setjmp.h. - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHInCz7M8hyUobTrERCPY6AJ44mK6VQWo5qTSn68MvW0aDo4UH+wCdGtVT DTRKsYMeCl6iQ0zA/KghENg= =ym9j -END PGP SIGNATURE-
Re: More portability stuff [Re: gettext configuration]
Micah Cowan [EMAIL PROTECTED] writes: Note that curl provides the additional check for a macro version in the configure script, rather than in the source; we should probably do it that way as well. I'm not sure how that helps for this, though: if the above test is failing, then either it's a function (no macro) and configure isn't picking it up; or else it's not defined in setjmp.h. Or getting the definition requires defining a magic preprocessor symbol such as _XOPEN_SOURCE. The man page I found claims that the function is defined by XPG4 and links to standards(5), which explicitly documents _XOPEN_SOURCE.
Re: More portability stuff [Re: gettext configuration]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: Micah Cowan [EMAIL PROTECTED] writes: Note that curl provides the additional check for a macro version in the configure script, rather than in the source; we should probably do it that way as well. I'm not sure how that helps for this, though: if the above test is failing, then either it's a function (no macro) and configure isn't picking it up; or else it's not defined in setjmp.h. Or getting the definition requires defining a magic preprocessor symbol such as _XOPEN_SOURCE. The man page I found claims that the function is defined by XPG4 and links to standards(5), which explicitly documents _XOPEN_SOURCE. Right. But we set that unconditionally in sysdep.h, so that shouldn't be the problem... right? Of course, we'd probably do well to upgrade the value we're setting it to (to 600). - -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHIn677M8hyUobTrERCNg3AJ0XNyH673f9Rk8bwfu4AKmRdQDZ7wCfX0FE Fu7U0ZB4VkSMW7D8u4Z1ITI= =d6do -END PGP SIGNATURE-
Re: More portability stuff [Re: gettext configuration]
Steven M. Schweda wrote: From: Micah Cowan [EMAIL PROTECTED] Next problem on Tru64: [...] ld: Unresolved: siggetmask We ain't go no siggetmask(). None on VMS (out as far as V8.3), either, should I ever get so far. siggetmask is an obsolete BSDism; POSIX has the sigprocmask function, which we should prefer. We should also do feature-testing, and not assume there's a portable way to block/unblock signals. Note that sigprocmask() does appear on VMS, but apparently not until V8.2, which is ahead of many users (including me, in part). More portability would be better in this region. Can't sigsetmask() or sigblock() do the same job if you tell them not to change anything? Oh... I guess siggetmask() _isn't_ the BSDism, then; it's just lumped into the same manpage. It comes from elsewhere. My thought was that we'd use sigprocmask() where available, and fall back to the older BSD extension (which I had thought would remain siggetmask()), and then to nothing if neither are available. I guess we should substitute sigblock(0) for siggetmask(). I wasn't really expecting VMS to have sigprocmask(); but I expect future systems may conceivably have it and lack the BSD ones (and perhaps such systems are already in the wild). Anyway, we'll use what's available. -- Micah J. Cowan Programmer, musician, typesetting enthusiast, gamer... http://micah.cowan.name/ signature.asc Description: OpenPGP digital signature
Re: More portability stuff [Re: gettext configuration]
From: Micah Cowan [EMAIL PROTECTED] Next problem on Tru64: [...] ld: Unresolved: siggetmask We ain't go no siggetmask(). None on VMS (out as far as V8.3), either, should I ever get so far. siggetmask is an obsolete BSDism; POSIX has the sigprocmask function, which we should prefer. We should also do feature-testing, and not assume there's a portable way to block/unblock signals. Note that sigprocmask() does appear on VMS, but apparently not until V8.2, which is ahead of many users (including me, in part). More portability would be better in this region. Can't sigsetmask() or sigblock() do the same job if you tell them not to change anything? SMS.
