ldc icon indicating copy to clipboard operation
ldc copied to clipboard

Wish: accept *.obj on par with *.o for non-Windows targets

Open denizzzka opened this issue 1 year ago • 3 comments

At the moment, such targets strictly require files with .o extension

This leads to issues with CMake - CMake produces .obj files for non-Unix && non-Windows targets. As result, this forces to use in CMake scripts additional config file (it must be a separate file) in a such manner:

if(NOT "${TARGET_SYSTEM}" MATCHES "Windows")
    set(CMAKE_USER_MAKE_RULES_OVERRIDE_C "${CMAKE_CURRENT_SOURCE_DIR}/set_o_output_extension.cmake")
    set(CMAKE_USER_MAKE_RULES_OVERRIDE_ASM "${CMAKE_CURRENT_SOURCE_DIR}/set_o_output_extension.cmake")
endif()

set_o_output_extension.cmake:

set(CMAKE_C_OUTPUT_EXTENSION .o)
set(CMAKE_ASM_OUTPUT_EXTENSION .o)

Clang accepts both variants in this case. Do we have any reason to stay on the existing scheme?

denizzzka avatar Aug 11 '24 21:08 denizzzka

For linking? I assume you can just pass the object files as linker flags then - -LmyWeirdObject.obj.

kinke avatar Aug 12 '24 10:08 kinke

Clang accepts both variants in this case. Do we have any reason to stay on the existing scheme?

Can you be more specific? What is "this" case? Is whatever extensions clang accepts depending on the triple? (if so, for which triples do we need to change?)

JohanEngelen avatar Aug 12 '24 12:08 JohanEngelen

For linking?

Yes

I assume you can just pass the object files as linker flags then - -LmyWeirdObject.obj.

CMake build system does this by different way.

(Actually, I am faced with this issue when building druntime for non-Linux && non-Windows target using runtime/CMakeLists.txt script)

Clang accepts both variants in this case. Do we have any reason to stay on the existing scheme?

Can you be more specific? What is "this" case?

Clang accepts object files for linking with name .obj on par with .o at least in case of unknown OS.

Is whatever extensions clang accepts depending on the triple? (if so, for which triples do we need to change?)

I came across the fact that for thumbv7em-unknown-none-eabi triple Clang accepts both variants (.o and .obj) and not fails CMake build, but ldc2 only accepts .o and this fails CMake build, because by default CMake generates .obj for non-Linux && non-Windows targets

Also, tested right now - when building for Linux Clang uses same approach

denizzzka avatar Aug 12 '24 14:08 denizzzka

Solved in https://github.com/dlang/dmd/pull/20609

denizzzka avatar Jan 13 '25 15:01 denizzzka