Re: iozone3-434 fails to rebuild

[Walter Schwarzenfeld]

Proposed patch:

Index: files/patch-iozone.c
===
--- files/patch-iozone.c(revision 417289)
+++ files/patch-iozone.c(nonexistent)
@@ -1,27 +0,0 @@
 iozone.c.orig2015-10-20 14:12:13 UTC
-+++ iozone.c
-@@ -360,6 +360,7 @@ typedef off_t off64_t;
- #ifndef SCO_Unixware_gcc
- #ifndef UWIN
- #ifndef __DragonFly__
-+#ifndef __FreeBSD__
- typedef long long off64_t;
- #endif
- #endif
-@@ -369,6 +370,7 @@ typedef long long off64_t;
- #endif
- #endif
- #endif
-+#endif
-
- #ifdef __AIX__
- #include 
-@@ -23009,7 +23011,7 @@ char *shell;
- #ifdef _HPUX_SOURCE
- strcpy(shell,"remsh");
- #else
--strcpy(shell,"rsh");
-+strcpy(shell,"ssh");
- #endif
- return;
- }

Property changes on: files/patch-iozone.c
___
Deleted: fbsd:nokeywords
## -1 +0,0 ##
-yes
\ No newline at end of property
Deleted: svn:eol-style
## -1 +0,0 ##
-native
\ No newline at end of property
Deleted: svn:mime-type
## -1 +0,0 ##
-text/plain
\ No newline at end of property
Index: files/patch-libasync.c
===
--- files/patch-libasync.c(revision 417289)
+++ files/patch-libasync.c(nonexistent)
@@ -1,36 +0,0 @@
 libasync.c.orig2015-10-20 14:12:13 UTC
-+++ libasync.c
-@@ -96,13 +96,13 @@
-
- #include 
- #include 
--#if defined(solaris) || defined(linux) || defined(SCO_Unixware_gcc) || 
defined(__NetBSD__)
-+#if defined(solaris) || defined(linux) || defined(SCO_Unixware_gcc) || 
defined(__NetBSD__) || defined(__FreeBSD__)

- #else
- #include 
- #endif
- #include 
- #include 
--#ifndef bsd4_4
-+#if !defined(bsd4_4) && !defined(__FreeBSD__)
- #include 
- #endif
- #ifdef VXFS
-@@ -119,7 +119,7 @@
- #include 
- #endif
-
--#if (defined(solaris) && defined(__LP64__)) || defined(__s390x__) || 
defined(FreeBSD) || defined(__NetBSD__)
-+#if (defined(solaris) && defined(__LP64__)) || defined(__s390x__) || 
defined(__FreeBSD__) || defined(__NetBSD__)
- /* If we are building for 64-bit Solaris, all functions that return 
pointers
-  * must be declared before they are used; otherwise the compiler will 
assume

-  * that they return ints and the top 32 bits of the pointer will be lost,
-@@ -135,7 +135,7 @@
- void mbcopy(char *source, char *dest, size_t len);
-
-
--#if !defined(solaris) && !defined(off64_t) && !defined(_OFF64_T) && 
!defined(__off64_t_defined) && !defined(SCO_Unixware_gcc)
-+#if !defined(solaris) && !defined(off64_t) && !defined(_OFF64_T) && 
!defined(__off64_t_defined) && !defined(SCO_Unixware_gcc) && 
!defined(__FreeBSD__)

- typedef long long off64_t;
- #endif
- #if defined(OSFV5)

Property changes on: files/patch-libasync.c
___
Deleted: fbsd:nokeywords
## -1 +0,0 ##
-yes
\ No newline at end of property
Deleted: svn:eol-style
## -1 +0,0 ##
-native
\ No newline at end of property
Deleted: svn:mime-type
## -1 +0,0 ##
-text/plain
\ No newline at end of property

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: iozone3-434 fails to rebuild

[Walter Schwarzenfeld]

I wrote it above. Remove or rename the two patches in the files directory.
It builds with warnings. I have tested only quick the functionality. 
This worked. Don't know if all will work.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: iozone3-434 fails to rebuild

[Don Lewis]

On 21 Jun, Jim Ohlstein wrote:
> Hello,
> 
>> On Jun 21, 2016, at 4:14 PM, Alphons van Werven 
>> wrote:
>> 
>> Doug Sampson wrote:
>> 
>>> it crashes as follows:
>>> 
>>>  ###
>>> <...snip...>
>>> iozone.c:1297:1: error: unknown type name 'off64_t'; did you mean
>>> 'off_t'? off64_t offset = 0;   /*offset for random I/O
>>> */
>>> ^~~
>>> off_t
>>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>>> typedef __off_t off_t;  /* file offset */
>>>^
>> [snip]
>>> Doesn't matter which config options I select/deselect,
>> 
>> As far as I can tell it doesn't *crash*, it merely fails to build ;-)
>> 
>> I don't think the options are relevant in this case. If I'm not
>> mistaken off64_t is some kind of GNU extension, but installing
>> lang/gcc and trying to compile a piece of sample code with GCC still
>> didn't work for me. Which means I can reproduce the problem on
>> 10.2-RELEASE-p19/amd64.
>> 
>> There seems to be a #define or typedef missing somewhere. Perhaps
>> somebody can ask around upstream what the authors are expecting from
>> the off64_t type, so we can find a suitable replacement on FreeBSD
>> systems: probably offset_t, (u)int64_t, or something along those
>> lines.
> 
> How about it be reverted to the previous, WORKING, version in the
> meantime, and before an "upgrade" is committed, proper testing is
> done?

The previous version didn't build on recent FreeBSD 11, which does
define off64_t.  I started trying to fix it, but the code is really
nasty and I finally gave up.

___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: iozone3-434 fails to rebuild

[Walter Schwarzenfeld]

Remove or rename files/patch-iozone.c and files/patch-libasync.c .
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: iozone3-434 fails to rebuild

[Jim Ohlstein]

Hello,

> On Jun 21, 2016, at 4:14 PM, Alphons van Werven  wrote:
> 
> Doug Sampson wrote:
> 
>> it crashes as follows:
>> 
>>  ###
>> <...snip...>
>> iozone.c:1297:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
>> off64_t offset = 0;   /*offset for random I/O */
>> ^~~
>> off_t
>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>> typedef __off_t off_t;  /* file offset */
>>^
> [snip]
>> Doesn't matter which config options I select/deselect,
> 
> As far as I can tell it doesn't *crash*, it merely fails to build ;-)
> 
> I don't think the options are relevant in this case. If I'm not mistaken
> off64_t is some kind of GNU extension, but installing lang/gcc and trying
> to compile a piece of sample code with GCC still didn't work for me. Which
> means I can reproduce the problem on 10.2-RELEASE-p19/amd64.
> 
> There seems to be a #define or typedef missing somewhere. Perhaps somebody
> can ask around upstream what the authors are expecting from the off64_t
> type, so we can find a suitable replacement on FreeBSD systems: probably
> offset_t, (u)int64_t, or something along those lines.

How about it be reverted to the previous, WORKING, version in the meantime, and 
before an "upgrade" is committed, proper testing is done?

Just sayin'

--
Jim
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: iozone3-434 fails to rebuild

[Alphons van Werven]

Doug Sampson wrote:

> it crashes as follows:
> 
>   ###
> <...snip...>
> iozone.c:1297:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
> off64_t offset = 0;   /*offset for random I/O */
> ^~~
> off_t
> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
> typedef __off_t off_t;  /* file offset */
> ^
[snip]
> Doesn't matter which config options I select/deselect,

As far as I can tell it doesn't *crash*, it merely fails to build ;-)

I don't think the options are relevant in this case. If I'm not mistaken
off64_t is some kind of GNU extension, but installing lang/gcc and trying
to compile a piece of sample code with GCC still didn't work for me. Which
means I can reproduce the problem on 10.2-RELEASE-p19/amd64.

There seems to be a #define or typedef missing somewhere. Perhaps somebody
can ask around upstream what the authors are expecting from the off64_t
type, so we can find a suitable replacement on FreeBSD systems: probably
offset_t, (u)int64_t, or something along those lines.

HTH,

Fonz

-- 
A.J. "Fonz" van Werven
mailsig: Ob technicas difficultates, lux in fine cuniculum non operatur.


signature.asc
Description: PGP signature

Re: iozone3-434 fails to rebuild

[Lowell Gilbert]

Kimmo Paasiala  writes:

> Same here on 10.3-RELEASE. I wonder how the port got updated with
> sponsorship from "Gandi.net", yet the committed changes were
> apparently not tested?

It may well work in their environment. I suspect you could fix the build
with an appropriate CFLAGS setting: something like "-Doff64_t=off_t".

I don't have my build machine up right now, but looking at the source
code, the upstream source does try to deal with defining off64_t for
some platforms. It knows about FreeBSD, but doesn't define it for
FreeBSD. I think that everything system-specific like that should be the
same for FreeBSD as for DragonflyBSD.
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: iozone3-434 fails to rebuild

[Jim Ohlstein]

+1

> On Jun 21, 2016, at 3:07 PM, Kimmo Paasiala  wrote:
> 
>> On Tue, Jun 21, 2016 at 9:32 PM, Doug Sampson  wrote:
>> Trying to rebuild iozone after a recent port upgrade and it crashes as 
>> follows:
>> 
>>  ###
>> <...snip...>
>> iozone.c:1297:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
>> off64_t offset = 0;   /*offset for random I/O */
>> ^~~
>> off_t
>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>> typedef __off_t off_t;  /* file offset */
>>^
>> iozone.c:1298:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
>> off64_t offset64 = 0;   /*offset for random I/O */
>> ^~~
>> off_t
>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>> typedef __off_t off_t;  /* file offset */
>>^
>> iozone.c:1299:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
>> off64_t filebytes64;
>> ^~~
>> off_t
>> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
>> typedef __off_t off_t;  /* file offset */
>>^
>> fatal error: too many errors emitted, stopping now [-ferror-limit=]
>> 2 warnings and 20 errors generated.
>> *** Error code 1
>> 
>> Stop.
>> make[2]: stopped in /usr/ports/benchmarks/iozone/work/iozone3_434/src/current
>> *** Error code 1
>> 
>> Stop.
>> make[1]: stopped in /usr/ports/benchmarks/iozone
>> *** Error code 1
>> 
>> Stop.
>> make: stopped in /usr/ports/benchmarks/iozone
>> root@pisces:/usr/ports/benchmarks/iozone#
>>   ###
>> 
>> root@pisces:/usr/ports/benchmarks/iozone# make showconfig
>> ===> The following configuration options are available for iozone-3.434:
>> SSH=on: Use ssh in distributed measurement
>> THREADS=on: Enable threading (uses pthreads)
>> ===> Use 'make config' to modify these settings
>> root@pisces:/usr/ports/benchmarks/iozone#
>> 
>> Doesn't matter which config options I select/deselect, it still fails to 
>> rebuild. It occurs on both 10.3-RELEASE-p4 i386 and 10.3-RELEASE-p4 amd64 
>> systems.
>> 
>> 
>> ~Doug
>> ___
> 
> Same here on 10.3-RELEASE. I wonder how the port got updated with
> sponsorship from "Gandi.net", yet the committed changes were
> apparently not tested? Shouldn't Gandi.net volunteer as the maintainer
> for the port if they want it to be updated (the port is unmaintained
> at the moment)?
> 
> -Kimmo
> ___
> freebsd-ports@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-ports
> To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"

Re: iozone3-434 fails to rebuild

[Kimmo Paasiala]

On Tue, Jun 21, 2016 at 9:32 PM, Doug Sampson  wrote:
> Trying to rebuild iozone after a recent port upgrade and it crashes as 
> follows:
>
>   ###
> <...snip...>
> iozone.c:1297:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
> off64_t offset = 0;   /*offset for random I/O */
> ^~~
> off_t
> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
> typedef __off_t off_t;  /* file offset */
> ^
> iozone.c:1298:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
> off64_t offset64 = 0;   /*offset for random I/O */
> ^~~
> off_t
> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
> typedef __off_t off_t;  /* file offset */
> ^
> iozone.c:1299:1: error: unknown type name 'off64_t'; did you mean 'off_t'?
> off64_t filebytes64;
> ^~~
> off_t
> /usr/include/sys/types.h:173:18: note: 'off_t' declared here
> typedef __off_t off_t;  /* file offset */
> ^
> fatal error: too many errors emitted, stopping now [-ferror-limit=]
> 2 warnings and 20 errors generated.
> *** Error code 1
>
> Stop.
> make[2]: stopped in /usr/ports/benchmarks/iozone/work/iozone3_434/src/current
> *** Error code 1
>
> Stop.
> make[1]: stopped in /usr/ports/benchmarks/iozone
> *** Error code 1
>
> Stop.
> make: stopped in /usr/ports/benchmarks/iozone
> root@pisces:/usr/ports/benchmarks/iozone#
>###
>
> root@pisces:/usr/ports/benchmarks/iozone# make showconfig
> ===> The following configuration options are available for iozone-3.434:
>  SSH=on: Use ssh in distributed measurement
>  THREADS=on: Enable threading (uses pthreads)
> ===> Use 'make config' to modify these settings
> root@pisces:/usr/ports/benchmarks/iozone#
>
> Doesn't matter which config options I select/deselect, it still fails to 
> rebuild. It occurs on both 10.3-RELEASE-p4 i386 and 10.3-RELEASE-p4 amd64 
> systems.
>
>
> ~Doug
> ___

Same here on 10.3-RELEASE. I wonder how the port got updated with
sponsorship from "Gandi.net", yet the committed changes were
apparently not tested? Shouldn't Gandi.net volunteer as the maintainer
for the port if they want it to be updated (the port is unmaintained
at the moment)?

-Kimmo
___
freebsd-ports@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"