Re: atk 'missing symbols' problem since gnome-3-14

[Arnavion <arnavion gmail com>]

(I haven't looked at the headers in question myself).

If I'm understanding the situation correctly, you're building a binary
that includes an atk(mm) header that has some functions marked with
dllexport (from the POV of the compiler when it's compiling your
code).


> Technically though, I don't know if a similar issue will arise from declaring dllexport when we meant to use 
> dllimport.  It might produce the same problem - or a different problem - or no problem at all.

The attribute to be ignored and the function won't be re-exported from
your binary, since your binary doesn't provide a definition for it to
the linker. However, as you discovered...


> At the end of last year I discovered that some very obscure problems can arise if we try to import symbols 
> from a DLL without using '__declspec(dllimport)'.

That is correct, and is mentioned in MSDN [1] and also explained in
this answer on StackOverflow [2]. It's sub-optimal to not use
dllimport for functions and outright incorrect to not use it for data.

As I said above, the dllexport parameter will be ignored, which means
the item gets treated as if no attribute was specified. So if there is
data marked as dllexport in the atk(mm) header then it will be handled
incorrectly by any binary that uses that header.


[1] http://msdn.microsoft.com/en-us/library/8fskxacy.aspx
> Using __declspec(dllimport) is optional on function declarations, but the compiler produces more efficient 
> code if you use this keyword. However, you must use __declspec(dllimport) for the importing executable to 
> access the DLL's public data symbols and objects.

[2] http://stackoverflow.com/a/4490536   See also the linked blog post.


-Arnav


On Fri, Sep 26, 2014 at 12:01 PM, John Emmas <johne53 tiscali co uk> wrote:
> On 26/09/2014 11:51, John Emmas wrote:
> > > Also, since my last post I've discovered why atkmm was also failing to
> > > build [...] Now that I'm managing to generate those files correctly again,
> > > everything's now building fine.
>
> Oh, one more thing, before I forget it....
>
> I think I'm right in saying that, for Windows, ATK_AVAILABLE_IN_ALL can only
> be defined as either 'extern' or '__declspec (dllexport) extern'.  This
> might cause problems with the fact that libatkmm is routinely #including
> 'atk-enum-types.h'.  When building atkmm, the symbols declared inside
> atk-enum-types.h will be wrongly defined as exported symbols when they
> should be defined as imported.  When importing for use by some other
> library, they should really be defined as '__declspec (dllimport)'.
>
> At the end of last year I discovered that some very obscure problems can
> arise if we try to import symbols from a DLL without using
> '__declspec(dllimport)'.  Here's my description from the time:-
>
> https://mail.gnome.org/archives/gtkmm-list/2013-December/msg00002.html
>
> To be fair, that specific problem was caused by not having any import
> specifier at all (and it only affected imported data - not imported
> functions).  Technically though, I don't know if a similar issue will arise
> from declaring dllexport when we meant to use dllimport.  It might produce
> the same problem - or a different problem - or no problem at all.  I
> genuinely don't know - but it's always better to be safe, rather than
> sorry!!
>
> I know that Fan Chun-wei is hoping to look into this soon for libatkmm but
> it probably needs tidying up in libatk too. Hopefully, someone can find some
> time to give it some thought.... Best regards,
>
> John
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-devel-list