[
https://issues.apache.org/jira/browse/LUCY-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nick Wellnhofer reopened LUCY-231:
----------------------------------
I came to the conclusion that using per-parcel defines which resolve to either
CHY_EXPORT or CHY_IMPORT might be a better idea after all. Especially for the C
bindings, I'd prefer CFC to generate deterministic output. Otherwise, we'd have
to generate a second set of header files to compile the test executables (at
least on Windows) or for installation.
My proposal is to use a per-parcel define like LUCY_VISIBLE for externally
visible symbols and to put the following #ifdef in parcel.h:
#ifdef CFP_LUCY
#define LUCY_VISIBLE CHY_EXPORT
#else
#define LUCY_VISIBLE CHY_IMPORT
#endif
We'd need a similar #ifdef for every included parcel but this can be done
later. Then I'd define CFP_LUCY via compiler flags only when compiling Lucy.
I'm only not sure what the best name for these macros would be. For example,
instead of LUCY_VISIBLE, we could also use LUCY_PUBLIC or LUCY_EXTERN.
> 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,
> 0003-Unify-method-data-for-initialization-and-callbacks.patch,
> 0004-Preliminary-Charmonizer-support-for-symbol-export.patch,
> 0005-Switch-to-fvisibility-hidden-and-start-using-CHY_EXP.patch,
> 0006-Install-import-library-on-Windows.patch, bad_encapsulation.pl,
> bad_encapsulation_report.txt
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
