RFR: 8372643: Warning message on macos when building the JDK - (arm64) /tmp/lto.o unable to open object file: No such file or directory

Erik Joelsson erikj at openjdk.org
Mon Dec 1 19:01:32 UTC 2025


On Fri, 28 Nov 2025 15:47:04 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> When building the recent mainline JDK (26), I see the following warning messages:
> 
> warning: (arm64) /tmp/lto.o unable to open object file: No such file or directory
> warning: no debug symbols in executable (-arch arm64)
> 
> 
> The build completes normally even with these warnings.
> I am on macos aarch64, but I see the same warning on macos x64 and aarch64 in our CI.
> Seems we miss a linker flag for libs built with lto (libsplashscreen), because the Apple linker has the following issue
> 
> https://clang.llvm.org/docs/CommandGuide/clang.html
> Note
> 
> `
> On Darwin, when using [-flto](https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-flto) along with [-g](https://clang.llvm.org/docs/CommandGuide/clang.html#cmdoption-g) and compiling and linking in separate steps, you also need to pass -Wl,-object_path_lto,<lto-filename>.o at the linking step to instruct the ld64 linker not to delete the temporary object file generated during Link Time Optimization (this flag is automatically passed to the linker by Clang if compilation and linking are done in a single step). This allows debugging the executable as well as generating the .dSYM bundle using dsymutil(1).`

make/autoconf/flags-ldflags.m4 line 83:

> 81:     else
> 82:       LDFLAGS_LTO="-flto=auto -fuse-linker-plugin -fno-strict-aliasing"
> 83:     fi

The way I understand this flag, we are defining a non temporary location for this file. Just specifying a file name without a directory path means it's relative to the directory where the compiler is running, which in our case is `make/`. We do not want to drop files in the source tree. Also, this file needs to be unique for each link unit using lto, so we can't have a global value defined here in configure. The filename needs to be generated uniquely into the build output dir for each call to SetupNativeCompilation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28559#discussion_r2578270182


More information about the build-dev mailing list