Opened 3 years ago

Closed 3 years ago

#7519 closed bug (fixed)

CLK_TCK is not always a constant

Reported by: singpolyma Owned by:
Priority: normal Milestone: 7.8.1
Component: libraries/base Version: 7.7
Keywords: qnx Cc: pho@…
Operating System: Other Architecture: Unknown/Multiple
Type of failure: Building GHC failed Test Case:
Blocked By: Blocking:
Related Tickets: Differential Revisions:

Description

System/CPUTime.hsc assumes that if CLK_TCK is defined, it is a constant, but on QNX it expands to a procedure call. The attached patch is one way to solve this problem.

http://www.haskell.org/pipermail/cvs-ghc/2012-December/079075.html http://www.haskell.org/pipermail/cvs-ghc/2012-December/079079.html

Attachments (1)

0001-Move-CLK_TCK-check-out-to-a-C-file.patch (2.4 KB) - added by singpolyma 3 years ago.

Download all attachments as: .zip

Change History (12)

Changed 3 years ago by singpolyma

comment:1 Changed 3 years ago by singpolyma

  • Status changed from new to patch

comment:2 Changed 3 years ago by igloo

  • difficulty set to Unknown

Does it expand to sysconf(_SC_CLK_TCK)?

If sysconf and _SC_CLK_TCK are portable enough, then we may as well just unconditionally use that.

comment:3 Changed 3 years ago by singpolyma

That is what it expands to on QNX, yes.

Well, it actually expands to _sysconf(_SC_CLK_TCK) which is an internal QNX wrapper, but the result is the same.

comment:5 Changed 3 years ago by kgardas

Looks like QNX and Solaris do exactly the same thing!

comment:6 Changed 3 years ago by PHO

  • Cc pho@… added

NetBSD does that too. In /usr/include/time.h:

/*
 * CLK_TCK uses libc's internal __sysconf() to retrieve the machine's
 * HZ. The value of _SC_CLK_TCK is 39 -- we hard code it so we do not
 * need to include unistd.h
 */
long __sysconf(int);
#define CLK_TCK         (__sysconf(39))

comment:7 Changed 3 years ago by singpolyma

  • Status changed from patch to merge

comment:8 Changed 3 years ago by simonmar

  • Milestone set to 7.8.1

The ticket state "merge" means you want the change in the stable branch (7.6). Will it help to merge it into the 7.6 branch?

comment:9 Changed 3 years ago by singpolyma

@simonmar oh. What's the state for "is in HEAD now"? Should it just be marked as "fixed"?

This patch *might* be useful to people on 7.6 (if they are building native compiles for Solaris, for example), but since most people seem to have run into this while cross-compiling, and 7.6 cannot cross-compile, that's probably not what I meant.

comment:10 Changed 3 years ago by kgardas

Hi, as a Solaris user I'd like to add that the patch is not needed for Solaris native compiles. i.e. i386. 7.6.x compiles and runs fine on Solaris. The patch is needed for cross-compiling i386-solaris -> x86_64-solaris. The problem is that hsc2hs is kind of more strict while cross-compiling than while doing native compiles -- that's why the code even before patch run fine and I just fail on it once attempting cross-compiling to x86_64-solaris. So, message is clear, if 7.6.x does not support cross-compilation, I wouldn't bother with merging the patch into 7.6.x branch.

comment:11 Changed 3 years ago by simonmar

  • Resolution set to fixed
  • Status changed from merge to closed
Note: See TracTickets for help on using tickets.