lucy-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick Wellnhofer (JIRA)" <j...@apache.org>
Subject [lucy-issues] [jira] [Resolved] (LUCY-231) Symbol visibility
Date Sat, 15 Jun 2013 19:17:20 GMT

     [ https://issues.apache.org/jira/browse/LUCY-231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Nick Wellnhofer resolved LUCY-231.
----------------------------------

    Resolution: Fixed

The symbol visibility changes have been done.
                
> 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

Mime
View raw message