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 541548 - Support for exporting a callback function in windows
Support for exporting a callback function in windows
Status: RESOLVED INVALID
Product: vala
Classification: Core
Component: Methods
0.3.x
Other Windows
: Normal minor
: ---
Assigned To: Vala maintainers
Vala maintainers
Depends on:
Blocks:
 
 
Reported: 2008-07-04 13:13 UTC by Matias
Modified: 2009-12-15 19:14 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Matias 2008-07-04 13:13:16 UTC
It is posible to add an attibute (like '[Export]') for export a callback
function in windows?
In linux work fine the callback functions but in window must add this to a
callback method:

G_MODULE_EXPORT void callback_example ();

When compiling on Linux, this will have absolutely no effect, but when
compiling on Windows, the macro expands to __declspec(dllexport), which
marks the symbol as one to be exported, so that it can be called by gmodule.

Please add this support because is important (in windows only), Thanks!!!

For Example:
Vala code:

[Export]
[CCode (instance_pos=-1)]
public void on_destroy (Gtk.Widget widget)
{
	Gtk.main_quit ();
}

C code:
G_MODULE_EXPORT void sample_on_destroy (GtkWidget* widget, Sample* self) {
	g_return_if_fail (IS_SAMPLE (self));
	g_return_if_fail (GTK_IS_WIDGET (widget));
	g_print ("Funciona salir\n");
	gtk_main_quit ();
}

Thanks!!

Other information:
Comment 1 Jared Moore 2008-07-04 14:17:02 UTC
Is there any reason not to export? I'm just wondering if it is possible to reduce complexity (i.e. not creating a new attribute, and not requiring use of it in user code) by just adding G_MODULE_EXPORT to everything.
Comment 2 Matias 2008-07-04 20:11:20 UTC
(In reply to comment #1)
> Is there any reason not to export? I'm just wondering if it is possible to
> reduce complexity (i.e. not creating a new attribute, and not requiring use of
> it in user code) by just adding G_MODULE_EXPORT to everything.
> 

The attribute '[Export]' it's just a suggestion. 
You can add G_MODULE_EXPORT to everything. In linux isn't a problem, but in windows all the methods will be exported.

The general idea is to place "G_MODULE_EXPORT" ONLY to callbacks. I you do this, perfect, problem solved.
The suggestion of the '[Export]' attribute was the first thing I came to mind.

Comment 3 Matias 2008-07-08 21:40:16 UTC
insted of G_MODULE_EXPORT you can also use GLIB_VAR in gtype.h, but it add 'extern' to the functions in linux....
Comment 4 Jürg Billeter 2008-08-14 19:07:51 UTC
Jared is right, we should add G_MODULE_EXPORT to all non-internal symbols, as you not only want to export callbacks but also library methods. Applications should not have any internal symbols except for callbacks anyway, so this should not be an issue, either.

We should also add G_GNUC_INTERNAL to all non-static internal symbols to avoid exporting internal symbols on ELF systems, however, that's only an optimization and not as urgent.
Comment 5 Haakon Sporsheim (ieei) 2009-07-13 11:22:18 UTC
G_MODULE_EXPORT should ONLY be used for functions/symbols which you later would be looking up with g_module_symbol(). It is specified in a gmodule header, so it makes gmodule a dependency. Since the header is located in the same directory as glib it will find the header without any PkgConfig modifications, but there might be problems on systems that for some reason have glib, but not gmodule installed. (Cant say I have heard of this, but anyways.. bad practice)

(In reply to comment #3)
> insted of G_MODULE_EXPORT you can also use GLIB_VAR in gtype.h, but it add
> 'extern' to the functions in linux....
> 
Absolutely NOT! GLIB_VAR is a preprocessor used for GLib 'global' public variables, so that they get exported to the glib dll when building on windows. Trying to define GLIB_COMPILATION and DLL_EXPORT just to get GLIB_VAR to be __declspec(dllexport) would break the already correctly annotated (__declspec(dllimport)) variables from GLib used in your module/application.



In most cross platform libraries I participate in we use a preprocessor which is similar to GLIB_VAR, but we use it for all public symbols in the library. And since our public header(s) is(/are) using it, the only thing separating the function and variable declarations is the __declspec annotation. dllexport when we compile the library and dllimport when we use it from another library or an application.

So yes, I agree with Jared and Jürg that this is something that would be great to just generate. Although I don't think G_MODULE_EXPORT is the right solution.
Comment 6 Haakon Sporsheim (ieei) 2009-07-13 11:30:07 UTC
Another approach is to skip __declspec and instead give the linker a list of all public symbols. See bug #586494. The file you give to the linker is a so called definitions (.def) file which basically consist of EXPORTS followed by all function/variable names (one symbol pr line). This is what I use when compiling a typical open source library, because it wont 'pollute' every header file which then again makes it harder to pull changes from upstream.

Personally I would like to have this generated, but bug #586494 makes my toolchain more happy, hehe ;) And is easier to implement I guess.
Comment 7 Jürg Billeter 2009-12-15 19:14:57 UTC
Bug 586494 has been fixed now.

I'd still like to support something like G_MODULE_EXPORT in Vala, however, in such a way that it can also be used to restrict visibility of internal symbols on ELF systems. It appears to me as if GLIb does not provide an approriate define for this yet, so I'm closing this as INVALID (there is no CANTFIX). Feel free to reopen the bug when GLib has an approriate define/mechanism for this.