G_MODULE_EXPORT (was: win32 trunk daily build runs again)

[Christian Stimming]

Am Sonntag, 24. April 2011 schrieb Geert Janssens:
> > Recently some functions were introduces with the attribute
> > G_MODULE_EXPORT (Geert in r20591 and r20533). In short: No good, please
> > don't use that attribute inside gnucash. Why did you do this?
> 
> Because that's what the GtkBuilder documentation suggested [1]. I'll admit
> I just blindly followed the advice given. I had no idea this had such an
> impact on the rest of the GnuCash library inter-dependencies.
> 
> > Here's the issue: In gnucash, our internally "downstream" libraries rely
> > on *all* symbols being exported from the internally "upstream"
> > libraries. This is done by mingw's linker if and *only* if no symbol at
> > all was marked as being exported.  As soon as at least one symbol is
> > manually marked as export, nothing except those marked symbols are
> > exported, 
> 
> Is that a design issue in the GnuCash code ? I mean should we normally
> explicitely decide which symbols to export an which not ? Or is this just
> bad advice on the gtkbuilder documentation page ?

It is bad advice on the gtkbuilder doc page. Their statement is only half-
complete. Just from reading the statement, I agree your decision to use that 
macro is correct. But their doc page is wrong. The wrong sentence is:

> When compiling applications for Windows, you must declare signal callbacks 
> with G_MODULE_EXPORT, or they will not be put in the symbol table.

Instead, a correct statement would be:

> When compiling applications for Windows and not using the auto-export 
feature where all symbols are exported automatically, you must declare signal 
callbacks with G_MODULE_EXPORT, or they will not be put in the symbol table. 
If you are using the auto-export feature where all symbols are exported 
automatically, you must not use the G_MODULE_EXPORT declaration as the auto-
export will work only if no symbol was declared with that macro.

In terms of gnucash design: Yes, we could see it as a design decision of 
gnucash. As we're not a library used by other people, we don't need to spend 
any thinking on which functions/symbols should be exported to others and which 
shouldn't. Hence, inside of our application (which happens to consist of the 
executable plus a whole bunch of DLLs) we simply declare everything as 
exported and that's it. Other projects that offer a library interface to 
downstream projects will probably decide on a different design, but we don't 
and shouldn't have to.

This probably means we should just remove all occurrences of G_MODULE_EXPORT 
again, not only undef'ing it as I did as a temporary workaround.

Regards,

Christian

> 
> Geert
> 
> [1]
> http://developer.gnome.org/gtk/stable/GtkBuilder.html#gtk-builder-connect-
> signals