911710 - unix.c fails to build with older GLIBC because of absence of CLOCK_MONOTONIC

Status: RESOLVED WONTFIX

(NSPR :: NSPR, defect, P3)

Description

[Ashwani Kadian]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20100101 Firefox/17.0 (Beta/Release)
Build ID: 20130805152501

Steps to reproduce:

Build NSPR 4.9.5 on RHEL 2 having GLIBC 2.2.4


Actual results:

Compilation of file "unix.c" failed with following error :

gcc -o unix.o -c      -Wall -pthread -O2 -fPIC  -UDEBUG  -DNDEBUG=1 -DXP_UNIX=1 -D_GNU_SOURCE=1 -DHAVE_FCNTL_FILE_LOCKING=1 -DLINUX=1 -Di386=1 -DHAVE_LCHOWN=1 -DHAVE_STRERROR=1 -DHAVE_DLADDR=1 -D_REENTRANT=1  -DFORCE_PR_LOG -D_PR_PTHREADS -UHAVE_CVAR_BUILT_ON_SEM -D_NSPR_BUILD_ -I/share/builds/mccrel3/security/securitytip/builds/20130820.1/wozzeck_Solaris8/mozilla/security/nss/../../dist/Linux2.4_x86_glibc_PTH_OPT.OBJ/include -I../../../../../pr/include -I../../../../../pr/include/private  ../../../../../pr/src/md/unix/unix.c
../../../../../pr/src/md/unix/unix.c: In function `_PR_UNIX_GetInterval2':
../../../../../pr/src/md/unix/unix.c:3045: `CLOCK_MONOTONIC' undeclared (first use in this function)
../../../../../pr/src/md/unix/unix.c:3045: (Each undeclared identifier is reported only once
../../../../../pr/src/md/unix/unix.c:3045: for each function it appears in.)


Expected results:

Compilation should have gone fine.

Comment 1

[Ashwani Kadian]

As a part of Bug 757593, "clock_gettime" is made to use "CLOCK_MONOTONIC" as a system clock type. But on RHEL 2 with GLIBC 2.2.4, clock type "CLOCK_MONOTONIC" is not available, hence compilation of "unix.c" fails with an undeclared identifier to "CLOCK_MONOTONIC". 
As a part of local patch (attached), we are defining it conditionally in "_linux.h". I think, the clock type has to be checked for its availability on system and used in "clock_gettime" only after confirming its availability.

Comment 2

[Ashwani Kadian]

Attachment: Patch

Comment 3

[Wan-Teh Chang]

Comment on attachment 798439 [details] [diff] [review]
Patch

Ashwani: thank you for the patch.

RHEL 2 is very old. I think NSPR no longer supports RHEL 2.
According to this page, RHEL 2 doesn't seem to be supported by
Red Hat either:
https://access.redhat.com/support/policy/updates/errata/

This patch is correct, but I may ask you to maintain this patch
as a private patch.

Comment 4

[Julien Pierre]

Wan-Teh,

Do you know of any other technical reason why NSPR would not work on RHEL 2, even if it's not supported ?
We still have some products that are supported on RHEL2, even if the OS is not supported by the vendor.

Comment 5

[Ashwani Kadian]

Hi Wan-Teh,

There are some problems with CLOCK_MONOTONIC on RHEL3 also. Clock type "CLOCK_MONOTONIC" is defined in header files but while passing it to "clock_gettime", comes up with an error code 22. It works fine on RHEL4 onwards.
    if (clock_gettime(CLOCK_MONOTONIC, &ts) != 0) {
        printf("clock_gettime with CLOCK_MONOTONIC failed: %d\n", errno);
    }
    else {
        printf("clock_gettime with CLOCK_MONOTONIC succeeded\n");
    }

Output : clock_gettime with CLOCK_MONOTONIC failed: 22

So this clearly tells us that we can not use CLOCK_MONOTONIC on RHEL3 also and will have to take up the changes proposed earlier.
RHEL3 is in support by Red Hat till January 30, 2014. So will it be possible for you to checkin the proposed changes?

Comment 6

[Ashwani Kadian]

But the proposed patch will not work on RHEL3 as the identifier CLOCK_MONOTONIC is defined on RHEL3 (but can not be used), which will in turn define HAVE_CLOCK_MONOTONIC causing the same problem.
I can not think of any way right now to decide availability of CLOCK_MONOTONIC (on RHEL3) other than to check the return code of "clock_gettime" in source code with this CLOCK_MONOTONIC argument.

Comment 7

[Julien Pierre]

I don't think we want to check this error for every call and then try again without CLOCK_MONOTONIC if it fails. We would probably need to test if CLOCK_MONOTONIC works during NSPR initialization and then remember that result.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Let's close it as we haven't seen any activity for years... and I don't think it is a big deal.