From: "Óscar Fuentes" <ofv@wanadoo.es>
To: emacs-devel@gnu.org
Subject: Re: good examples of Emacs modules?
Date: Fri, 01 Apr 2016 15:20:42 +0200 [thread overview]
Message-ID: <87lh4x5utx.fsf@wanadoo.es> (raw)
In-Reply-To: 83mvpdu79a.fsf@gnu.org
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Óscar Fuentes <ofv@wanadoo.es>
>> 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.
next prev parent reply other threads:[~2016-04-01 13:20 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-30 23:17 good examples of Emacs modules? Paul Eggert
2016-03-31 14:49 ` Aurélien Aptel
2016-03-31 15:34 ` Óscar Fuentes
2016-03-31 16:53 ` Eli Zaretskii
2016-03-31 17:07 ` Óscar Fuentes
2016-03-31 17:39 ` Eli Zaretskii
2016-03-31 20:23 ` Óscar Fuentes
2016-03-31 21:29 ` Aurélien Aptel
2016-03-31 21:59 ` Óscar Fuentes
2016-04-01 7:18 ` Eli Zaretskii
2016-04-01 13:20 ` Óscar Fuentes [this message]
2016-04-01 14:02 ` Eli Zaretskii
2016-04-02 2:10 ` Syohei Yoshida
2016-05-03 20:48 ` Philipp Stephani
2016-05-03 22:16 ` Stefan Monnier
2016-04-01 6:23 ` Eli Zaretskii
2016-04-01 13:25 ` Óscar Fuentes
2016-04-01 14:07 ` Eli Zaretskii
2016-05-03 20:54 ` Philipp Stephani
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87lh4x5utx.fsf@wanadoo.es \
--to=ofv@wanadoo.es \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.