[Bug 797185] Fix API export/import decorators in general and "inconsistent DLL linkage" with MSVC on Windows
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Mon Sep 24 13:50:52 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=797185
Tim-Philipp Müller <t.i.m at zen.co.uk> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
Target Milestone|git master |1.15.1
--- Comment #8 from Tim-Philipp Müller <t.i.m at zen.co.uk> ---
core:
commit 50c32da91fb0c398be23aff7b37ac3dc516323be (HEAD -> master, origin/master,
origin/HEAD)
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Wed Sep 19 19:37:38 2018 +0100
meson: use library() for libgstcheck instead of always building a shared
lib
Otherwise we try to build a shared lib when we build the rest
of GStreamer statically, which won't work because we pass
-DGST_STATIC_COMPILATION when building statically, which means
we won't dllimport public symbols from our libs which means
that on Windows the unit tests will fail to link to libgstcheck.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
commit af5717b3646927013902c690f46162554fd547c3
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Sun Aug 26 01:23:23 2018 +0200
tests: netclock-replay: fix build with new api export/import
Can't mix/match imports and exports from the same library
here, so just include all .c files needed instead and don't
link to gstnet at all then.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
commit 57c8e0146f0e203058c95721527cf50a1dd19f72
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Sat Aug 25 23:56:01 2018 +0200
libs: figure out right export define in configure
Add new GST_API_EXPORT in config.h and use that for GST_*_API
decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes
gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
commit 46ed0f0489896824f45694b5d8fbdfaac8de6504
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Sat Aug 25 23:09:12 2018 +0200
libs: fix 'inconsistent DLL linkage' warnings on Windows
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
commit 50038bed79e056eee109572db03113999cc7eb38
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Sat Aug 25 22:53:07 2018 +0200
gstconfig.h: add GST_API_IMPORT define
This is for use by the various GST_*_API decorators and
will be what they get defined to when a library API is being
used by external users of that library (not the library itself
whilst it's being compiled).
In most cases it will simply map to a plain 'extern' but on
Windows with MSVC it will need to map to __declspec(dllimport).
For functions this is not strictly needed, but for exported
variables it is.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
base:
commit dc29bc4e13ea1c25b1179efe362dd5b2bc071fd5 (HEAD -> master, origin/master,
origin/HEAD)
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Sat Apr 28 14:50:11 2018 +0100
libs: fix API export/import and 'inconsistent linkage' on MSVC
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
While we're at it, add new GST_API_EXPORT in config.h and use
that for GST_*_API decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes
gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
bad:
commit 96ac822b67b56aacd3bc530ca6cba1d38f90895c
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Mon Sep 24 14:40:31 2018 +0100
player: fix deprecated api declaration
commit b6411ae74cc7319ef368f5b4a6a872231b49620a
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Mon Sep 24 11:52:22 2018 +0100
libs: fix API export/import and 'inconsistent linkage' on MSVC
For each lib we build export its own API in headers when we're
building it, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
The problem was that we had defined all GST_*_API decorators
unconditionally to GST_EXPORT. This was intentional and only
supposed to be temporary, but caused linker warnings because
we tell the linker that we want to export all symbols even
those from externall DLLs, and when the linker notices that
they were in external DLLS and not present locally it warns.
What we need to do when building each library is: export
the library's own symbols and import all other symbols. To
this end we define e.g. BUILDING_GST_FOO and then we define
the GST_FOO_API decorator either to export or to import
symbols depending on whether BUILDING_GST_FOO is set or not.
That way external users of each library API automatically
get the import.
While we're at it, add new GST_API_EXPORT in config.h and use
that for GST_*_API decorators instead of GST_EXPORT.
The right export define depends on the toolchain and whether
we're using -fvisibility=hidden or not, so it's better to set it
to the right thing directly than hard-coding a compiler whitelist
in the public header.
We put the export define into config.h instead of passing it via the
command line to the compiler because it might contain spaces and brackets
and in the autotools scenario we'd have to pass that through multiple
layers of plumbing and Makefile/shell escaping and we're just not going
to be *that* lucky.
The export define is only used if we're compiling our lib, not by external
users of the lib headers, so it's not a problem to put it into config.h
Also, this means all .c files of libs need to include config.h
to get the export marker defined, so fix up a few that didn't
include config.h.
This commit depends on a common submodule commit that makes
gst-glib-gen.mak
add an #include "config.h" to generated enum/marshal .c files for the
autotools build.
https://bugzilla.gnome.org/show_bug.cgi?id=797185
rtsp-server:
commit 62d4c0b179555fa0189d2c8a8e2d81da04a5bc3d
Author: Tim-Philipp Müller <tim at centricular.com>
Date: Mon Sep 24 09:36:21 2018 +0100
libs: fix API export/import and 'inconsistent linkage' on MSVC
Export rtsp-server library API in headers when we're building the
library itself, otherwise import the API from the headers.
This fixes linker warnings on Windows when building with MSVC.
Fix up some missing config.h includes when building the lib which
is needed to get the export api define from config.h
https://bugzilla.gnome.org/show_bug.cgi?id=797185
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list