fio failed to build on 10.5

[betonmischer86]

Diagnostic info collected below.

gist

[sevan]

Not sure this'll run on 10.5 or anything before Sierra / El Capitan.
The website seems down and the source archive you seem to have in your cache is not archived on the wayback! :)
The tar.gz version is, so I used that to try. Wouldn't build on Tiger with the same error as you + some more errors.

[betonmischer86]

@sevan Even version 2.2.9 from the current formula won't build using the system-provided gcc, but I got further with GCC-14. The latter I had to bootstrap with GCC-8, which itself could have been sufficient (GCC-14 took 3 hours to build on my G5 Quad). Still, version 2.2.9 appears to erroneously set __sync_fetch_and_add to yes with ./configure, which leads to the following build error:

user@home-dt-3 fio % ./configure --cc=gcc-14
...
__sync_fetch_and_add          yes
...
user@home-dt-3 fio % make -j1 V=1
...
Undefined symbols:
  "___sync_fetch_and_add_8", referenced from:
      _sum_ddir in workqueue.o
      _sum_ddir in workqueue.o
      _sum_ddir in workqueue.o
      _sum_ddir in workqueue.o
      _sum_ddir in workqueue.o
ld: symbol(s) not found

On the other hand, the latest version 3.41 from fio github blows up on a different kind of error, despite seemingly being configured to use a workaround for the missing type:

user@home-dt-3 fio % ./configure --cc=gcc-14
...
clockid_t                     no
...
user@home-dt-3 fio % make -j1 V=1
...
crc/../fio_time.h:34:50: error: unknown type name 'clockid_t'; did you mean 'clock_t'?
   34 | extern void set_epoch_time(struct thread_data *, clockid_t, clockid_t);
      |                                                  ^~~~~~~~~
      |                                                  clock_t
crc/../fio_time.h:34:61: error: unknown type name 'clockid_t'; did you mean 'clock_t'?
   34 | extern void set_epoch_time(struct thread_data *, clockid_t, clockid_t);
      |                                                             ^~~~~~~~~
      |                                                             clock_t

Thankfully, I managed to build version 3.7, and it works. There's only a linker error, which doesn't seem to affect anything.

ld: duplicate symbol _tsc_reliable in t/arch.o and gettime.o
collect2: error: ld returned 1 exit status
make: *** [t/fio-dedupe] Error 1

[betonmischer86]

I tried building fio-3.7 with GCC-8 instead of GCC-14, and it worked too. I've no idea what the oldest compatible GCC version is, though.

[sevan]

I tried building fio-3.7 with GCC-8 instead of GCC-14, and it worked too. I've no idea what the oldest compatible GCC version is, though.

Try 4.8, that's the minimum compiler version needed to buld GCC 14. C11 support was completed by 4.9 if a C11 support is lacking. They're fairly quick to compile in comparison to GCC 5.x and up.

[sevan]

@sevan Even version 2.2.9 from the current formula won't build using the system-provided gcc, but I got further with GCC-14. The latter I had to bootstrap with GCC-8, which itself could have been sufficient (GCC-14 took 3 hours to build on my G5 Quad). Still, version 2.2.9 appears to erroneously set __sync_fetch_and_add to yes with ./configure, which leads to the following build error:

user@home-dt-3 fio % ./configure --cc=gcc-14
...
__sync_fetch_and_add          yes
...
user@home-dt-3 fio % make -j1 V=1
...
Undefined symbols:
  "___sync_fetch_and_add_8", referenced from:
      _sum_ddir in workqueue.o
      _sum_ddir in workqueue.o
      _sum_ddir in workqueue.o
      _sum_ddir in workqueue.o
      _sum_ddir in workqueue.o
ld: symbol(s) not found

3 hour to build GCC 14! That would be nice to have but those machines weigh a tonne.
"Fastest" machine I have is a last gen imac g5 isight, but I need to look a the PSU. It was performing worse than my 1s gen imac g5 :D
Looks like the build is choking on atomic operations. I tried to build the lates version last night and it failed when trying to compile crc32 something for arm64. I suspect it now just assumes x86 or arm64.

On the other hand, the latest version 3.41 from fio github blows up on a different kind of error, despite seemingly being configured to use a workaround for the missing type:

user@home-dt-3 fio % ./configure --cc=gcc-14
...
clockid_t                     no
...
user@home-dt-3 fio % make -j1 V=1
...
crc/../fio_time.h:34:50: error: unknown type name 'clockid_t'; did you mean 'clock_t'?
   34 | extern void set_epoch_time(struct thread_data *, clockid_t, clockid_t);
      |                                                  ^~~~~~~~~
      |                                                  clock_t
crc/../fio_time.h:34:61: error: unknown type name 'clockid_t'; did you mean 'clock_t'?
   34 | extern void set_epoch_time(struct thread_data *, clockid_t, clockid_t);
      |                                                             ^~~~~~~~~
      |                                                             clock_t

The clockid_t stuff showed up alongside clock_gettime(3) in Sierra. I think fio has some portability bits to make up for systems that lack it? they missed something here? (I haven't looked closer at the code).

Thankfully, I managed to build version 3.7, and it works. There's only a linker error, which doesn't seem to affect anything.

ld: duplicate symbol _tsc_reliable in t/arch.o and gettime.o
collect2: error: ld returned 1 exit status
make: *** [t/fio-dedupe] Error 1

I wonder if the portability gettime object trips things up.

[betonmischer86]

I opened an issue for version 3.41. The related commit is this one, and the lines in ‎os/os-mac.h‎ are still there.

GCC 4.8 is indeed new enough to build fio-3.7. I wonder if there is a way to specify the minimum required version of GCC in a formula, but not make that exact version a hard dependency in case a newer GCC is already installed.

[sevan]

I opened an issue for version 3.41. The related commit is this one, and the lines in ‎os/os-mac.h‎ are still there.

Cool :)

GCC 4.8 is indeed new enough to build fio-3.7. I wonder if there is a way to specify the minimum required version of GCC in a formula, but not make that exact version a hard dependency in case a newer GCC is already installed.

Yep. For now exclude the compilers (the knob to say this formula needs such and such language standard support needs work).

Example:

  # Need a compiler with C11 support 
  fails_with :gcc
  fails_with :gcc_4_0

[sitsofe]

(FYI: fio 3.22 and above will need at least GCC 4.9 for C11 atomics. See https://github.com/axboe/fio/blob/fio-3.41/configure#L658 and https://gcc.gnu.org/wiki/C11Status )

[betonmischer86]

Hi @mistydemeo! The existing formula for fio can fixed by updating the repo URL and excluding incompatible system-provided compilers. Version 2.2.9 can be safely bumped to 3.7. I also managed to backport fio-3.41, but that required a shim to substitute for the clock_gettime() function missing from Tiger and Leopard. Let me know if you would rather have both fio-3.7 and fio-3.41 versions as separate formulae or move straight to 3.41.

Instead of baking the clock_gettime() shim into fio-3.41, it can be wrapped into its own package to be used as a dependency for fio and other software that may require the same compatibility hack. Again, LMK which method is preferred.

[sevan]

@betonmischer86 best to just raise a pull request for 3.41 and one of us will review it. Let's see the shim and we can work from there (if it requires major surgery maybe it would be better to stick with 3.7 after). Since you're using the tool, you're in a better position to judge :)