Closed Bug 4761 Opened 26 years ago Closed 26 years ago

_PR_HAVE_OFF64_T not defined for Solaris 5.7

Categories

(NSPR :: NSPR, defect, P3)

Sun
Solaris

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: vdemarco, Assigned: wtc)

Details

Attachments

(1 obsolete file)

When compiling mozilla on Solaris _PR_HAVE_OFF64_T needs to get defined in nspr/include/md/_solaris.h environment SunOS whatever 5.7 Generic sun4u sparc SUNW,Ultra-1 egcs-2.91.60 In the file mozilla/nsprpub/config/Solaris5.mk, the check for the OS doesn't seem correct, it completely ignores 5.7 This doesn't seem to work. ifeq (5.5,$(findstring 5.5,$(OS_RELEASE))) OS_DEFINES += -DSOLARIS2_5 else ifeq (,$(filter-out 5.3 5.4,$(OS_RELEASE))) OS_DEFINES += -D_PR_NO_LARGE_FILES else OS_DEFINES += -D_PR_HAVE_OFF64_T endif endif
Status: NEW → ASSIGNED
Accepted the bug and added cc list.
When you cd into mozilla/nsprpub and say 'gmake', do you see -D_PR_HAVE_OFF64_T on the command line? You should see -D_PR_HAVE_OFF64_T on the command line, otherwise something is seriously wrong with gmake. I suspect that the problem is not _PR_HAVE_OFF64_T but _LARGEFILE64_SOURCE. Can you apply this patch to mozilla/nsprpub/config/SunOS5.mk and give it a try? ******* begin patch ******* Index: SunOS5.mk =================================================================== RCS file: /cvsroot/mozilla/nsprpub/config/SunOS5.mk,v retrieving revision 3.9 diff -c -r3.9 SunOS5.mk *** SunOS5.mk 1998/11/23 06:32:32 3.9 --- SunOS5.mk 1999/04/08 20:08:07 *************** *** 106,111 **** --- 106,114 ---- OS_DEFINES += -D_PR_NO_LARGE_FILES else OS_DEFINES += -D_PR_HAVE_OFF64_T + ifdef NS_USE_GCC + OS_DEFINES += -D_LARGEFILE64_SOURCE + endif endif endif ******* end patch *******
Attached patch Applied this patch and build worked (obsolete) (deleted) — Splinter Review
Sorry take that back, its still broken here is the error. c++ -o nsJVMManager.o -c -fno-rtti -fno-exceptions -include ../../../config-defs.h -g -fPIC -DDEBUG -UNDEBUG -DDEBUG_vdemarco -DTRACING -DOSTYPE=\"SunOS5\" -DCookieManagement -DOJI -DUNIX_SKIP_ASSERTS -I../../../dist/./include -I../../../dist/include -I/export/home/vdemarco/netscape_src/mozilla/include -I/export/home/vdemarco/netscape_src/obj-sparc-sun-solaris2.7/nspr/include -I../../../dist/./public/jpeg -I../../../dist/./public/png -I../../../dist/./public/zlib -I/export/home/vdemarco/netscape_src/obj-sparc-sun-solaris2.7/nspr/include/private -I/usr/openwin/include /export/home/vdemarco/netscape_src/mozilla/modules/oji/src/nsJVMManager.cpp In file included from /export/home/vdemarco/netscape_src/obj-sparc-sun-solaris2.7/nspr/include/md/_unixos.h:147, from /export/home/vdemarco/netscape_src/obj-sparc-sun-solaris2.7/nspr/include/md/prosdep.h:121, from /export/home/vdemarco/netscape_src/obj-sparc-sun-solaris2.7/nspr/include/private/primpl.h:59, from /export/home/vdemarco/netscape_src/mozilla/modules/oji/src/nsJVMManager.cpp:28: /usr/include/sys/mman.h:80: warning: `PRIVATE' redefined /export/home/vdemarco/netscape_src/mozilla/include/xp_core.h:246: warning: this is the location of the previous definition In file included from /export/home/vdemarco/netscape_src/obj-sparc-sun-solaris2.7/nspr/include/md/prosdep.h:121, from /export/home/vdemarco/netscape_src/obj-sparc-sun-solaris2.7/nspr/include/private/primpl.h:59, from /export/home/vdemarco/netscape_src/mozilla/modules/oji/src/nsJVMManager.cpp:28: /export/home/vdemarco/netscape_src/obj-sparc-sun-solaris2.7/nspr/include/md/_unixos.h:566: #error "I don't know yet" gmake[3]: *** [nsJVMManager.o] Error 1 gmake[3]: Leaving directory `/export/home/vdemarco/netscape_src/mozilla/obj-sparc-sun-solaris2.7/modules/oji/src' gmake[2]: *** [libs] Error 2 gmake[2]: Leaving directory `/export/home/vdemarco/netscape_src/mozilla/obj-sparc-sun-solaris2.7/modules/oji' gmake[1]: *** [libs] Error 2 gmake[1]: Leaving directory `/export/home/vdemarco/netscape_src/mozilla/obj-sparc-sun-solaris2.7'
There are two problems: - The first problem is that gcc/egcs cannot compile mozilla/nsprpub on Solaris 2.6 and 7 unless we explicitly define _LARGEFILE64_SOURCE. We shouldn't need to do that, according to the lfcompile64(5) man page on Solaris 2.6: For applications that do not wish to conform to the POSIX or X/Open specifications, the 64-bit transitional interfaces are available by default. No compile-time flags need to be set. (Note: Conforming to the POSIX or X/Open specs means you use only the functions in those APIs.) I consider this a bug in gcc/egcs because it does not behave as required by the lfcompile64(5) man page. The patch I gave to you earlier works around this gcc/egcs bug. Can you verify that mozilla/nsprpub won't build without the patch? - nsJVMManager.cpp should not include the private NSPR header primpl.h. I have created bug #4839 for this bug, so this bug report should only track the first bug.
I just tried a local installation of egcs-2.91.60 and I can compile nsprpub with it just fine. Can you try this? - Remove (undo) the patch for mozilla/nsprpub/config/SunOS5.mk. - cd mozilla/nsprpub - gmake clean export See if you can compile nsprpub with no modifications to SunOS5.mk. Please let me know. Thanks.
NSPR now has its own Bugzilla product. Moving this bug to the NSPR product.
Assignee: srinivas → wtc
Status: ASSIGNED → NEW
Chris McAfee also reported this problem in the newsgroup, so added mcafee and ramiro to the cc list. Reassigned the bug to me. Ramiro, where are your gcc installations?
I have gcc-2.7.2.3 installed on mocha in /usr/local/gcc-2.7.2.3, there's build space in /export2.
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
I checked in a fix to define _LARGEFILE64_SOURCE if we are on Solaris 2.6 or 2.7 and using gcc: /cvsroot/mozilla/nsprpub/config/SunOS5.mk, revision 3.11. Apparently, this problem has been fixed in egcs and possibly gcc 2.8.x, so this fix isn't really necessary for egcs (and perhaps gcc 2.8.x), but it should be harmless. The fix is also checked into the internal CVS repository: /m/src/ns/nspr20/config/SunOS5.mk, revision 2.15. Chris, can you please verify? Thanks.
Status: RESOLVED → VERIFIED
Yes, this seems to be working now. Thanks Wan-Teh. Marking verified.
Attachment #1 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: