This link may be relevant:
When exporting a function in ATS to C, there are some concerns.
Say we have:
extern foo (x: string): int = “ext#”
The ‘foo’ is given the following interface in C:
int foo (void*) // this is too imprecise
Following is another way to do this:
extern foo (x: string): int = “sta#foo_”
%{
int foo(char *p) { return foo_(p); } // you can use VISIBLE here
%}
Though a bit pedantic, the latter style should be preferred.On Monday, November 3, 2014 11:46:55 PM UTC-5, Barry Schwartz wrote:
Is there any way to control GCC’s symbol visibility attribute from
within ATS code?I am referring to what in C is done by having something like
#if I_AM_USING_GCC
#define VISIBLE attribute((visibility(“default”)))
#else
#define VISIBLE
#endifto let you mark an extern symbol for exportation by a shared library.
Then you put -fvisibility=hidden in the gcc command line, to make
extern symbols “hidden” by default.This is a favored technique when making shared and dynamically
loadable libraries on systems that have support for ‘visibility’; it
reduces symbol bloat and also helps ensure correct linkage.Perhaps there is no way other than, for instance, to mark the ATS
functions as “ext#” and at the same time put extern declarations in
.cats files that include the visibility attribute notation. Or is it
possible to modify how “ext#” works?Note 1. This visibility stuff does nothing useful for static
libraries. Static libraries are rare these days, of course.Note 2. GNU ld often can do similar things, but in ways that in my
opinion are too troublesome.