with recent dbus-1.10 branch I get a build error with autotools cross compiling for windows: make[3]: Entering directory `/home/ralf.habacker/src/dbus-autotools-cross-build/test' ^ ../../dbus/test/test-utils-glib.c:454:3: warning: nested extern declaration of 'alarm' [-Wnested-externs] ../../dbus/test/test-utils-glib.c:458:14: error: variable 'act' has initializer but incomplete type struct sigaction act = { }; ^ ../../dbus/test/test-utils-glib.c:458:24: error: storage size of 'act' isn't known struct sigaction act = { }; ^ ../../dbus/test/test-utils-glib.c:462:7: warning: nested extern declaration of 'sigaction' [-Wnested-externs] ../../dbus/test/test-utils-glib.c:462:18: error: 'SIGALRM' undeclared (first use in this function) sigaction (SIGALRM, &act, NULL); ^ make[3]: *** [test-utils-glib.lo] Fehler 1 make[3]: Leaving directory `/home/ralf.habacker/src/dbus-autotools-cross-build/test' make[2]: *** [all-recursive] Fehler 1 make[2]: Leaving directory `/home/ralf.habacker/src/dbus-autotools-cross-build/test' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/home/ralf.habacker/src/dbus-autotools-cross-build' make: *** [all] Fehler 2 and with cmake In file included from /home/ralf.habacker/src/dbus/test/test-utils-glib.c:28:0: /home/ralf.habacker/src/dbus/test/test-utils-glib.h:32:18: fatal error: glib.h: No such file or directory compilation terminated. make[2]: *** [test/CMakeFiles/dbus-testutils-glib.dir/home/ralf.habacker/src/dbus/test/test-utils-glib.obj] Fehler 1 make[1]: *** [test/CMakeFiles/dbus-testutils-glib.dir/all] Fehler 2 make: *** [all] Fehler 2
(In reply to Ralf Habacker from comment #0) > ../../dbus/test/test-utils-glib.c:458:14: error: variable 'act' has > initializer but incomplete type > struct sigaction act = { }; That line is only compiled if DBUS_UNIX is defined, which it shouldn't be in a cross-build for Windows. How are you configuring your build tree and what configure output do you get? I configure with ${srcdir}/configure \ --enable-maintainer-mode --enable-developer \ --enable-installed-tests --enable-modular-tests --with-glib \ --build=x86_64-pc-linux-gnu --host=i686-w64-mingw32 \ --prefix=/opt/i686-w64-mingw32 \ LDFLAGS=-L/opt/i686-w64-mingw32/lib \ CPPFLAGS=-I/opt/i686-w64-mingw32/include \ CFLAGS=-static-libgcc \ PKG_CONFIG_LIBDIR=/opt/i686-w64-mingw32/lib/pkgconfig \ PKG_CONFIG_PATH= and that works. /opt/i686-w64-mingw32 has locally-installed copies of libffi, GLib, gettext, libintl, zlib and expat, and I'm using Debian's i686-w64-mingw32-gcc toolchain with the mingw-w64 runtime library headers.
(In reply to Simon McVittie from comment #1) > That line is only compiled if DBUS_UNIX is defined Sorry, no, G_OS_UNIX. I think your mistake is that you haven't told pkg-config to look in a mingw-specific directory, and it is finding an x86_64 version of GLib, which is not suitable for a cross-build. That's what PKG_CONFIG_LIBDIR=/opt/i686-w64-mingw32/lib/pkgconfig PKG_CONFIG_PATH= are for - the first one makes pkg-config look in my mingw prefix, and the second makes it not look anywhere else.
(In reply to Ralf Habacker from comment #0) > and with cmake ... > /home/ralf.habacker/src/dbus/test/test-utils-glib.h:32:18: fatal error: > glib.h: No such file or directory If you're compiling that file, then DBUS_WITH_GLIB must be defined, which means CMake thinks it has found GLib and GObject - but somehow GLIB2_INCLUDE_DIR and GOBJECT_INCLUDE_DIR aren't being found. Build with VERBOSE=1 to see whether the build system is supplying the right compiler command-line arguments.
(In reply to Simon McVittie from comment #2) > (In reply to Simon McVittie from comment #1) > > That line is only compiled if DBUS_UNIX is defined > > Sorry, no, G_OS_UNIX. > Got it. config.status included the following line: S["oldincludedir"]="/usr/include" I remember to configured the build dir correctly several weeks ago and did several correct builds from that, but was told few days ago to rerun autogen.sh from the source dir (It may be caused by a autotools package update or git checkout -f <dbus-source-dir>). After that I got this errors.
(In reply to Ralf Habacker from comment #4) > (In reply to Simon McVittie from comment #2) > > (In reply to Simon McVittie from comment #1) > > > That line is only compiled if DBUS_UNIX is defined > > > > Sorry, no, G_OS_UNIX. > > > Got it. config.status included the following line: > S["oldincludedir"]="/usr/include" > > I remember to configured the build dir correctly several weeks ago and did > several correct builds from that, but was told few days ago to rerun > autogen.sh from the source dir (It may be caused by a autotools package > update or git checkout -f <dbus-source-dir>). After that I got this errors. I had another autotools cross build dir, in with running make automatically reruns autogen.sh. After it finished config.status includes the mentioned linux host include path and lead to the build issues.
(In reply to Ralf Habacker from comment #5) > (In reply to Ralf Habacker from comment #4) > > (In reply to Simon McVittie from comment #2) > > > (In reply to Simon McVittie from comment #1) > > > > That line is only compiled if DBUS_UNIX is defined > > > > > > Sorry, no, G_OS_UNIX. > > > > > Got it. config.status included the following line: > > S["oldincludedir"]="/usr/include" > > > > I remember to configured the build dir correctly several weeks ago and did > > several correct builds from that, but was told few days ago to rerun > > autogen.sh from the source dir (It may be caused by a autotools package > > update or git checkout -f <dbus-source-dir>). After that I got this errors. > > I had another autotools cross build dir, in with running make automatically > reruns autogen.sh. After it finished config.status includes the mentioned > linux host include path and lead to the build issues. (In reply to Simon McVittie from comment #1) > (In reply to Ralf Habacker from comment #0) > > ../../dbus/test/test-utils-glib.c:458:14: error: variable 'act' has > > initializer but incomplete type > > struct sigaction act = { }; > > That line is only compiled if DBUS_UNIX is defined, which it shouldn't be in > a cross-build for Windows. How are you configuring your build tree and what > configure output do you get? > > I configure with > > ${srcdir}/configure \ > --enable-maintainer-mode --enable-developer \ > --enable-installed-tests --enable-modular-tests --with-glib \ > --build=x86_64-pc-linux-gnu --host=i686-w64-mingw32 \ > --prefix=/opt/i686-w64-mingw32 \ > LDFLAGS=-L/opt/i686-w64-mingw32/lib \ > CPPFLAGS=-I/opt/i686-w64-mingw32/include \ > CFLAGS=-static-libgcc \ > PKG_CONFIG_LIBDIR=/opt/i686-w64-mingw32/lib/pkgconfig \ > PKG_CONFIG_PATH= > > and that works. /opt/i686-w64-mingw32 has locally-installed copies of > libffi, GLib, gettext, libintl, zlib and expat, and I'm using Debian's > i686-w64-mingw32-gcc toolchain with the mingw-w64 runtime library headers. On opensuse the directory layout is different mingw32 is installed in /usr/i686-w64-mingw32/sys-root/mingw From the obs build https://build.opensuse.org/build/home:rhabacker:branches:windows:mingw:win32/openSUSE_13.2/x86_64/mingw32-dbus-1/_log I extraced the related environment vars and command line to build CLASSPATH=:/usr/i686-w64-mingw32/sys-root/mingw/share/java/libgcj.jar:/usr/i686-w64-mingw32/sys-root/mingw/share/java/libgcj-tools.jar \ PKG_CONFIG_PATH=/usr/i686-w64-mingw32/sys-root/mingw/lib/pkgconfig:/usr/i686-w64-mingw32/sys-root/mingw/share/pkgconfig \ CXX=i686-w64-mingw32-g++ \ CXXFLAGS='-O2 -g -pipe -Wall -fexceptions --param=ssp-buffer-size=4 -mms-bitfields' \ WINDRES=/usr/bin/i686-w64-mingw32-windres CC=i686-w64-mingw32-gcc \ CFLAGS='-O2 -g -pipe -Wall -fexceptions --param=ssp-buffer-size=4 -mms-bitfields' \ LDFLAGS='-Wl,--exclude-libs=libintl.a -Wl,--exclude-libs=libiconv.a -Wl,--no-keep-memory' \ PKG_CONFIG=/usr/bin/i686-w64-mingw32-pkg-config ../dbus-1/configure --cache-file=mingw32-config.cache --host=i686-w64-mingw32 --build=x86_64-suse-linux-gnu --target=i686-w64-mingw32 --prefix=/usr/i686-w64-mingw32/sys-root/mingw --exec-prefix=/usr/i686-w64-mingw32/sys-root/mingw --bindir=/usr/i686-w64-mingw32/sys-root/mingw/bin --sbindir=/usr/i686-w64-mingw32/sys-root/mingw/sbin --sysconfdir=/usr/i686-w64-mingw32/sys-root/mingw/etc --datadir=/usr/i686-w64-mingw32/sys-root/mingw/share --includedir=/usr/i686-w64-mingw32/sys-root/mingw/include --libdir=/usr/i686-w64-mingw32/sys-root/mingw/lib --libexecdir=/usr/i686-w64-mingw32/sys-root/mingw/libexec --localstatedir=/usr/i686-w64-mingw32/sys-root/mingw/var --sharedstatedir=/usr/i686-w64-mingw32/sys-root/mingw/com --mandir=/usr/i686-w64-mingw32/sys-root/mingw/share/man --infodir=/usr/i686-w64-mingw32/sys-root/mingw/share/info --enable-maintainer-mode --disable-static --enable-verbose-mode --enable-embedded-tests --enable-checks --enable-asserts --disable-xml-docs --disable-doxygen-docs After that I still need to remove the /usr/include from the generated config.status to avoid the compile issue. ralf.habacker@blendertest:~/src/dbus-1-autotools-cross-build> grep -n /usr/include config.status 1233:S["oldincludedir"]="/usr/include"
(In reply to Ralf Habacker from comment #6) > After that I still need to remove the /usr/include from the generated > config.status to avoid the compile issue. This surprises me. In my mingw builddir, I do get S["oldincludedir"]="/usr/include" in config.status, and various mentions in Makefile.in such as bus/Makefile.in 549:oldincludedir = @oldincludedir@ but nothing actually dereferences that variable. In particular, I don't see "-I$(oldincludedir)" anywhere. You could try adding --oldincludedir='${includedir}' (with the quoting) to your configure command line? But I still don't know why the oldincludedir would be causing problems for you - nothing in dbus explicitly uses it, and I don't think anything in the Autotools toolchain implicitly uses it with -I either.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus/issues/132.
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.