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 _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
