[
https://issues.apache.org/jira/browse/LUCY-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13255997#comment-13255997
]
Marvin Humphrey commented on LUCY-231:
--------------------------------------
> We still have to export all the method symbols because they might be used in
> the initialization of VTables of extension classes (and possibly other
> places).
You mean the implementing functions? We should be able to just copy the
parent VTable, as VTable_singleton() does when creating a new subclass at
runtime.
The only place that we have to worry about symbol import is when the
implementation is defined in a separate file, as it is for host
implementations such as Lucy_Doc_Get_Size();
Say that we autogenerate VTable bootstrapping code to look for functions
beginning with "S_" (because the implementations are static functions). For
methods where the implementation must be elsewhere, we can have the static
function wrap an ordinary (implicitly extern) function:
{noformat}
// core/Lucy/Document/Doc.c
static uint32_t
S_Doc_get_size(Doc *self) {
return lucy_Doc_get_size_IMPL(self);
}
// perl/xs/Lucy/Document/Doc.c
uint32_t
lucy_Doc_get_size_IMPL(lucy_Doc *self) {
return self->fields ? HvKEYS((HV*)self->fields) : 0;
}
{noformat}
> Symbol visibility
> -----------------
>
> Key: LUCY-231
> URL: https://issues.apache.org/jira/browse/LUCY-231
> Project: Lucy
> Issue Type: Task
> Components: Clownfish
> Reporter: Nick Wellnhofer
> Assignee: Nick Wellnhofer
> Attachments:
> 0001-Preliminary-Charmonizer-support-for-symbol-export.patch,
> 0002-Switch-to-fvisibility-hidden-and-start-using-CHY_EXP.patch
>
>
> In order to get compiled extension working on Windows, we'll have to define
> the visibility of our extern variables and functions. On Windows every
> exported symbol of a DLL has to be marked with __declspec(dllexport) when
> compiling the DLL. If you're linking against a DLL, every symbol imported
> from the DLL has to be marked __declspec(dllimport)
> On UNIX, every symbol is exported by default, so defining visibility is not
> strictly necessary. But hiding symbols that don't have to be exported has the
> benefit of reducing size and speeding up loading of a DLL. Hidden symbols
> also allow the compiler to generate more optimized code.
> The standard approach is to compile with the GCC option -fvisibility=hidden
> which emulates the Windows behavior. Then a macro is defined roughly like
> that (should probably be handled by charmonizer):
> {noformat}
> #if defined __GNUC__
> # if defined _WIN32 || defined __CYGWIN__
> # define CHY_EXPORT __attribute__ ((dllexport))
> # elif __GNUC__ >= 4
> # define CHY_EXPORT __attribute__ ((visibility ("default")))
> # else
> # define CHY_EXPORT
> # endif
> #elif defined _MFC_VER
> # define CHY_EXPORT __declspec(dllexport)
> #else
> # define CHY_EXPORT
> #endif
> {noformat}
> This macro can then be used like that:
> {noformat}
> CHY_EXPORT void
> exported_function();
> extern CHY_EXPORT int exported_variable;
> {noformat}
> When compiling an extension, we also have to handle __declspec(dllimport) on
> Windows. For the generated headers, we could define CHY_IMPORT and use it
> instead of CHY_EXPORT for "included" headers. For the code in XSBind.[ch], we
> could define BUILDING_XSBIND only during compilation of XSBind.c and then use
> something like that:
> {noformat}
> #if defined __GNUC__
> # if defined _WIN32 || defined __CYGWIN__
> # if BUILDING_XSBIND
> # define XSBIND_EXPORT __attribute__ ((dllexport))
> # else
> # define XSBIND_EXPORT __attribute__ ((dllimport))
> # endif
> # elif __GNUC__ >= 4
> # define XSBIND_EXPORT __attribute__ ((visibility ("default")))
> # else
> # define XSBIND_EXPORT
> # endif
> #elif defined _MFC_VER
> # if BUILDING_XSBIND
> # define XSBIND_EXPORT __declspec(dllexport)
> # else
> # define XSBIND_EXPORT __declspec(dllimport)
> # endif
> #else
> # define XSBIND_EXPORT
> #endif
> XSBIND_EXPORT cfish_Obj*
> cfish_XSBind_new_blank_obj(SV *either_sv);
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
