On Tue, Nov 11, 2014 at 7:21 AM, Andrew Gabriel < illu...@cucumber.demon.co.uk> wrote > > We currently support 32 bit and 64 bit kernel. A bug fix needs to work on > both 32 and 64 bit versions, so that would not be acceptable as a bug fix > for this issue (if it was something you were trying to fix in the distro). >
There isn't anything specific in the program in question that would definitively qualify as a "bug". The program operates correctly e.g. even when compiled as a 32-bit application on NetBSD: # file grap grap: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for NetBSD 6.1.5, not stripped # ./grap -d grap.defines test.grap | grep aligned line invis "2038-01-20T23:59:59" aligned from Frame.Bottom.end + (0, -0.4) to Frame.Bottom.start + (0, -0.4) There are two parts of the problem, neither of which is specific to application code: 1. 32-bit time_t provided by Solaris-derived kernel, run-time, and build system is inadequate (well-known, long-standing issue) 2. default build on Solaris-derived 64-bit systems is 32-bits. Even though the 64-bit version works as expected on OI, it isn't built as 64-bit without special effort; i.e. by default anything using time_t is broken, even on 64-bit OI. Other OSes (e.g. NetBSD as shown above) have solved issue #1. If issue #1 is solved on illumos, issue #2 becomes strictly a performance tweak. If there's a "bug" involved here, it is issue #1. Issue #2 means that without special Solaris-specific effort, applications using time_t or any library functions that directly or indirectly use time_t may exhibit anomalous behavior when built for Solaris or illumos, even on 64-bit systems. Applications which need to handle dates outside of the operating system > time (such as dates of births, deaths, marriages, retirements, etc) > shouldn't be using time_t -- that's very well established. You have an alternative? Note that every standard time-based function eventually involves time_t. That includes strftime() and strptime() as in the example, time(), clock_gettime(), all of the ctime functions (localtime(), gmtime(), etc.) , mktime(), difftime(), and so on. > Generally, 32 bit apps which are simply rebuilt as 64 bit (without being > modified to explicitly make use of larger address space) run faster on x86 > because of the extra registers available for compiler optimisation, and run > slower on sparc because of the larger working set size. > That sounds like a good reason (in addition to the time_t correctness issue) for making 64-bit builds the default, at least on 64-bit x86. _______________________________________________ openindiana-discuss mailing list openindiana-discuss@openindiana.org http://openindiana.org/mailman/listinfo/openindiana-discuss