Bug 33973 - static-only autotools build on Windows fails unless you define DBUS_STATIC_BUILD
Summary: static-only autotools build on Windows fails unless you define DBUS_STATIC_BUILD
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: core (show other bugs)
Version: 1.4.x
Hardware: All Windows (All)
: medium normal
Assignee: Simon McVittie
QA Contact: John (J5) Palmieri
URL:
Whiteboard: review?
Keywords: patch
: 46366 46367 (view as bug list)
Depends on:
Blocks: dbus-1.5
  Show dependency treegraph
 
Reported: 2011-02-06 14:53 UTC by René Berber
Modified: 2012-06-15 07:23 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments
When not producing a dynamic library, define DBUS_STATIC_BUILD (3.72 KB, patch)
2012-03-12 07:33 UTC, Simon McVittie
Details | Splinter Review

Description René Berber 2011-02-06 14:53:52 UTC
On versions 1.4.1 and 1.4.3 using ./configure ... --enable-static --disable-shared ... fails unless you also use CFLAGS=-DDBUS_STATIC_BUILD.

The failure shows at this point:

  CCLD   dbus-send.exe
dbus-print-message.o: In function `print_hex':
/home/rberber/mingw/dbus/tools/dbus-print-message.c:66: undefined reference to `__imp__dbus_message_iter_get_arg_type'
...
... many other similar messages referencing dynamic library items.
...
collect2: ld returned 1 exit status
make[2]: *** [dbus-send.exe] Error 1
make[2]: Leaving directory `/export/home/rberber/mingw-cross-env/dbus/tools'
Comment 1 Simon McVittie 2011-02-23 08:54:02 UTC
I believe this is a Windows-specific consequence of how PE imports work; ELF systems don't have this problem.
Comment 2 René Berber 2011-02-23 08:58:38 UTC
(In reply to comment #1)
> I believe this is a Windows-specific consequence of how PE imports work; ELF
> systems don't have this problem.

You are missing the point, the Makefiles are not propagating the DBUS_STATIC_BUILD.

And yes, that only affects the macros defined in the Windows header files that define symbol export.
Comment 3 Ralf Habacker 2011-11-17 06:53:42 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I believe this is a Windows-specific consequence of how PE imports work; ELF
> > systems don't have this problem.
> 
> You are missing the point, the Makefiles are not propagating the
> DBUS_STATIC_BUILD.
> 
> And yes, that only affects the macros defined in the Windows header files that
> define symbol export.

How would a related fix looks like ? Something like 

AC_SUBST(DBUS_STATIC_BUILD)

or is there more required ? 

Having a path will increase the chance to get this into git.
Comment 4 Simon McVittie 2011-11-17 07:17:04 UTC
It'd have to be something like this in configure.ac (untested, but could work):

    if test "x$enable_shared" = xno; then
        AC_DEFINE([DBUS_STATIC_BUILD], [1],
            [Define to 1 if you are only building static libraries])
    fi

The CMake build system might need something equivalent, but I don't speak fluent cmake.

If you've built both shared and static libraries, and you want to link against the static libraries, you'll still have to define DBUS_STATIC_BUILD yourself. I recommend using shared libraries for everything, unless there's a compelling reason not to.
Comment 5 Simon McVittie 2012-02-21 01:35:41 UTC
*** Bug 46367 has been marked as a duplicate of this bug. ***
Comment 6 Simon McVittie 2012-02-21 01:42:50 UTC
Bug 46367 is a duplicate of this. The workaround is:

(In reply to comment #0)
> using ./configure ... --enable-static
> --disable-shared ... fails unless you also use CFLAGS=-DDBUS_STATIC_BUILD.

Background information: the autotools build system normally compiles shared *and* static libraries. On Unix, this is fine, because the headers are the same; but on Windows, one or the other will need a special cpp definition, because they have to have different (semantics in the) headers (with/without __declspec annotations). This seems to be unavoidable unless you maintain a separate .def file listing public symbols. We've chosen to make the shared-library version "the default", so you have to define DBUS_STATIC_BUILD for the static-library version.

Comment #4 explains how someone could get this done automatically on static-only builds, if there's interest; I recommend using shared libraries and I don't develop on Windows, so I'm not going to work on this myself, but I'd review a patch.
Comment 7 Simon McVittie 2012-02-21 07:11:47 UTC
*** Bug 46366 has been marked as a duplicate of this bug. ***
Comment 8 Simon McVittie 2012-03-12 07:14:26 UTC
*** Bug 46367 has been marked as a duplicate of this bug. ***
Comment 9 Simon McVittie 2012-03-12 07:33:14 UTC
Created attachment 58319 [details] [review]
When not producing a dynamic library, define  DBUS_STATIC_BUILD

When targeting Windows, linking against the static library requires
special effort to turn off DLL import/export processing. We normally
link some things against the dynamic library, but if we're not building
that, we'll have to link everything statically.

Based on patches from 'william' on Bug #46367.

---

With this patch, the tools compile in a static-only build on Debian (both natively and with mingw-w64 targeting Win32), and -DDBUS_STATIC_BUILD appears in the pkg-config files for library users.

In practice, -DDBUS_STATIC_BUILD is never needed on Unix, but it seems better to be consistent and define it whenever we'll be using a static library.

Patch applicable to 1.5.x, review requested.
Comment 10 Simon McVittie 2012-06-05 03:49:29 UTC
If anyone cares about this bug, review would be appreciated.
Comment 11 René Berber 2012-06-11 10:36:54 UTC
Comment on attachment 58319 [details] [review]
When not producing a dynamic library, define  DBUS_STATIC_BUILD

Review of attachment 58319 [details] [review]:
-----------------------------------------------------------------

Tested the patch with release 1.6.0, building in MXE (previously known as MinGW cross compiling environment), reverting their patch with the same objective.

Everything build fine.
Comment 12 Simon McVittie 2012-06-15 07:23:32 UTC
Not reviewed, as such, but nobody has objected and it's a simple change, so I'm going to ship it.

Fixed in git for 1.6.2.


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.