-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Eric Blake on 3/5/2007 7:15 AM: > According to Matthew Woehlke on 3/2/2007 9:33 AM: >>> Another option would be to leave int64_t defined as it is, but set >>> HAVE_INT64_T >>> to 0, to indicate that gnulib shouldn't use it. >> Hmm... this looks like it would fix sys/stat.h (see below). I'm still >> not sure I trust it. Will clock_t and fpos_t be defined correctly so as >> to not break system API's using these? Will gnulib behave correctly >> w.r.t. these? > > We don't have access to your system, so you will have to try various > experiments. One thing that would be helpful is for you to determine how > packages will behave as though the .m4 files were fixed to already > recognize that gnulib's assumptions about long long are broken, and > therefore, from gnulib's point of view, a working long long does not exist > (leaving actual system headers to use long long to their hearts content, > unmolested by gnulib's replacement stdint.h).
I'd really like some feedback on this thread. It is the only issue holding up a release of M4 1.4.9. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF8BNv84KuGfSFAYARAmgPAJ4+jog4UCUU6Kp/mjQS6zRmCijILQCfXtO8 cbyb95CvsNEpuo8FnEsTjn0= =ckRs -----END PGP SIGNATURE----- _______________________________________________ M4-discuss mailing list M4-discuss@gnu.org http://lists.gnu.org/mailman/listinfo/m4-discuss
