Date: Tue, 19 Jul 2016 21:03:39 +0000
From: bugzilla-noreply@freebsd.org
To: freebsd-ports-bugs@FreeBSD.org
Subject: [Bug 211152] benchmarks/iozone: Build fails on typedef redefinition with different types ('long long' vs '__off64_t' (aka 'long'))
Message-ID: <bug-211152-13-wzJFuw9oHr@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-211152-13@https.bugs.freebsd.org/bugzilla/>
References: <bug-211152-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D211152 --- Comment #35 from Mark Millard <markmi@dsl-only.net> --- (In reply to Kubilay Kocak from comment #32) I believe that the following part of the overall changes are all that was required to deal with the original build failure reported (iozone 434 or 444 vintages): typedef off_t off64_t; #endif +#if defined(__FreeBSD__) +#define __off64_t_defined +typedef off_t off64_t; +#endif #ifndef solaris #ifndef off64_t and optionally (__off64_t_defined was sufficient to avoid the typedef): #ifndef SCO_Unixware_gcc #ifndef UWIN #ifndef __DragonFly__ +#ifndef __FreeBSD__ typedef long long off64_t; #endif #endif with its matching: #endif #endif #endif +#endif But the __DragonFly__ in the original code base was also optional because of __off64_t_defined already being defined for that context. So the above optional part-pair maintains the style of handling in the original. One possibility for the CACHE_LINE_SIZE issue for FreeBSD is: +#if !defined(CACHE_LINE_SIZE) #define CACHE_LINE_SIZE 32 +#endif Has anyone contacted the upstream author ( capps@iozone.org ) to see what t= heir criteria are for changes to go upstream? For example: what range of vintage= s of C are to be supported? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-211152-13-wzJFuw9oHr>