Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
denizzzka opened this issue Aug 11, 2024 · 3 comments
Open

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

denizzzka opened this issue Aug 11, 2024 · 3 comments

Comments

@denizzzka
Copy link
Contributor

denizzzka commented Aug 11, 2024

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?

@kinke
Copy link
Member

kinke commented Aug 12, 2024

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

@JohanEngelen
Copy link
Member

JohanEngelen commented Aug 12, 2024

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?)

@denizzzka
Copy link
Contributor Author

denizzzka commented Aug 12, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants