Bug 33973

I believe this is a Windows-specific consequence of how PE imports work; ELF systems don't have this problem.

(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.

(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.

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.

*** Bug 46367 has been marked as a duplicate of this bug. ***

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.

*** Bug 46366 has been marked as a duplicate of this bug. ***

*** Bug 46367 has been marked as a duplicate of this bug. ***

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.

If anyone cares about this bug, review would be appreciated.

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.

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.