Skip to content

Linux CMake lib prefix not generated #114

Open
Open
Linux CMake lib prefix not generated#114
Labels
bugSomething isn't working

Description

@silenuz
silenuz
opened on Apr 10, 2026

Godot version

v 4.6.1

godot-cpp version

current - cloned today

System information

Linux Open suse Tumbleweed

Issue description

I recently had a problem working on an extension and didn't notice the problem for a while because I always built things first with scons. However on a recent project I had not built with scons I started getting file not found errors for the generated shared library.

After solving my user errors, I still had to edit the .gdextension file to adjust the name of the built library file because the cmake build does not add the lib prefix.

To confirm this I cloned the template and tried building it without any changes using cmake. The template builds and launches but there are errors:

ERROR: Condition "!FileAccess::exists(path)" is true. Returning: ERR_FILE_NOT_FOUND
   at: open_dynamic_library (drivers/unix/os_unix.cpp:1061)
ERROR: Condition "!FileAccess::exists(path)" is true. Returning: ERR_FILE_NOT_FOUND
   at: open_dynamic_library (drivers/unix/os_unix.cpp:1061)
ERROR: GDExtension dynamic library not found: 'res://bin/example.gdextension'.
   at: open_library (core/extension/gdextension.cpp:740)
ERROR: Error loading extension: 'res://bin/example.gdextension'.

To fix I had to add the lib prefix explicitly to the libname variable in the cmake lists file or edit the gdextnsions file to omit the lib prefix in the library name.

not sure if related to #38 or #107 ?

Edit:
Here's a screenshot in case it's unclear what I mean. At the top is the library file that is generated, and at the bottom the gdextension file. Note the library generated lacks the lib prefix that is present in the gdextension file for each of the library file names.

Image

Activity

  1. Ivorforce commented on Apr 10, 2026

    @Ivorforce
    Ivorforce
    on Apr 10, 2026
    Member

    CC @enetheru

  2. paddy-exe
    added
    bugSomething isn't working
    on Apr 11, 2026

  3. enetheru commented on Apr 11, 2026

    @enetheru
    enetheru
    on Apr 11, 2026
    Contributor

    The CMake solution omits the prefix because I was testing on windows where the prefix is not added in scons.
    From my testing removing the line that clears the prefix adds the 'lib' prefix on windows making it misaligned with the scons code.
    I think a consistent solution would have scons adopting the lib prefix for windows, and cmake removing the clearing of it.
    Then all platforms look the same with the lib*, instead of windows being an odd ball without it.

  4. silenuz commented on Apr 11, 2026

    @silenuz
    silenuz
    on Apr 11, 2026
    Author

    I came up with a simple hack, but it probably wouldn't work for a cross compile because it checks the host system, and not the target platform. On windows it produces the lib with no prefix, and the rest have the lib prefix added. Just before it sets the target properties for the library I added this block of code:

    if(WIN32)
    set(LIBPREFIX "")
else ()
    set(LIBPREFIX "lib")
endif ()

    Then I changed the OUPUT_NAME variable in set_target_properties to include the LIBPREFIX variable like so:

    OUTPUT_NAME "${LIBPREFIX}${LIBNAME}${GODOTCPP_SUFFIX}"

    All Together:

    
if(WIN32)
    set(LIBPREFIX "")
else ()
    set(LIBPREFIX "lib")
endif ()

set_target_properties(${LIBNAME}
    PROPERTIES
    # The generator expression here prevents msvc from adding a Debug or Release subdir.
    RUNTIME_OUTPUT_DIRECTORY "$<1:${PROJECT_SOURCE_DIR}/bin/${GODOTCPP_PLATFORM}>"

    PREFIX ""
    OUTPUT_NAME "${LIBPREFIX}${LIBNAME}${GODOTCPP_SUFFIX}"
)

    I guess alternatively one could use the variable value to set the prefix value.

    Edit:
    Actually after further checking, it seems that if(WIN32) does check the target platform instead of the host system, so it should be compatible with cross platform builds.

  5. dsnopek commented on Apr 13, 2026

    @dsnopek
    dsnopek
    on Apr 13, 2026
    Contributor

    I think a consistent solution would have scons adopting the lib prefix for windows, and cmake removing the clearing of it.
    Then all platforms look the same with the lib*, instead of windows being an odd ball without it.

    I'd personally be fine with using the lib* prefix on all platforms. It doesn't hurt anything, even if it isn't Windows convention

  6. silenuz commented on Apr 14, 2026

    @silenuz
    silenuz
    on Apr 14, 2026
    Author

    Oops did it again. Don't know if this should be separate issue, I'll put it here and you can decide.

    I see if I set set(GODOTCPP_DEV_BUILD ON) in CMakeLIsts.txt, the library created by cmake is not named the same as the the library created by scons for the same value.

    scons dev_build=yes

    results in a library named the same as a regular build:

    libEXTENSION-NAME.linux.template_debug.x86_64.so

    while the cmake file name ends up being:
    libEXTENSION-NAME.linux.template_debug.dev.x86_64.so

  7. enetheru commented on Apr 15, 2026

    @enetheru
    enetheru
    on Apr 15, 2026
    Contributor

    That would indicate to me that the template project scons configuration is not following the convention of godot-cpp scons files where the dev is added to the library name.

  8. silenuz commented on Apr 15, 2026

    @silenuz
    silenuz
    on Apr 15, 2026
    Author

    Just saw your message and had a look and you are correct, line 52 of the SConstruct file strips the .dev portion of the suffix.

    This is what I ended up doing in my cmake file just so I wouldn't have to adjust the names in the gdextension file each time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions