Re: [Fink-users] Incorrect fribidi link path?

[Martin C. <cos...@wa...>]

On 9/09/13 16:24, Alexander Hansen wrote:
> On 9/9/13 3:51 AM, Martin Costabel wrote:
>> On 6/09/13 18:49, Alexander Hansen wrote:
>>> On 9/6/13 8:22 AM, Renaud Detry wrote:
[]
>>> Making all in doc
>>> make[2]: Warning: File `fribidi-bidi.h' has modification time 1.8e+19 s
>>> in the future
>>> Running c2man
>>> ../missing: line 52: c2man: command not found
[]
>>> It appears that the following item from the patch script isn't working,
>>> although it shows up in your build log:
>>>
>>>      # don't regenerate manpage (patch doesn't change its results
>>>      # and fink doesn't have the c2man tool)
>>>      touch -t 197001010000 lib/fribidi-bidi.h
>>
>> I get the same warning about modification time 2^64 seconds in the
>> future and missing c2man. This looks to me like a bug in make that
>> considers all dates before 01:00 on 1970-01-01 as a date in the future,
>> modulo 2^64 s. Note that this is one hour after the epoch.
[]
> I'm also on 10.8.4, but I don't see this issue.  Could it be
> filesystem-specific (case-insensitive here)?

The only explanation I can imagine for a different behavior in your case 
is that it might be timezone specific. Execetive summary: If you are 
east of Greenwich, you get an error, if you are west of it, you don't.

Detailed evidence:
According to the operating system, I am in UTC+1 (in reality it is UTC+2 
with summertime), and you are in some UTC-8 or so. Thus in my case,
  touch -t 197001010000 lib/fribidi-bidi.h
sets the modification time of the file to one hour before epoch. In your 
case, it sets it to epoch + 8 hours. Try

   date -r 0

It gives you the Unix epoch in timestamp format, in my case

Thu Jan  1 01:00:00 CET 1970

In your case you will probably see something like

Wen Dec  31 16:00:00 PST 1969

Another test is after the above touch command to read the mtime via 
`stat -s`

touch -t 197001010000 foo
stat -s foo

It gives me st_mtime=-3600, that is one hour before the epoch.
Thus in my case, but not in yours, st_mtime is negative.

And at that point the bug in make kicks in. I think I saw it in the 
sources of make. They cast the signed 32bit int st_mtime into an 
unsigned 64bit long long, which gives a date in the future, long after 
the end of the universe. Funny bug.

-- 
Martin