esnet / esnet/iperf

Build failure on platforms without `<stdatomic.h>` due to use of non-standard `u_int64_t`

Open Beginner friendly
#2,060 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
C
Stars
8.8k
Forks
1.5k
PR merge metrics
No merged PRs in 30d

Description

I am having trouble cross-compiling iperf v3.21 in julia's BinaryBuilder.jl toolchain (see https://github.com/JuliaPackaging/Yggdrasil/pull/14208). The affected platforms are:
- i686-linux-musl
- x86_64-linux-musl
- aarch64-linux-musl
- armv6l-linux-musleabihf
- armv7l-linux-musleabihf

The following writeup was written with the assistance of ChatGPT.

### Description

Building iperf 3.21 fails on targets where `` is not available. The failure occurs in the fallback atomic type definition in `src/iperf_api.h`.

The build emits the following warning and error:

```
../src/iperf_api.h:47:2: warning: #warning "No available" [-Wcpp]
#warning "No available"

../src/iperf_api.h:48:1: error: unknown type name ‘u_int64_t’
typedef u_int64_t atomic_uint_fast64_t;
^
```

### Reproduction environment

I am building iperf 3.21 using Julia's BinaryBuilder infrastructure, which builds portable binaries across multiple target platforms.

The relevant build command is:

```
./configure --prefix=${prefix} --build=${MACHTYPE} --host=${target} --disable-profiling
make -j${nproc}
make install
```

The failure occurs during compilation of the `mis` component:

```
cc -std=gnu11 -DHAVE_CONFIG_H -I. -I../src -g -g -O2 -Wall -pthread \
-MT mis-mis.o -MD -MP -MF .deps/mis-mis.Tpo \
-c -o mis-mis.o mis.c
```

### Cause

When C11 atomics are unavailable, `src/iperf_api.h` provides a fallback definition:

```c
#ifndef HAVE_STDATOMIC_H
#warning "No available"
typedef u_int64_t atomic_uint_fast64_t;
#endif
```

However, `u_int64_t` is not a standard C type. It is a BSD-derived typedef that is not guaranteed to exist on all platforms. Portable C code should use `uint64_t`, which is defined by ``.

As a result, platforms without `` but without BSD integer typedefs fail to compile.

### Suggested fix

Replace the fallback typedef with a standard fixed-width integer type:

```c
#ifndef HAVE_STDATOMIC_H
#warning "No available"
#include
typedef uint64_t atomic_uint_fast64_t;
#endif
```

Alternatively, include the appropriate header that defines `u_int64_t` if retaining that typedef is desired, although using `uint64_t` would be more portable.

### Additional context

The issue does not appear on systems where either:

* `` is available and the fallback code is not used, or
* system headers provide the BSD `u_int64_t` typedef.

It affects cross-platform builds targeting environments with limited libc headers or non-BSD-derived C libraries.

A small change to the fallback implementation should make iperf build successfully on these targets.

Contributor guide

Open the contributing guide

Research direction

Start in src/iperf_api.h at the fallback atomic type definition used when HAVE_STDATOMIC_H is unavailable. Reproduce with the configure and make commands in the issue, targeting one of the listed musl platforms, then verify that the fallback uses a portable standard integer type and that the mis component builds successfully.

Written by the indexing model from the issue text.

Assessment

Tech stack
c
Domain
networking
Issue type
Bug
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Quiet
Clarity
Clearly specified
Newbie friendliness
78/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.