Bug 66159 - [PATCH] Fix ezm3 for 64-bit time_t on sparc64 5.x-current
Summary: [PATCH] Fix ezm3 for 64-bit time_t on sparc64 5.x-current
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Only Me
Assignee: John Polstra
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-05-02 04:10 UTC by Garance A Drosehn
Modified: 2004-05-16 18:45 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Garance A Drosehn 2004-05-02 04:10:21 UTC
	The freebsd/sparc64 platform recently switched to 64-bit time_t's.
	ezm3, as it stands, does not handle this.  This is bad for cvsup.
	Right now people using 64-bit time_t's are running a special
	ezm3 package that I have at http://people.freebsd.org/~gad :
		ezm3-64btt-1.1_1.tbz
	along with a special package of cvsup-without-gui as built by
	that version of ezm3, at:
		cvsup-without-gui-64btt-16.1h.tbz
	However, if they rebuild ezm3 from the present ports collection
	then they will run into problems with cvsup.

Fix: 

I have a patch at:

	http://people.freebsd.org/~gad/time-64/port-ezm3.diff

	which, if applied to the port, will fix exm3.  There is some
	debate as to whether this is the perfect fix, but it is at
	least a very workable and reliable way to solve the issue.

	One way or another, this issue with the ezm3 port should be
	addressed before we get to 5.3-release.
How-To-Repeat: 	This has been discussed on freebsd-sparc64 maling list.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2004-05-02 06:24:30 UTC
Responsible Changed
From-To: freebsd-ports-bugs->jdp

Over to maintainer.
Comment 2 marius 2004-05-16 17:03:49 UTC
The patch at http://people.freebsd.org/~gad/time-64/port-ezm3.diff
causes some problems as it makes the Makefile evaluate CHECKRESULT
every time it's run, even when WRKSRC doesn't exists. This causes
e.g. `make -V <something>` to break:
marius@nephilim:/tmp/co/ezm3 > make -V PGKNAME
/usr/bin/ld: cannot open output file /checktimet: Permission denied
"Makefile", line 63: warning: "/bin/rm -rf /checktimet &&  cc -o /checktimet /tmp/co/ezm3/files/checktimet.c &&  /checktimet" returned non-zero status

While the ezm3 port probably can be made to use checktimet.c without
causing problems it now should be sufficient to use OSVERSION to
decide whether the value of time_t should be changed to int64_t. The
reason for this is that FreeBSD/sparc64 fully switched to 64bit
time_t by default with __FreeBSD_version 502107; there should be
no more testing of the time_t change and going back and forth
between 32bit and 64bit time_t, just users that recompile their
ports after switching to a 64bit time_t FreeBSD/sparc64.
The author of the above mentioned patch basically agreed to this in:
http://lists.freebsd.org/pipermail/freebsd-sparc64/2004-March/001444.html
A patch which makes the ezm3 port change time_t on FreeBSD/sparc64
based on OSVERSION is below.

Index: Makefile
===================================================================
RCS file: /mnt/futile/usr/data/bsd/cvs/fbsd/ports/lang/ezm3/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- Makefile	4 Feb 2004 05:21:33 -0000	1.9
+++ Makefile	4 Mar 2004 18:42:30 -0000
@@ -26,6 +26,7 @@
 SCRIPTS_ENV+=	TARGET=${TARGET}
 USE_BZIP2=	yes
 USE_GMAKE=	yes
+USE_REINPLACE=	yes
 
 PROGS=		bin/m3build \
 		bin/m3bundle \
@@ -57,6 +58,12 @@
 BOOTSTRAP=	ezm3-${PORTVERSION}-${TARGET}-boot.tar.bz2
 .endif
 
+post-patch:
+.if ${ARCH} == "sparc64" && ${OSVERSION} >= 502107
+	@${REINPLACE_CMD} -E -e 's|(^.*time_t.*=.*)int32_t;|\1int64_t;|' \
+		${WRKSRC}/libs/m3core/src/unix/freebsd-4.sparc64/Utypes.i3
+.endif
+
 do-build:
 	@${ECHO_MSG} "This port does everything in the install step."
 	@${ECHO_MSG} "The build step is a no-op."
Comment 3 John Polstra freebsd_committer freebsd_triage 2004-05-16 18:42:38 UTC
State Changed
From-To: open->closed

Fixed in ports/lang/ezm3/Makefile revision 1.10.  I used the simpler 
patch submitted by Marius Strobl because of the problems mentioned 
in the PR that occur if WRKSRC doesn't exist (and also just because 
it's simpler).  Many thanks to both submitters for helping solve 
this problem.