Created attachment 116101 [details] [review] No need to link against librt on QNX Small changes to CMakeFiles to allow for cross-compilation on QNX. Please bear with me if the patches don't look fine to you, I will be more than happy to fix and adjust them accordingly. Also, I am wondering if I should care to test non-cmake builds, too. What do you think? And last, but not least - should I also attach the QNX 6.6.0 Toolchain file? Thank you for reviewing this. Rafael
Created attachment 116102 [details] [review] QNX export socket api symbols thru libsocket
Created attachment 116103 [details] Toolchain file for QNX Please disregard if this is out of scope.
Comment on attachment 116101 [details] [review] No need to link against librt on QNX Review of attachment 116101 [details] [review]: ----------------------------------------------------------------- Looks good, but is it complete? Please either apply the same modification to the autotools files or write in the commit message that it's already ok.
Comment on attachment 116102 [details] [review] QNX export socket api symbols thru libsocket Review of attachment 116102 [details] [review]: ----------------------------------------------------------------- Looks good, but same comment as the other patch: autotools files.
(In reply to Rafael Roquetto from comment #0) > Small changes to CMakeFiles to allow for cross-compilation on QNX. Why are you using the CMake build system on QNX? The Autotools build system is the one I would recommend for any Unixish platform. Autotools cross-compilation is well-understood, e.g. <https://developer.blackberry.com/playbook/native/documentation/porting_getting_started.html> describes ./configure --build=i686-pc-linux --host=arm-unknown-nto-qnx6.5.0eabi (plus whatever command-line options are necessary for your intended use of D-Bus, which normally includes --prefix=/usr --sysconfdir=/etc --localstatedir=/var). The major reason why we have a CMake build system at all is because (some) developers on Windows prefer to compile and debug with Microsoft Visual C++, which is not command-line-compatible with the Unix-style C compilers (gcc, clang, icc etc.) that are assumed by Autotools. The CMake build system does work to at least some extent on Unix, but that's mainly so that I can run its tests on Linux to check that I haven't broken it too badly. Unless there is a strong reason to prefer CMake over Autotools for a particular other Unix platform (QNX, *BSD, etc.), I would rather not go to any particular lengths to support them in CMake. I hope you can see why adding special cases for QNX, special cases for FreeBSD, special cases for Solaris and so on doesn't really scale very well. Autotools solves this by preferring to test for features, not OSs: AC_SEARCH_LIBS(socket,[socket network]) ... AC_SEARCH_LIBS([clock_getres], [rt], [THREAD_LIBS="$LIBS"]) and if you must use CMake on QNX for whatever reason, I would prefer a more feature-based approach in general - think "special case for platforms where -lsocket is needed" rather than "special case for QNX".
(In reply to Simon McVittie from comment #5) > The major reason why we have a CMake build system at all is because (some) > developers on Windows prefer to compile and debug with Microsoft Visual C++, > which is not command-line-compatible with the Unix-style C compilers (gcc, > clang, icc etc.) that are assumed by Autotools. The second reason is that KDE on Windows uses cmake to build dbus regardless of the compiler.
(In reply to Simon McVittie from comment #5) > (In reply to Rafael Roquetto from comment #0) > > Small changes to CMakeFiles to allow for cross-compilation on QNX. > > Why are you using the CMake build system on QNX? Because we need to cross-compile it from Windows hosts, in a scripted way, and we cannot rely on an autotools environment for that. > > The Autotools build system is the one I would recommend for any Unixish > platform. Autotools cross-compilation is well-understood, e.g. > <https://developer.blackberry.com/playbook/native/documentation/ > porting_getting_started.html> describes > > ./configure --build=i686-pc-linux --host=arm-unknown-nto-qnx6.5.0eabi > > (plus whatever command-line options are necessary for your intended use of > D-Bus, which normally includes --prefix=/usr --sysconfdir=/etc > --localstatedir=/var). I am actually struggling to build DBUS using autotools on the Linux box. See https://paste.kde.org/p1uvfu2qa#line-5 - the problem is that it is trying to load my host system's sys/types.h and not the one from the QNX SDP, and that messes up with the value of _XOPEN_SOURCE. I have tried several different approaches, including --sysroot and -isysroot without any success. Any clues? > > The major reason why we have a CMake build system at all is because (some) > developers on Windows prefer to compile and debug with Microsoft Visual C++, > which is not command-line-compatible with the Unix-style C compilers (gcc, > clang, icc etc.) that are assumed by Autotools. > > The CMake build system does work to at least some extent on Unix, but that's > mainly so that I can run its tests on Linux to check that I haven't broken > it too badly. Unless there is a strong reason to prefer CMake over Autotools > for a particular other Unix platform (QNX, *BSD, etc.), I would rather not > go to any particular lengths to support them in CMake. I understand, that sounds perfectly reasonable to me. > > I hope you can see why adding special cases for QNX, special cases for > FreeBSD, special cases for Solaris and so on doesn't really scale very well. > Autotools solves this by preferring to test for features, not OSs: > > AC_SEARCH_LIBS(socket,[socket network]) > ... > AC_SEARCH_LIBS([clock_getres], [rt], [THREAD_LIBS="$LIBS"]) > > and if you must use CMake on QNX for whatever reason, I would prefer a more > feature-based approach in general - think "special case for platforms where > -lsocket is needed" rather than "special case for QNX". I agree - althought I cannot think of any other platform but QNX where -lsocket is required. I guess QNX is a special case on its own. In any case, I am happy to try to bring DBUS to QNX via autotools. I just need to manage to build it. And regardless of that, we still need the CMake changes for Windows, although I understand it if you don't want to have those merged.
(In reply to Thiago Macieira from comment #3) > Comment on attachment 116101 [details] [review] [review] > No need to link against librt on QNX > > Review of attachment 116101 [details] [review] [review]: > ----------------------------------------------------------------- > > Looks good, but is it complete? Please either apply the same modification to > the autotools files or write in the commit message that it's already ok. Will do it as soon as I manage to build it with autotools - thank you for reviewing it.
(In reply to Rafael Roquetto from comment #7) > (In reply to Simon McVittie from comment #5) > > Why are you using the CMake build system on QNX? > > Because we need to cross-compile it from Windows hosts, in a scripted way, > and we cannot rely on an autotools environment for that. In that case I'd be prepared to consider QNX patches to the CMake build system, but I would much prefer them to be "feature-based" not "OS-based": ideally think "special case for OSs where -lsocket is needed", "special case for QNX". I don't know precisely how to spell it in CMake syntax, but if you can do something like this pseudocode: set(PLATFORM_LIBS "") if (-lrt is needed for clock_getres()) { # true on Linux, false on QNX set(PLATFORM_LIBS "${PLATFORM_LIBS} rt") } if (-lsocket is needed for socket() or something) { # false on Linux, true on QNX set(PLATFORM_LIBS "${PLATFORM_LIBS} socket") } target_link_libraries(whatever-target ${PLATFORM_LIBS}) then that would be better. I don't know the CMake equivalent of AC_SEARCH_LIBS, but presumably it has one... If you do need to do anything OS-specific because you cannot detect a particular feature, it should look something like this pseudocode: if (unusual platform 1) { # this platform needs foo instead of bar set(special_thing foo) } else if (unusual platform 2) { # this platform is unusual in that neither foo nor bar is needed, # don't do anything special } else { # most platforms need bar set(special_thing bar) } where the "else" is the case that is expected to cover the majority of Unix platforms (Linux, *BSD, Solaris etc.) - some properties of Linux are unusual Linuxisms, whereas some are common to most Unixes. Windows counts as an unusual platform here, since its behaviour is typically not the same as any Unix. > I am actually struggling to build DBUS using autotools on the Linux box. See > https://paste.kde.org/p1uvfu2qa#line-5 - the problem is that it is trying to > load my host system's sys/types.h and not the one from the QNX SDP, and that > messes up with the value of _XOPEN_SOURCE. I have tried several different > approaches, including --sysroot and -isysroot without any success. Any clues? You certainly need some sort of sysroot, but I don't know a great deal about sysroot-based cross-compiling. I do know that it can be done - Matt Fischer had it working, according to Bug #61176. I would guess that you might be picking up -I/usr/include from something found on the host system via pkg-config. Read the pkg-config man page, then set the PKG_CONFIG_SYSROOT_DIR and/or PKG_CONFIG_LIBDIR environment variables. Also check that PKG_CONFIG_PATH is unset, or set to an appropriate value. You might want to create a shell script named arm-unknown-nto-qnx6.5.0eabi-pkg-config (or whatever GNU tuple you passed to --host=) that sets these environment variables to the right values and then execs pkg-config "$@", and put that on your PATH. I don't know where -D_XOPEN_SOURCE=600 is coming from. dbus' only mention of _XOPEN_SOURCE seems to be to set it to 500 on Solaris. We are unlikely to be able to provide further assistance without seeing what configure arguments and environment variables you are using, for instance the result of running "./config.status --version" in the build directory.
(In reply to Simon McVittie from comment #9) > In that case I'd be prepared to consider QNX patches to the CMake build > system, but I would much prefer them to be "feature-based" not "OS-based": > ideally think "special case for OSs where -lsocket is needed", "special case > for QNX". Er, there was a missing "not" there. That should say: think "special case for OSs where -lsocket is needed", not "special case for QNX". (Yes, this means that Linux also becomes a special case, because it's part of "OSs where -lrt is needed". That's OK.)
(In reply to Simon McVittie from comment #9) > I don't know the CMake equivalent of AC_SEARCH_LIBS, but presumably it has one... find_library for custom libraries (http://www.cmake.org/cmake/help/v3.0/command/find_library.html) or find_package for predefined external projects/libraries (http://www.cmake.org/cmake/help/v3.0/command/find_package.html) for example find_package(LibIconv), which could be found in the top level CMakeLists in dbus/cmake
Created attachment 116434 [details] [review] Changes to enable autotools compilation on QNX
I have added the relevant patch to be able to build it with autotools - the problem is that it was detecting my X11 on the host computer and messing up with the include paths. I am now going to give some thought on the CMake stuff as you suggested.
Comment on attachment 116434 [details] [review] Changes to enable autotools compilation on QNX Review of attachment 116434 [details] [review]: ----------------------------------------------------------------- ::: configure.ac @@ +1309,4 @@ > else > AC_PATH_XTRA > > + if test "x$enable_x" = xno; then No, this would break --without-x (which sets $no_x). If AC_PATH_XTRA is misbehaving in your environment, then it might be an Autoconf bug in that macro. In any case, please configure --without-x instead of patching in special cases. @@ +1355,4 @@ > dnl - we're not on Windows (too many warnings), and > dnl - we're in developer mode (a D-Bus developer, not a distro or end-user) > dnl Override with --enable-Werror or --disable-Werror > + [test x$dbus_win != xyes -a x$dbus_cygwin != xyes -a x$enable_developer = xyes -a x$dbus_qnx != xyes], Please configure with --disable-Werror, or fix the warnings, or at least *report* the warnings. Sorry, I'm not going to do anything about compiler warnings if you don't tell me what the specific warnings are...
(In reply to Rafael Roquetto from comment #0) > Created attachment 116101 [details] [review] [review] > No need to link against librt on QNX > > Small changes to CMakeFiles to allow for cross-compilation on QNX. Please > bear with me if the patches don't look fine to you, I will be more than > happy to fix and adjust them accordingly. > > Also, I am wondering if I should care to test non-cmake builds, too. What do > you think? > > And last, but not least - should I also attach the QNX 6.6.0 Toolchain file? > > Thank you for reviewing this. > > Rafael (In reply to Simon McVittie from comment #14) > Comment on attachment 116434 [details] [review] [review] > Changes to enable autotools compilation on QNX > > Review of attachment 116434 [details] [review] [review]: > ----------------------------------------------------------------- > > ::: configure.ac > @@ +1309,4 @@ > > else > > AC_PATH_XTRA > > > > + if test "x$enable_x" = xno; then > > No, this would break --without-x (which sets $no_x). > > If AC_PATH_XTRA is misbehaving in your environment, then it might be an > Autoconf bug in that macro. In any case, please configure --without-x > instead of patching in special cases. > > @@ +1355,4 @@ > > dnl - we're not on Windows (too many warnings), and > > dnl - we're in developer mode (a D-Bus developer, not a distro or end-user) > > dnl Override with --enable-Werror or --disable-Werror > > + [test x$dbus_win != xyes -a x$dbus_cygwin != xyes -a x$enable_developer = xyes -a x$dbus_qnx != xyes], > > Please configure with --disable-Werror, or fix the warnings, or at least > *report* the warnings. > > Sorry, I'm not going to do anything about compiler warnings if you don't > tell me what the specific warnings are... Of course, make sense. Anyway, those switches work, thank you for that, so no need for the patch. As for the warning, it is bascailly dbus-run-session.c:188: error: missing sentinel in function call [-Werror=format] Thank you again for your patience and for your feedback.
(In reply to Rafael Roquetto from comment #15) > As for the warning, it is bascailly dbus-run-session.c:188: error: missing > sentinel in function call [-Werror=format] That seems like a false positive: execlp (dbus_daemon, dbus_daemon, "--nofork", "--print-address", write_address_fd_as_string, config_file ? "--config-file" : "--session", config_file, /* has to be last in this varargs list */ NULL); ... we pass an explicit NULL terminator. config_file may also be NULL, which might be what is confusing your compiler? It probably isn't expecting execlp (..., "--session", NULL, NULL). As far as I know this is valid (has defined behaviour) in any Standard C compiler, though. What compiler is this? Some old gcc version?
(In reply to Simon McVittie from comment #16) > (In reply to Rafael Roquetto from comment #15) > > As for the warning, it is bascailly dbus-run-session.c:188: error: missing > > sentinel in function call [-Werror=format] > > That seems like a false positive: > > execlp (dbus_daemon, > dbus_daemon, > "--nofork", > "--print-address", write_address_fd_as_string, > config_file ? "--config-file" : "--session", > config_file, /* has to be last in this varargs list */ > NULL); > > ... we pass an explicit NULL terminator. > > config_file may also be NULL, which might be what is confusing your > compiler? It probably isn't expecting execlp (..., "--session", NULL, NULL). > As far as I know this is valid (has defined behaviour) in any Standard C > compiler, though. > > What compiler is this? Some old gcc version? This is QNX's own QCC, which is based on GCC 4.7.3 - it might be indeed just a QNX side-effect then, no problem.
(In reply to Ralf Habacker from comment #11) > (In reply to Simon McVittie from comment #9) > > > I don't know the CMake equivalent of AC_SEARCH_LIBS, but presumably it has one... > > find_library for custom libraries > (http://www.cmake.org/cmake/help/v3.0/command/find_library.html) So I was fiddling with find_library, but there is a little problem: QNX stores its /lib/ dir per architecture, i.e. libsocket exists inside $QNX_TARGET/{armle-v7,x86}/lib First, I assume hardcoding such PATHS on CMakeLists.txt is not elegant at all. Second, how to tell CMake which architecture version for libsocket to use, without adding any extra external variables for QNX? (non-rhetorical question here). If we add QNX-only variables, then we meet the QNX-specificness problem again. And in that case, I suppose the current patch does a better job, since it lets the compiler automatically pick the right architecture. Any ideas? Thanks, Rafael > > or find_package for predefined external projects/libraries > (http://www.cmake.org/cmake/help/v3.0/command/find_package.html) for example > find_package(LibIconv), which could be found in the top level CMakeLists in > dbus/cmake
(In reply to Rafael Roquetto from comment #18) > So I was fiddling with find_library, but there is a little problem: QNX > stores its /lib/ dir per architecture, i.e. libsocket exists inside > $QNX_TARGET/{armle-v7,x86}/lib > > First, I assume hardcoding such PATHS on CMakeLists.txt is not elegant at > all. Second, how to tell CMake which architecture version for libsocket to > use, without adding any extra external variables for QNX? (non-rhetorical > question here). Debian does that too. How does Debian cope? My guess is that if you're cross-compiling to a Debian system, then GCC is configured to search for the libs in that subdir on its own. I'd guess that QCC does the same. In other words, how do you cross compile a helloworld? qcc [some flags] helloworld.c What are [some flags]? Those should be passed by the user in CFLAGS to autoconf and whatever mechanism is appropriate for CMake. If CMake doesn't support it, CMake needs to be fixed. > If we add QNX-only variables, then we meet the QNX-specificness problem > again. And in that case, I suppose the current patch does a better job, > since it lets the compiler automatically pick the right architecture. > > Any ideas? I don't see why they need to be QNX-specific. CFLAGS should be enough.
(In reply to Thiago Macieira from comment #19) > Debian does that too. How does Debian cope? Debian's linker has /usr/lib/x86_64-linux-gnu (or whatever is the appropriate path for the CPU) in its default search path, just like Red Hat's x86_64 linker has /usr/lib64 in its default search path. Compilers with the correct default search path considered useful :-) > I don't see why they need to be QNX-specific. CFLAGS should be enough. I assume you mean LDFLAGS if they are to affect the linker, but yes. According to http://www.cmake.org/cmake/help/v3.0/command/find_library.html, CMake has CMAKE_FIND_ROOT_PATH, CMAKE_LIBRARY_PATH, CMAKE_SYSTEM_LIBRARY_PATH and CMAKE_SYSROOT which all look like part of the puzzle. (In reply to Rafael Roquetto from comment #0) > And last, but not least - should I also attach the QNX 6.6.0 Toolchain file? You can attach it if you want, but we will not merge it, because as far as I understand it, CMake toolchain files are specific to your particular installation and toolchain, and are independent of what you're compiling.
(In reply to Thiago Macieira from comment #19) > (In reply to Rafael Roquetto from comment #18) > > So I was fiddling with find_library, but there is a little problem: QNX > > stores its /lib/ dir per architecture, i.e. libsocket exists inside > > $QNX_TARGET/{armle-v7,x86}/lib > > > > First, I assume hardcoding such PATHS on CMakeLists.txt is not elegant at > > all. Second, how to tell CMake which architecture version for libsocket to > > use, without adding any extra external variables for QNX? (non-rhetorical > > question here). > > Debian does that too. How does Debian cope? > > My guess is that if you're cross-compiling to a Debian system, then GCC is > configured to search for the libs in that subdir on its own. I'd guess that > QCC does the same. Cross compiling with cmake is documentated at http://www.vtk.org/Wiki/CMake_Cross_Compiling At https://trac.lcsr.jhu.edu/cisst/wiki/qnx#no1 there are some cmake toolchain files for QNX. Not sure, if they are usable.
(In reply to Simon McVittie from comment #5) > if you must use CMake on QNX for whatever reason, I would prefer a more > feature-based approach in general - think "special case for platforms where > -lsocket is needed" rather than "special case for QNX". See also Bug #94096, which is the same thing for Android, which also doesn't want -lrt.
Ralf has fixed the -lrt and -lsocket issues in the way I requested on Bug #94096 (patches not yet applied, but I reviewed them and they look good). *** This bug has been marked as a duplicate of bug 94096 ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.