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: > 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]
-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 , > > 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]
-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 . > > 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]
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 . 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]
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 , 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]
-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 . > > 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 , 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]
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 . 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 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 . - -- 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]
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]
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]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: > 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. My Linux man page claims that all the functions in there, _except_ siggetmask, are from BSD, and that siggetmask is of unclear origin. >> At least sigblock(0) is more portable, > > What makes you say that? Because that one _is_ a BSD-ism. >> 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. Not when we can use a more portabile facility to make both systems happy. "Doesn't have siggetmask() nor sigsetjmp()" != "wildly different alarm/signal facilities". >> 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. Steven's been testing on that as a stepping-stone to VMS, as it's the most similar Unix to VMS. He has also run some tests on Solaris, more recently. Sorry if there was some confusion; one of the earlier threads was entitled "VMS and Wget", because the message that spawned it was me prodding him to get his VMS kit up-to-date for inclusion. :) - -- 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 iD8DBQFHIjLb7M8hyUobTrERCDmmAJ9NccwcxdkJ73xrq465SH+GT4LfrwCeJ/sd Z9hotYNSvKVzdQVFLTM73gY= =qh10 -END PGP SIGNATURE-
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]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hrvoje Niksic wrote: > Micah Cowan <[EMAIL PROTECTED]> writes: > >>>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 do prefer the POSIX way, which is to use sigsetjmp/siglongjmp, in > which case we need no explicit unblocking of signals. It is only on > non-POSIX systems without sigsetjmp that we use siggetmask. > > Non-Unix systems, such as VMS, should be handled like Windows are > currently handled: by providing their own native implementation of > highly non-portable routines such as run_with_timeout. That's the > whole point of having an abstract run_with_timeout function. 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. AFAIK, _no_ system supports POSIX 100%, so just because it lacks one POSIX facility doesn't mean we should assume we don't have another. Much better is to use something with a bit of a better guarantee, or at least not just leap to an assumption like that. At least sigblock(0) is more portable, but we shouldn't assume we have that either. And saying that VMS should implement its own completely separate run_with_timeout just because it lacks an unportable facility doesn't make sense--esides which, we're talking about a Unix here (Tru64), not VMS (yet). - -- 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 iD8DBQFHIiWq7M8hyUobTrERCIjNAJ99DOhtgnur4YlUdoY3T4Tui9yxEwCfeH1g BQmOzgE42CnZCtRNV2lBM+c= =USw1 -END PGP SIGNATURE-
Re: More portability stuff [Re: gettext configuration]
Micah Cowan <[EMAIL PROTECTED]> writes: > 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. I think you're misunderstanding the logic of run_with_timeout. It doesn't use non-POSIX code unless it has to (explanation in the other mail in this thread). It could be improved to support moer non-POSIX systems, but POSIX systems should run it as currently written.
Re: More portability stuff [Re: gettext configuration]
Micah Cowan <[EMAIL PROTECTED]> writes: >>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 do prefer the POSIX way, which is to use sigsetjmp/siglongjmp, in which case we need no explicit unblocking of signals. It is only on non-POSIX systems without sigsetjmp that we use siggetmask. Non-Unix systems, such as VMS, should be handled like Windows are currently handled: by providing their own native implementation of highly non-portable routines such as run_with_timeout. That's the whole point of having an abstract run_with_timeout function.
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.
More portability stuff [Re: gettext configuration]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 List cc'd Steven M. Schweda wrote: >M: > >Next problem on Tru64: > > cc -g -o wget cmpt.o connect.o convert.o cookies.o ftp.o ftp-basic.o > ftp-ls.o > hash.o host.o html-parse.o html-url.o http.o init.o log.o main.o netrc.o > progre > ss.o ptimer.o recur.o res.o retr.o snprintf.o spider.o url.o utils.o > xmalloc.o v > ersion.o ftp-opie.o openssl.o http-ntlm.o gen-md5.o ../lib/libgnu.a -lrt > -lssl > -lcrypto /usr/local/lib/libintl.so -liconv -lc -rpath /usr/local/lib > 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. >And speaking of Solaris: > > sol# autoreconf --version > autoreconf (GNU Autoconf) 2.61 > > sol# automake --version > automake (GNU automake) 1.10 > > sol# m4 --version > m4 (GNU M4) 1.4.10 > > sol# cp -p maint.mk maint.mk_orig > sol# cp -p ../maint.mk . > > sol# cp -p lib/stdbool.in.h lib/stdbool.in.h_orig > sol# cp -p ../stdbool.in.h lib > > sol# autoreconf > /usr/local/share/aclocal/pkg.m4:5: warning: underquoted definition of > PKG_CHECK_ > MODULES > /usr/local/share/aclocal/pkg.m4:5: run info '(automake)Extending aclocal' > /usr/local/share/aclocal/pkg.m4:5: or see > http://sources.redhat.com/automake/a > utomake.html#Extending-aclocal That one's an indication of a bug in pkg-config, I think; at any rate it's in your installation and not related to Wget. > sol# CC=cc ./configure > sol# gmake > [...] > source='main.c' object='main.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/bash ../depcomp \ > cc -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\" > -DLOCALEDIR=\"/usr/ > local/share/locale\" -I. -I../lib -g -c main.c > "main.c", line 719: warning: argument #2 is incompatible with prototype: > prototype: pointer to pointer to char : "../lib/getopt.h", line 208 > argument : pointer to const pointer to char > [...] I believe I noticed that one when I was looking at it before. It violates the C standard, but is generally likely to work, though apt to produce warnings on some environments. I'll get to that. > source='gen-md5.c' object='gen-md5.o' libtool=no \ > DEPDIR=.deps depmode=none /bin/bash ../depcomp \ > cc -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\"/usr/local/etc/wgetrc\" > -DLOCALEDIR=\"/usr/ > local/share/locale\" -I. -I../lib -g -c gen-md5.c > "gen-md5.c", line 42: warning: no explicit type given > "gen-md5.c", line 42: syntax error before or at: gen_md5_context_imp > "gen-md5.c", line 42: warning: old-style declaration or incorrect type for: > gen_ > md5_context_imp > [... lots of consequences ...] > >I'm guessing that this is the result of using ./lib/md5.h instead of > /usr/include/md5.h (or some other md5.h), but I haven't tested that yet. > This part of config.log looks interesting, though: > > configure:17259: checking for working md5.h > configure:17271: cc -c -g conftest.c >&5 > configure:17277: $? = 0 > configure:17283: result: yes > configure:17292: using the Solaris MD5 implementation > >That _test_ will be getting /usr/include/md5.h, but with "-I. > -I../lib", the real thing will be finding ../lib/md5.h before it gets to > /usr/include/md5.h, and they don't look to be compatible (around here). > I see lib/md5.h in the source kit, so it doesn't look generated to me, > and it's not safe to leave lying around for the children to see. Right. I'll probably have to separate md5 from the rest of the gnulib kit, then, since we do special things in checking whether we want it or not. If we have a md5/ directory, we can just decide to compile/include it or not (and still reap the benefits of easily syncing with changes to the original version). - -- 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 iD8DBQFHHmy47M8hyUobTrERCK8LAJ43Z+6drad/TnB+OrKEmPbe6FPK2ACfbYHC CmS5qk8CpSN7EJWtzSo7lWk= =WYdH -END PGP SIGNATURE-
