Re: good examples of Emacs modules?

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

>> From: Óscar Fuentes <address@hidden>
>> Date: Thu, 31 Mar 2016 23:59:36 +0200
>> 
>> BTW, it is necessary to explicitly export the symbols on Windows (and on
>> GNU/Linux too depending on the arguments used):
>> 
>> int plugin_is_GPL_compatible;
>> 
>> should be
>> 
>> int __declspec(dllexport) plugin_is_GPL_compatible;
>> 
>> (Windows)
>> 
>> int __attribute__ ((visibility("default"))) plugin_is_GPL_compatible;
>
> I don't need any such Windows-specific attributes, so I'm unsure why
> you think you do.  The test in modules/mod-test compiles and passes
> the tests just fine without that.

This is because MinGW defaults to "export everything" (as soon as the
compiler sees a dllexport, it disables the "export everything" feature),
same as gcc on GNU/Linux does. On Windows this is not a good practice if
you have multiple dlls (modules) with potentially identical symbols
exported. Not a big deal on the case of Emacs modules, but having to
explicitly exporting symbols is something a non-MinGW-immersed Windows
developer assumes as a fact.

>> (GNU/Linux, when you compile your module with -fvisibility=hidden, which
>> is a Good Thing.)
>
> If someone uses -fvisibility=hidden on a shared object, they know what
> they are doing, and they need the attribute on every exported symbol,
> not just on plugin_is_GPL_compatible.

Yes, that's the idea. Explicitly exporting symbols is a recommended
practice (by GCC) on GNU/Linux and a requirement on Windows, except on
the case of MinGW which implements a hack, which is problematic, and the
MinGW developers (the old ones such as Danny, who knew the binutils and
gcc internals) advised against using it.

Anyway, it is possibly a good idea to left things how they are now as
most modules will be developed on GNU/Linux and decorating
`plugin_is_GPL_compatible' may cause confusion, both to module writers
on GNU/Linux and builders on Windows.

So let's forget the issue for now.