Use -fvisibility=hidden and explicitly mark symbols for shared object export #248
Comments
|
One must be mindful about how much of that is GNU extensions that might potentially introduce incompatibilities with either some compilers (e.g. IBM XL, PGI) or non-Linux operating systems (macOS, Windows). |
|
@epifanovsky Totally agree. It will probably take some time to iron out the differences for all operating systems and compilers that we support. In the worst case, we undefine the envisioned export macro so that it has no effect, and we revert to something similar to current behavior. |
fgvanzee
added a commit
that referenced
this issue
Mar 12, 2019
Details: - After merging PR #303, at Isuru's request, I removed the use of BLIS_EXPORT_BLIS from all function prototypes *except* those that we potentially wish to be exported in shared/dynamic libraries. In other words, I removed the use of BLIS_EXPORT_BLIS from all prototypes of functions that can be considered private or for internal use only. This is likely the last big modification along the path towards implementing the functionality spelled out in issue #248. Thanks again to Isuru Fernando for his initial efforts of sprinkling the export macros throughout BLIS, which made removing them where necessary relatively painless. Also, I'd like to thank Tony Kelman, Nathaniel Smith, Ian Henriksen, Marat Dukhan, and Matthew Brett for participating in the initial discussion in issue #37 that was later summarized and restated in issue #248. - CREDITS file update.
pradeeptrgit
pushed a commit
to amd/blis
that referenced
this issue
Jan 14, 2020
Details: - After merging PR flame#303, at Isuru's request, I removed the use of BLIS_EXPORT_BLIS from all function prototypes *except* those that we potentially wish to be exported in shared/dynamic libraries. In other words, I removed the use of BLIS_EXPORT_BLIS from all prototypes of functions that can be considered private or for internal use only. This is likely the last big modification along the path towards implementing the functionality spelled out in issue flame#248. Thanks again to Isuru Fernando for his initial efforts of sprinkling the export macros throughout BLIS, which made removing them where necessary relatively painless. Also, I'd like to thank Tony Kelman, Nathaniel Smith, Ian Henriksen, Marat Dukhan, and Matthew Brett for participating in the initial discussion in issue flame#37 that was later summarized and restated in issue flame#248. - CREDITS file update.
dzambare
pushed a commit
to amd/blis
that referenced
this issue
Mar 15, 2021
Details: - After merging PR flame#303, at Isuru's request, I removed the use of BLIS_EXPORT_BLIS from all function prototypes *except* those that we potentially wish to be exported in shared/dynamic libraries. In other words, I removed the use of BLIS_EXPORT_BLIS from all prototypes of functions that can be considered private or for internal use only. This is likely the last big modification along the path towards implementing the functionality spelled out in issue flame#248. Thanks again to Isuru Fernando for his initial efforts of sprinkling the export macros throughout BLIS, which made removing them where necessary relatively painless. Also, I'd like to thank Tony Kelman, Nathaniel Smith, Ian Henriksen, Marat Dukhan, and Matthew Brett for participating in the initial discussion in issue flame#37 that was later summarized and restated in issue flame#248. - CREDITS file update.
dzambare
pushed a commit
to amd/blis
that referenced
this issue
Jul 6, 2021
Details: - After merging PR flame#303, at Isuru's request, I removed the use of BLIS_EXPORT_BLIS from all function prototypes *except* those that we potentially wish to be exported in shared/dynamic libraries. In other words, I removed the use of BLIS_EXPORT_BLIS from all prototypes of functions that can be considered private or for internal use only. This is likely the last big modification along the path towards implementing the functionality spelled out in issue flame#248. Thanks again to Isuru Fernando for his initial efforts of sprinkling the export macros throughout BLIS, which made removing them where necessary relatively painless. Also, I'd like to thank Tony Kelman, Nathaniel Smith, Ian Henriksen, Marat Dukhan, and Matthew Brett for participating in the initial discussion in issue flame#37 that was later summarized and restated in issue flame#248. - CREDITS file update.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Picking up on the discussion that developed in pull request #37, it would probably be best for BLIS to not automatically export all symbols in its shared libraries, but rather only export the ones that correspond to "public" APIs.
In summary, this means:
-fvisibility=hidden, which sets the default symbol visibility to hidden;Also, if the export statements (that mark a symbol as public) are macroized, the macro can be defined conditionally based on whether we are building a Linux shared object or a Windows DLL.
GNU gcc documentation on symbol visibility can be found here.
The text was updated successfully, but these errors were encountered: