Cannot build dbus with clang about llvm-mingw

[mstorsjo]

Will have a try later. Any particular configure options you used, and does it depend on other libraries?

[mstorsjo]

Works for me, in a clean cross environment, with libexpat built with the same toolchain right before.

[mathias-freire]

Configure options I used:

LDFLAGS="-L$PREF/evince/lib -lexpat -lc++ -Wl,/force:multiple" CC=$MHOST-clang CXX=$MHOST-clang++ AR=llvm-ar NM=llvm-nm RANLIB=llvm-ranlib ./configure --prefix=$PREF/evince --build=$MHOST --enable-shared --disable-static --disable-systemd --disable-tests

[mstorsjo]

Sorry, can't reproduce it with those flags either. You'll have to dive in and debug it yourself.

*** Warning: This system cannot link to static lib archive libdbus-1.la.
*** I have the capability to make that library automatically link in when
*** you link to this library.  But I can only do this if you have a
*** shared version of the library, which you do not appear to have.

This makes it sound like the library it's built is static, even though you're building shared. This could be stemming from building in an unclean directory.

[mathias-freire]

I noticed some flaws in build. Linkin errors are rooting from symbol uncompatibility. When I examine the static library libdbus-1.a, I encounter strange things. For example, one of the linking errors is:

lld-link: error: undefined symbol: __imp_dbus_connection_close
>>> referenced by libdbus-daemon-internal.a(bus.o):(bus_context_add_incoming_connection)
>>> referenced by libdbus-daemon-internal.a(connection.o):(bus_connections_unref)
>>> referenced by libdbus-daemon-internal.a(connection.o):(bus_connections_unref)
>>> referenced by libdbus-daemon-internal.a(connection.o):(pending_unix_fds_timeout_cb)
>>> referenced by libdbus-daemon-internal.a(connection.o):(bus_connections_expire_incomplete)
>>> referenced by libdbus-daemon-internal.a(dispatch.o):(bus_dispatch_message_filter)
>>> referenced by libdbus-daemon-internal.a(dispatch.o):(bus_dispatch_message_filter)

When I write this, I get nothing:

llvm-nm dbus/.libs/libdbus-1.a | grep __imp_dbus_connection_close

But when I try without "_imp", I get something:

llvm-nm dbus/.libs/libdbus-1.a | grep dbus_connection_close
         U _dbus_connection_close_possibly_shared
000011d0 T _dbus_connection_close_if_only_one_ref
00001060 T _dbus_connection_close_possibly_shared
00001e00 T dbus_connection_close
         U _dbus_connection_close_if_only_one_ref

What does it mean and what causes this?

[mathias-freire]

Btw, the latest development release, 1.13.12 has cmake build system. By configuring those arguments:

LDFLAGS="-L$PREF/evince/lib -lexpat -lc++ -Wl,/force:multiple" CC=$MHOST-clang CXX=$MHOST-clang++ AR=llvm-ar NM=llvm-nm RANLIB=llvm-ranlib cmake .. -G "Ninja" -DCMAKE_INSTALL_PREFIX=$PREF/evince -DCMAKE_BUILD_TYPE=Release -DCMAKE_AR=/d/mingw-llvm/bin/llvm-ar.exe -DCMAKE_RANLIB=/d/mingw-llvm/bin/llvm-ranlib.exe -DZLIB_LIBRARY_RELEASE=/d/minpref/evince/lib/libz.dll.a -DBUILD_SHARED_LIBS=ON -DDBUS_BUILD_TESTS=OFF -DDBUS_ENABLE_VERBOSE_MODE=OFF -DDBUS_WITH_GLIB=OFF -DDBUS_ENABLE_XML_DOCS=OFF

I'm getting this:

FAILED: bin/dbus-update-activation-environment.exe
cmd.exe /C "cd . && D:\mingw-llvm\bin\x86_64-w64-mingw32-clang.exe -O2 -I/d/minpref/evince/include  -Wsign-compare -O3 -DNDEBUG  -LD:/minpref/evince/lib -lexpat -lc++ -Wl,/force:multiple tools/CMakeFiles/dbus-update-activation-environment.dir/dbus-update-activation-environment.c.obj tools/CMakeFiles/dbus-update-activation-environment.dir/tool-common.c.obj tools/CMakeFiles/dbus-update-activation-environment.dir/versioninfo-dbus-update-activation-environment.rc.obj tools/CMakeFiles/dbus-update-activation-environment.dir/__/disable-uac.rc.obj  -o bin\dbus-update-activation-environment.exe -Wl,--out-implib,lib\libdbus-update-activation-environment.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -LD:/evince/dbus-1.13.12/bld/bin lib/libdbus-1.dll.a -lws2_32 -ladvapi32 -lnetapi32 -liphlpapi -ldbghelp -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ."
lld-link: error: tools/CMakeFiles/dbus-update-activation-environment.dir/__/disable-uac.rc.obj: more than one resource obj file not allowed, already got tools/CMakeFiles/dbus-update-activation-environment.dir/versioninfo-dbus-update-activation-environment.rc.obj

[mstorsjo]

lld-link: error: undefined symbol: __imp_dbus_connection_close
What does it mean and what causes this?

If the calling code (in e.g. libdbus-daemon-internal.a(bus.o)) saw a declaration of dbus_connection_close with the dllimport attribute, then it will make references to the symbol __imp_dbus_connection_close instead of dbus_connection_close, and then you can only link it against the DLL's import libraries which contains these symbols. So this sounds like something in your build is mismatched (maybe you have other dbus headers installed somewhere, with dllimport declarations, which happen to be used instead of the ones for your current build?).

lld-link: error: tools/CMakeFiles/dbus-update-activation-environment.dir/__/disable-uac.rc.obj: more than one resource obj file not allowed, already got tools/CMakeFiles/dbus-update-activation-environment.dir/versioninfo-dbus-update-activation-environment.rc.obj

Linking more than one resource object into the same exe/dll is implemented in the very latest version of lld (committed to trunk in the last few days). Apparently this issue, multiple resource object files, only happens when building dbus with cmake instead of autotools.

[mstorsjo]

The issue with linking multiple resource objects should have been resolved since a couple releases, so closing this one for now.