[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: GNU M4 1.4.8b released (beta release)

From: Eric Blake
Subject: Re: GNU M4 1.4.8b released (beta release)
Date: Thu, 08 Mar 2007 06:45:19 -0700
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070221 Thunderbird/ Mnenhy/

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             address@hidden
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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]