Ok, this is a weird one. Apparently platform detection either fails or isn' "remembered" when "-S ." is used to specify the source directory but if "." is added to the end of the cmake command line it configures fine.
Shouldn't these work exactly the same?
When "-S ." is used (as it's set in %cmake) the configure fails in two ways:
1. GNUInstallDirs complains it can't set CMAKE_INSTALL_LIBDIR
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:239 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs.
2. Some libraries are not found, I think for the same reason. Using --debug-find I see that no incarnation of "lib64" is checked:
find_library considered the following locations:
/builddir/.local/bin/lib/(lib)mbedtls(.so|.a) /builddir/.local/bin/(lib)mbedtls(.so|.a) /builddir/bin/lib/(lib)mbedtls(.so|.a) /builddir/bin/(lib)mbedtls(.so|.a) /usr/bin/lib/(lib)mbedtls(.so|.a) /usr/bin/(lib)mbedtls(.so|.a) /bin/lib/(lib)mbedtls(.so|.a) /bin/(lib)mbedtls(.so|.a) /usr/sbin/lib/(lib)mbedtls(.so|.a) /usr/sbin/(lib)mbedtls(.so|.a) /sbin/lib/(lib)mbedtls(.so|.a) /sbin/(lib)mbedtls(.so|.a) /usr/local/sbin/lib/(lib)mbedtls(.so|.a) /usr/local/sbin/(lib)mbedtls(.so|.a) /usr/local/lib/lib/(lib)mbedtls(.so|.a) /usr/local/lib/(lib)mbedtls(.so|.a) /usr/local/lib/(lib)mbedtls(.so|.a) /usr/local/(lib)mbedtls(.so|.a) /usr/lib/lib/(lib)mbedtls(.so|.a) /usr/lib/(lib)mbedtls(.so|.a) /usr/lib/(lib)mbedtls(.so|.a) /usr/(lib)mbedtls(.so|.a) /lib/lib/(lib)mbedtls(.so|.a) /lib/(lib)mbedtls(.so|.a) /usr/X11R6/lib/lib/(lib)mbedtls(.so|.a) /usr/X11R6/lib/(lib)mbedtls(.so|.a) /usr/X11R6/lib/(lib)mbedtls(.so|.a) /usr/X11R6/(lib)mbedtls(.so|.a) /usr/pkg/lib/lib/(lib)mbedtls(.so|.a) /usr/pkg/lib/(lib)mbedtls(.so|.a) /usr/pkg/lib/(lib)mbedtls(.so|.a) /usr/pkg/(lib)mbedtls(.so|.a) /opt/lib/lib/(lib)mbedtls(.so|.a) /opt/lib/(lib)mbedtls(.so|.a) /opt/lib/(lib)mbedtls(.so|.a) /opt/(lib)mbedtls(.so|.a) /usr/lib/X11/lib/(lib)mbedtls(.so|.a) /usr/lib/X11/(lib)mbedtls(.so|.a)
Looking at the source of GNUInstallDirs the only reason to see that message is:
if (NOT DEFINED CMAKE_SYSTEM_NAME OR NOT DEFINED CMAKE_SIZEOF_VOID_P) message(AUTHOR_WARNING "Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. " "Please enable at least one language before including GNUInstallDirs.") endif()
So why the heck would using "-S ." make any difference?
See: https://bugzilla.redhat.com/show_bug.cgi?id=2079833
--
Michal Schorm Software Engineer Core Services - Databases Team Red Hat
--
On Sun, Jun 12, 2022 at 7:49 PM Richard Shaw hobbes1069@gmail.com wrote:
Ok, this is a weird one. Apparently platform detection either fails or isn' "remembered" when "-S ." is used to specify the source directory but if "." is added to the end of the cmake command line it configures fine.
Shouldn't these work exactly the same?
When "-S ." is used (as it's set in %cmake) the configure fails in two ways:
- GNUInstallDirs complains it can't set CMAKE_INSTALL_LIBDIR
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:239 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs.
- Some libraries are not found, I think for the same reason. Using --debug-find I see that no incarnation of "lib64" is checked:
find_library considered the following locations:
/builddir/.local/bin/lib/(lib)mbedtls(\.so|\.a) /builddir/.local/bin/(lib)mbedtls(\.so|\.a) /builddir/bin/lib/(lib)mbedtls(\.so|\.a) /builddir/bin/(lib)mbedtls(\.so|\.a) /usr/bin/lib/(lib)mbedtls(\.so|\.a) /usr/bin/(lib)mbedtls(\.so|\.a) /bin/lib/(lib)mbedtls(\.so|\.a) /bin/(lib)mbedtls(\.so|\.a) /usr/sbin/lib/(lib)mbedtls(\.so|\.a) /usr/sbin/(lib)mbedtls(\.so|\.a) /sbin/lib/(lib)mbedtls(\.so|\.a) /sbin/(lib)mbedtls(\.so|\.a) /usr/local/sbin/lib/(lib)mbedtls(\.so|\.a) /usr/local/sbin/(lib)mbedtls(\.so|\.a) /usr/local/lib/lib/(lib)mbedtls(\.so|\.a) /usr/local/lib/(lib)mbedtls(\.so|\.a) /usr/local/lib/(lib)mbedtls(\.so|\.a) /usr/local/(lib)mbedtls(\.so|\.a) /usr/lib/lib/(lib)mbedtls(\.so|\.a) /usr/lib/(lib)mbedtls(\.so|\.a) /usr/lib/(lib)mbedtls(\.so|\.a) /usr/(lib)mbedtls(\.so|\.a) /lib/lib/(lib)mbedtls(\.so|\.a) /lib/(lib)mbedtls(\.so|\.a) /usr/X11R6/lib/lib/(lib)mbedtls(\.so|\.a) /usr/X11R6/lib/(lib)mbedtls(\.so|\.a) /usr/X11R6/lib/(lib)mbedtls(\.so|\.a) /usr/X11R6/(lib)mbedtls(\.so|\.a) /usr/pkg/lib/lib/(lib)mbedtls(\.so|\.a) /usr/pkg/lib/(lib)mbedtls(\.so|\.a) /usr/pkg/lib/(lib)mbedtls(\.so|\.a) /usr/pkg/(lib)mbedtls(\.so|\.a) /opt/lib/lib/(lib)mbedtls(\.so|\.a) /opt/lib/(lib)mbedtls(\.so|\.a) /opt/lib/(lib)mbedtls(\.so|\.a) /opt/(lib)mbedtls(\.so|\.a) /usr/lib/X11/lib/(lib)mbedtls(\.so|\.a) /usr/lib/X11/(lib)mbedtls(\.so|\.a)
Looking at the source of GNUInstallDirs the only reason to see that message is:
if (NOT DEFINED CMAKE_SYSTEM_NAME OR NOT DEFINED CMAKE_SIZEOF_VOID_P) message(AUTHOR_WARNING "Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. " "Please enable at least one language before including GNUInstallDirs.") endif()
So why the heck would using "-S ." make any difference? _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sun, Jun 12, 2022 at 1:03 PM Michal Schorm mschorm@redhat.com wrote:
Perhaps related, I see the reference to my earlier user list thread. But unless I missed something it doesn't seem to be an exact match unless we've modified upstream CMakes behavior.
What's even stranger is I added debug messages showing the value of the variables used in the logic of the message and it clearly shows CMAKE_SYSTEM_NAME is defined:
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:239 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMAKE_SYSTEM_NAME: Linux CMAKE_SIZEOF_VOID_P:
WTF?!?!?
Thanks, Richard
On Sun, Jun 12, 2022 at 1:03 PM Michal Schorm mschorm@redhat.com wrote:
Whether it's part of the same problem or not, the "-S ." seems to be causing issues for projects that "add_subdirectory()" other projects. Not everything is propagating into the sub-project.
ARG!
Thanks, Richard
On Mon, 2022-06-13 at 17:42 -0500, Richard Shaw wrote:
On Sun, Jun 12, 2022 at 1:03 PM Michal Schorm mschorm@redhat.com wrote:
Whether it's part of the same problem or not, the "-S ." seems to be causing issues for projects that "add_subdirectory()" other projects. Not everything is propagating into the sub-project.
Hi ,
please tell me what packages you need fix the cmake builds and I will try to fix it .
for reference here some possible fixes https://bugzilla.redhat.com/show_bug.cgi?id=2057738
Best regards
ARG!
Thanks, Richard _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Wed, Jun 15, 2022 at 5:24 PM Sérgio Basto sergio@serjux.com wrote:
On Mon, 2022-06-13 at 17:42 -0500, Richard Shaw wrote:
On Sun, Jun 12, 2022 at 1:03 PM Michal Schorm mschorm@redhat.com wrote:
See: https://bugzilla.redhat.com/show_bug.cgi?id=2079833
Whether it's part of the same problem or not, the "-S ." seems to be causing issues for projects that "add_subdirectory()" other projects. Not everything is propagating into the sub-project.
Hi ,
please tell me what packages you need fix the cmake builds and I will try to fix it .
Now I see the problem regardless of whether I use the "-S ." or "." at the end method... The strange part is with GNUInstallDirs. It should only emit that message if neither CMAKE_SYSTEM_NAME nor CMAKE_SIZEOF_VOIDP is defined, but clearly one of them is:
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:241 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMAKE_SYSTEM_NAME: Linux CMAKE_SIZEOF_VOID_P:
I'm working with it in a COPR currently so here's a link to the SRPM:
https://hobbes1069.fedorapeople.org/emqx-nanomq-0.8.0-1.fc35.src.rpm
Thanks, Richard
On Wed, 2022-06-15 at 20:28 -0500, Richard Shaw wrote:
On Wed, Jun 15, 2022 at 5:24 PM Sérgio Basto sergio@serjux.com wrote:
On Mon, 2022-06-13 at 17:42 -0500, Richard Shaw wrote:
On Sun, Jun 12, 2022 at 1:03 PM Michal Schorm mschorm@redhat.com wrote:
Whether it's part of the same problem or not, the "-S ." seems to be causing issues for projects that "add_subdirectory()" other projects. Not everything is propagating into the sub-project.
Hi ,
please tell me what packages you need fix the cmake builds and I will try to fix it .
Now I see the problem regardless of whether I use the "-S ." or "." at the end method... The strange part is with GNUInstallDirs. It should only emit that message if neither CMAKE_SYSTEM_NAME nor CMAKE_SIZEOF_VOIDP is defined, but clearly one of them is:
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:241 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMAKE_SYSTEM_NAME: Linux CMAKE_SIZEOF_VOID_P:
I'm working with it in a COPR currently so here's a link to the SRPM:
https://hobbes1069.fedorapeople.org/emqx-nanomq-0.8.0-1.fc35.src.rpm
Good , now to fix "relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE" you need patch attached
Now build ends with
/usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_Delete' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_PrintUnformatted' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_fini' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_AddStringToObject' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_auth_parser' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_auth_http_parse' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `nano_msg_set_dup' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_CreateObject'
Best regards,
On Thu, Jun 16, 2022 at 9:57 PM Sérgio Basto sergio@serjux.com wrote:
On Wed, 2022-06-15 at 20:28 -0500, Richard Shaw wrote:
On Wed, Jun 15, 2022 at 5:24 PM Sérgio Basto sergio@serjux.com wrote:
On Mon, 2022-06-13 at 17:42 -0500, Richard Shaw wrote:
On Sun, Jun 12, 2022 at 1:03 PM Michal Schorm mschorm@redhat.com wrote:
See: https://bugzilla.redhat.com/show_bug.cgi?id=2079833
Whether it's part of the same problem or not, the "-S ." seems to be causing issues for projects that "add_subdirectory()" other projects. Not everything is propagating into the sub-project.
Hi ,
please tell me what packages you need fix the cmake builds and I will try to fix it .
Now I see the problem regardless of whether I use the "-S ." or "." at the end method... The strange part is with GNUInstallDirs. It should only emit that message if neither CMAKE_SYSTEM_NAME nor CMAKE_SIZEOF_VOIDP is defined, but clearly one of them is:
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:241 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMAKE_SYSTEM_NAME: Linux CMAKE_SIZEOF_VOID_P:
I'm working with it in a COPR currently so here's a link to the SRPM:
https://hobbes1069.fedorapeople.org/emqx-nanomq-0.8.0-1.fc35.src.rpm
Good , now to fix "relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE" you need patch attached
Now build ends with
/usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_Delete' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_PrintUnformatted' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_fini' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_AddStringToObject' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_auth_parser' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_auth_http_parse' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `nano_msg_set_dup' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_CreateObject'
What did you change?
Now it looks like I'm back to where I was :) I added cjson to the BR's but it didn't work, but that's at least something I can troubleshoot without all the extra CMake issues.
Thanks, Richard
On Thu, 2022-06-16 at 22:02 -0500, Richard Shaw wrote:
On Thu, Jun 16, 2022 at 9:57 PM Sérgio Basto sergio@serjux.com wrote:
On Wed, 2022-06-15 at 20:28 -0500, Richard Shaw wrote:
On Wed, Jun 15, 2022 at 5:24 PM Sérgio Basto sergio@serjux.com wrote:
On Mon, 2022-06-13 at 17:42 -0500, Richard Shaw wrote:
On Sun, Jun 12, 2022 at 1:03 PM Michal Schorm mschorm@redhat.com wrote:
Whether it's part of the same problem or not, the "-S ." seems to be causing issues for projects that "add_subdirectory()" other projects. Not everything is propagating into the sub-project.
Hi ,
please tell me what packages you need fix the cmake builds and I will try to fix it .
Now I see the problem regardless of whether I use the "-S ." or "." at the end method... The strange part is with GNUInstallDirs. It should only emit that message if neither CMAKE_SYSTEM_NAME nor CMAKE_SIZEOF_VOIDP is defined, but clearly one of them is:
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:241 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMAKE_SYSTEM_NAME: Linux CMAKE_SIZEOF_VOID_P:
I'm working with it in a COPR currently so here's a link to the SRPM:
https://hobbes1069.fedorapeople.org/emqx-nanomq-0.8.0-1.fc35.src.rpm
Good , now to fix "relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE" you need patch attached
Now build ends with
/usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_Delete' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_PrintUnformatted' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_fini' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_AddStringToObject' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_auth_parser' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_auth_http_parse' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `nano_msg_set_dup' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_CreateObject'
What did you change?
I sent the patch in attachment
diff --git a/CMakeLists.txt b/CMakeLists.txt
-SET(CMAKE_C_FLAGS "-std=c99") -SET(CMAKE_CXX_FLAGS "-std=c++11 -O3")
diff --git a/nanolib/CMakeLists.txt.orig b/nanolib/CMakeLists.txt
-SET(CMAKE_C_FLAGS "-std=gnu99") -SET(CMAKE_CXX_FLAGS "-std=c++11 -O3")
you need not remove the default C_FLAGS and CXX_FLAGS
Now it looks like I'm back to where I was :) I added cjson to the BR's but it didn't work, but that's at least something I can troubleshoot without all the extra CMake issues.
Thanks, Richard _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Fri, Jun 17, 2022 at 8:49 AM Sérgio Basto sergio@serjux.com wrote:
On Thu, 2022-06-16 at 22:02 -0500, Richard Shaw wrote:
On Thu, Jun 16, 2022 at 9:57 PM Sérgio Basto sergio@serjux.com wrote:
On Wed, 2022-06-15 at 20:28 -0500, Richard Shaw wrote:
On Wed, Jun 15, 2022 at 5:24 PM Sérgio Basto sergio@serjux.com wrote:
On Mon, 2022-06-13 at 17:42 -0500, Richard Shaw wrote:
On Sun, Jun 12, 2022 at 1:03 PM Michal Schorm mschorm@redhat.com wrote:
See: https://bugzilla.redhat.com/show_bug.cgi?id=2079833
Whether it's part of the same problem or not, the "-S ." seems to be causing issues for projects that "add_subdirectory()" other projects. Not everything is propagating into the sub-project.
Hi ,
please tell me what packages you need fix the cmake builds and I will try to fix it .
Now I see the problem regardless of whether I use the "-S ." or "." at the end method... The strange part is with GNUInstallDirs. It should only emit that message if neither CMAKE_SYSTEM_NAME nor CMAKE_SIZEOF_VOIDP is defined, but clearly one of them is:
CMake Warning (dev) at /usr/share/cmake/Modules/GNUInstallDirs.cmake:241 (message): Unable to determine default CMAKE_INSTALL_LIBDIR directory because no target architecture is known. Please enable at least one language before including GNUInstallDirs. Call Stack (most recent call first): CMakeLists.txt:15 (include) This warning is for project developers. Use -Wno-dev to suppress it. CMAKE_SYSTEM_NAME: Linux CMAKE_SIZEOF_VOID_P:
I'm working with it in a COPR currently so here's a link to the SRPM:
https://hobbes1069.fedorapeople.org/emqx-nanomq-0.8.0-1.fc35.src.rpm
Good , now to fix "relocation R_X86_64_32 against `.rodata' can not be used when making a PIE object; recompile with -fPIE" you need patch attached
Now build ends with
/usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_Delete' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_PrintUnformatted' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_fini' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_AddStringToObject' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_auth_parser' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `conf_auth_http_parse' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `nano_msg_set_dup' /usr/bin/ld: ../../../libnng.so.1.6.0-pre: undefined reference to `cJSON_CreateObject'
What did you change?
I sent the patch in attachment
diff --git a/CMakeLists.txt b/CMakeLists.txt
-SET(CMAKE_C_FLAGS "-std=c99") -SET(CMAKE_CXX_FLAGS "-std=c++11 -O3")
diff --git a/nanolib/CMakeLists.txt.orig b/nanolib/CMakeLists.txt
-SET(CMAKE_C_FLAGS "-std=gnu99") -SET(CMAKE_CXX_FLAGS "-std=c++11 -O3")
you need not remove the default C_FLAGS and CXX_FLAGS
Whoops. Didn't see the patch. So I thought that setting the CMAKE_Cxxxx flags were still additive with the environment variables, I guess not.
Thanks! RIchard