Am Sun, 27 Jul 2025 08:11:16 +0200
schrieb Andreas Grabher <andreas_g86@xxxxxxxxxx>:
Am 27.07.2025 um 07:38 schrieb Thomas Huth <th.huth@xxxxxxxxx>:
Am Sat, 26 Jul 2025 23:07:51 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
Le 21/07/2025 à 11:45, Andreas Grabher a écrit :
Hello all,
it seems the latest compilers on macOS require -fno-common to be set in
order to avoid a compilation error (/ld: warning: reducing alignment of
section __DATA,__common from 0x8000 //to 0x4000 because it exceeds
segment maximum alignment/).
Here is a post about the issue: https://lists.ffmpeg.org/pipermail/
ffmpeg-devel/2025-May/343169.html <https://lists.ffmpeg.org/pipermail/
ffmpeg-devel/2025-May/343169.html>
At the moment -fno-common is only set if ASAN is enabled but it should
always be set.
Hi
for now this doesn't seem to create an issue in our macOS cirrus-ci
build, but that's certainly because we doesn't use the latest macOS in
the CI job.
Let's see after 2.6.1 if there's any side effect when -fno-common is used.
According to that description on ffmpeg.org, the issue should be there
since GCC 10 and Clang 11, which are certainly several years old already
and used in older macOS versions, too. But the issue apparently only
triggers when you try to use large global tables. I guess we don't have
such large global tables in Hatari, otherwise we would have seen such
linking errors in the CI before.
Thomas
I appended the console output from compiling the latest version of Hatari on my system using the latest Xcode and command line tools (replaced the path with X, everything else unmodified).
[ 84%] Linking C executable Hatari.app/Contents/MacOS/Hatari
ld: warning: reducing alignment of section __DATA,__common from 0x8000 to 0x4000 because it exceeds segment maximum alignment
As also mentioned in the ffmpeg mailing list the issue occurs since Xcode 16.3 (a few month old), or to be more specific the command line tools that came along with that version.
Ah, sorry, apparently I got that information from the ffmpeg.org page wrong.
Does a patch like this fix the issue for you?
diff --git a/CMakeLists.txt b/CMakeLists.txt
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -267,6 +267,11 @@ if(CMAKE_COMPILER_IS_GNUCC OR CMAKE_C_COMPILER_ID MATCHES "Clang")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wformat-security")
endif()
+if(APPLE AND CMAKE_C_COMPILER_ID MATCHES "Clang")
+
# Silence linker warning with AppleClang 17
+
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fno-common")
+endif()
+
CHECK_C_COMPILER_FLAG("-Wimplicit-fallthrough=2" WARN_FALLTRHOUGH_AVAILABLE)
if(WARN_FALLTRHOUGH_AVAILABLE)
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wimplicit-fallthrough=2")
Thomas