G_MODULE_EXPORT (was: win32 trunk daily build runs again)

Geert Janssens janssens-geert at telenet.be
Mon Apr 25 06:01:15 EDT 2011


On Sunday 24 April 2011 21:40:25 Christian Stimming wrote:
> 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.
> 
Ok, that clarifies it a lot.

> 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.
> 
Yes, that makes sense as things are now. If we ever come to a point that we 
would want a libgnucash that can be used independently of a gnucash/cutecash 
application, we may have to revisit this item. For now, that's not needed.

> 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.
I will do so later today or tomorrow, unless someone else does it first.

Geert


More information about the gnucash-devel mailing list