After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 726159 - linking problem with METHOD_** symbols under windows
linking problem with METHOD_** symbols under windows
Status: RESOLVED FIXED
Product: libsoup
Classification: Core
Component: Misc
unspecified
Other Windows
: Normal normal
: ---
Assigned To: libsoup-maint@gnome.bugs
libsoup-maint@gnome.bugs
Depends on:
Blocks:
 
 
Reported: 2014-03-12 09:07 UTC by Eric
Modified: 2016-03-20 07:18 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
fix export by using G_MODULE_EXPORT (1.28 KB, patch)
2014-03-12 09:18 UTC, Eric
none Details | Review

Description Eric 2014-03-12 09:07:04 UTC
Hi,
when linking with libsoup-2.4.lib, the external symbols for METHOD_GET, METHDO_HEAD ... can't be find.

I had to change the declaration from extern to __declspec(dllimport) for the linker to find the symbol.

Regards,
Eric T.
Comment 1 Eric 2014-03-12 09:18:56 UTC
Created attachment 271581 [details] [review]
fix export by using G_MODULE_EXPORT
Comment 2 Dan Winship 2014-11-23 14:35:39 UTC
sorry, very belatedly dealing with old bugs...

G_MODULE_EXPORT is "Used to declare functions imported from modules" according to the docs, which is not what we're doing here, so it's not the right macro to be using. (And, eg, it might do the wrong thing on some other platform.)

GLib uses "GLIB_VAR" internally, which switches between _declspec(dllexport) and _declspec(dllimport) depending on whether you're building GLib or compiling against it. Maybe libsoup needs to have something like that?
Comment 3 Edward Hervey 2014-12-05 10:01:03 UTC
Can't we just use GLIB_VAR from glib as-is ?
Comment 4 Dan Winship 2014-12-05 13:58:42 UTC
In general, symbols/macros prefixed with "glib_" rather than "g_" aren't intended for external consumption. They're things that belong to GLib itself, but which, for whatever reason, have to end up in installed headers. In particular in this case, the behavior of GLIB_VAR depends on GLIB_COMPILATION, which is what GLib headers use to figure out that they're being included from inside the glib build, as opposed to being included by another module, and definitely should not be #defined by other modules. (libsoup doesn't currently have a #define that means that, so that would need to be added.)
Comment 5 Dan Winship 2015-02-10 11:58:34 UTC
[mass-moving all "UNCONFIRMED" libsoup bugs to "NEW" after disabling the "UNCONFIRMED" status for this product now that bugzilla.gnome.org allows that. bugspam-libsoup-20150210]
Comment 6 Nirbheek Chauhan 2016-03-20 07:18:04 UTC
This is already fixed in git. Closing.

commit e4572a770ecafc807296d9a2eb99e9dea0019887
Author: Ignacio Casal Quinteiro <icq@gnome.org>
Date:   Tue Oct 27 13:22:55 2015 +0100

    Declare a SOUP_VAR to externalize variables
    
    This is needed to properly externalize the variables
    on windows. Since we need to handle dllexport vs dllimport
    
    https://bugzilla.gnome.org/show_bug.cgi?id=757146