On Fri, 28 Nov 2025 15:47:04 GMT, Matthias Baesken <[email protected]> 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

Reply via email to