[GH-ISSUE #5906] build: Error: symbol `fopen64' is already defined (custom time/offset bits)

gitea-mirror commented

2026-05-05 09:45:52 -06:00

Owner

Originally created by @gotthardp on GitHub (Jul 17, 2023).
Original GitHub issue: https://github.com/netblue30/firejail/issues/5906

I am getting the following error when building firejail against the latest gcc/glibc.

| {standard input}:2515: Error: symbol `fopen64' is already defined
| {standard input}:2883: Error: symbol `freopen64' is already defined
| {standard input}:4072: Error: symbol `__stat64_time64' is already defined
| {standard input}:4406: Error: symbol `__lstat64_time64' is already defined

It's due to the defines like bellow, which are not defined by glibc although the functions are available.
dcb5bc0e45/src/libtrace/libtrace.c (L342)

The checks introduced were introduced by the commit a86c4fe93f. It seems those work for musl only.

Environment: gcc 13.1.1 / glibc 2.37

Relates to:

#3297

Originally created by @gotthardp on GitHub (Jul 17, 2023). Original GitHub issue: https://github.com/netblue30/firejail/issues/5906 I am getting the following error when building firejail against the latest gcc/glibc. ``` | {standard input}:2515: Error: symbol `fopen64' is already defined | {standard input}:2883: Error: symbol `freopen64' is already defined | {standard input}:4072: Error: symbol `__stat64_time64' is already defined | {standard input}:4406: Error: symbol `__lstat64_time64' is already defined ``` It's due to the defines like bellow, which are not defined by glibc although the functions are available. https://github.com/netblue30/firejail/blob/dcb5bc0e457f7b58443bbb2e63338d416596a380/src/libtrace/libtrace.c#L342 The checks introduced were introduced by the commit a86c4fe93f130752a862ff0a5ee75f073c3586b1. It seems those work for musl only. Environment: gcc 13.1.1 / glibc 2.37 Relates to: * #3297

gitea-mirror added the

bug

label 2026-05-05 09:45:52 -06:00

gitea-mirror commented

2026-05-05 09:45:55 -06:00

Author

Owner

@gotthardp commented on GitHub (Jul 17, 2023):

As a workaround it helps to add to src/libtrace/libtrace.c and src/libtracelog/libtracelog.c:

#define fopen64 1
#define freopen64 1
#define stat64 1
#define lstat64 1

@gotthardp commented on GitHub (Jul 17, 2023): As a workaround it helps to add to `src/libtrace/libtrace.c` and `src/libtracelog/libtracelog.c`: ``` #define fopen64 1 #define freopen64 1 #define stat64 1 #define lstat64 1 ```

gitea-mirror commented

2026-05-05 09:45:57 -06:00

Author

Owner

@kmk3 commented on GitHub (Jul 17, 2023):

I am getting the following error when building firejail against the latest
gcc/glibc.

| {standard input}:2515: Error: symbol `fopen64' is already defined
| {standard input}:2883: Error: symbol `freopen64' is already defined
| {standard input}:4072: Error: symbol `__stat64_time64' is already defined
| {standard input}:4406: Error: symbol `__lstat64_time64' is already defined

Strange, it builds without issues with the same versions on Artix Linux:

$ pacman -Q gcc glibc
gcc 13.1.1-2
glibc 2.37-3

What is the distribution and version?

Are you building from latest git version?

Please post the output of the following:

./configure
cat config.mk

The checks introduced were introduced by the commit
a86c4fe.
It seems those work for musl only.

Cc: @reinerh @rusty-snake

Relates to:

#5421
#5431

@kmk3 commented on GitHub (Jul 17, 2023): > I am getting the following error when building firejail against the latest > gcc/glibc. > > ``` > | {standard input}:2515: Error: symbol `fopen64' is already defined > | {standard input}:2883: Error: symbol `freopen64' is already defined > | {standard input}:4072: Error: symbol `__stat64_time64' is already defined > | {standard input}:4406: Error: symbol `__lstat64_time64' is already defined > ``` Strange, it builds without issues with the same versions on Artix Linux: ```console $ pacman -Q gcc glibc gcc 13.1.1-2 glibc 2.37-3 ``` What is the distribution and version? Are you building from latest git version? Please post the output of the following: ```sh ./configure cat config.mk ``` > The checks introduced were introduced by the commit > [a86c4fe](https://github.com/netblue30/firejail/commit/a86c4fe93f130752a862ff0a5ee75f073c3586b1). > It seems those work for musl only. Cc: @reinerh @rusty-snake Relates to: * #5421 * #5431

gitea-mirror commented

2026-05-05 09:45:57 -06:00

Author

Owner

@reinerh commented on GitHub (Jul 17, 2023):

Works here as well. Can you please post a full build log, and more details about compiler and glibc?

@reinerh commented on GitHub (Jul 17, 2023): Works here as well. Can you please post a full build log, and more details about compiler and glibc?

gitea-mirror commented

2026-05-05 09:45:58 -06:00

Author

Owner

@gotthardp commented on GitHub (Jul 17, 2023):

It's the Yocto latest master branch. I did some more digging and found that the Yocto build sets two extra CFLAGS="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64, which seem to cause the issue.

The following reproduces the issue even on my standard Fedora 38

CFLAGS="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" ./configure
make

The documentation of the two macros say "If you define this macro", so it seems to be valid settings.

@gotthardp commented on GitHub (Jul 17, 2023): It's the Yocto latest master branch. I did some more digging and found that the Yocto build sets two extra `CFLAGS="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64`, which seem to cause the issue. The following reproduces the issue even on my standard Fedora 38 ``` CFLAGS="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64" ./configure make ``` The [documentation of the two macros](https://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html) say "If you define this macro", so it seems to be valid settings.

gitea-mirror commented

2026-05-05 09:45:59 -06:00

Author

Owner

@reinerh commented on GitHub (Jul 17, 2023):

Thanks, I can reproduce the error with these defines.

@reinerh commented on GitHub (Jul 17, 2023): Thanks, I can reproduce the error with these defines.

gitea-mirror commented

2026-05-05 09:45:59 -06:00

Author

Owner

@reinerh commented on GitHub (Apr 21, 2024):

Happens now also on Debian on armhf, probably since the time64_t transition.

@reinerh commented on GitHub (Apr 21, 2024): Happens now also on [Debian](https://bugs.debian.org/1069449) on armhf, probably since the time64_t transition.

gitea-mirror commented

2026-05-05 09:46:00 -06:00

Author

Owner

@vinc17fr commented on GitHub (Jun 6, 2024):

It's due to the defines like bellow, which are not defined by glibc although the functions are available.

Yes, there are no reasons that a macro is defined for each available function! The patch is definitely wrong. A usual configure test would be needed.

It's the Yocto latest master branch. I did some more digging and found that the Yocto build sets two extra CFLAGS="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64, which seem to cause the issue.

The glibc manual says:

If the sources are compiled with ‘_FILE_OFFSET_BITS == 64’ on a 32
bits machine this function is available under the name ‘fopen’ and
so transparently replaces the old interface.

But it is not clear what change -D_FILE_OFFSET_BITS=64 brings on a 64-bit machine like here. In any case, I don't think that the glibc internals have to be documented.

Note that without these defines, the fopen64 function is still declared by glibc's <stdio.h>, as this can be seen on

#define _GNU_SOURCE
#include <stdio.h>
void f(void) { fopen64("",""); }

with gcc -E and gcc -c (note that _GNU_SOURCE is important and defined by src/libtrace/libtrace.c for firejail).

For firejail, the compilation and linking succeed, but I'm wondering whether the behavior could be incorrect, because there is a definition from the glibc and a definition from firejail/libtrace.

@vinc17fr commented on GitHub (Jun 6, 2024): > It's due to the defines like bellow, which are not defined by glibc although the functions are available. Yes, there are no reasons that a macro is defined for each available function! The patch is definitely wrong. A usual configure test would be needed. > It's the Yocto latest master branch. I did some more digging and found that the Yocto build sets two extra `CFLAGS="-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64`, which seem to cause the issue. The glibc manual says: If the sources are compiled with ‘_FILE_OFFSET_BITS == 64’ on a 32 bits machine this function is available under the name ‘fopen’ and so transparently replaces the old interface. But it is not clear what change `-D_FILE_OFFSET_BITS=64` brings on a 64-bit machine like here. In any case, I don't think that the glibc internals have to be documented. Note that without these defines, the `fopen64` function is still declared by glibc's `<stdio.h>`, as this can be seen on ``` #define _GNU_SOURCE #include <stdio.h> void f(void) { fopen64("",""); } ``` with `gcc -E` and `gcc -c` (note that `_GNU_SOURCE` is important and defined by `src/libtrace/libtrace.c` for firejail). For firejail, the compilation and linking succeed, but I'm wondering whether the behavior could be incorrect, because there is a definition from the glibc and a definition from firejail/libtrace.

Rows
Columns

[GH-ISSUE #5906] build: Error: symbol `fopen64' is already defined (custom time/offset bits) #3129