This would certainly be the better way to do things, as currently we are 
hidding
part of the CSOUND structure with pre-compiler directives which seems to
me to be a bit funny.

Victor

At 15:24 06/11/2007, you wrote:
>On windows, shared libraries only export wanted symbols (functions, 
>variables,
>etc). Historically, the reverse has been true for linux: all symbols are
>exported by default. Recently (with gcc4), it is possible to emulate that
>behavior. This is good because ABI breakages are less likely (only the API is
>exported, if the API doesn't change, the ABI most likely hasn't changed).
>
>The attached patch enables this by (a) defining PUBLIC on gcc systems, and 
>(b)
>enabling it by default on a linux/shared library build/gcc4 combination.
>
>--
>
>         Felipe Sateler
>
>
>-------------------------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc.
>Still grepping through log files to find problems?  Stop.
>Now Search log events and configuration files using AJAX and a browser.
>Download your FREE copy of Splunk now >> 
>http://get.splunk.com/_______________________________________________
>Csound-devel mailing list
>Csound-devel@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/csound-devel

Victor Lazzarini
Music Technology Laboratory
Music Department
National University of Ireland, Maynooth


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

It will still be necessary to hide parts of CSOUND using the pre-processor.
I think we should definitely not be exporting all symbols on any platform or
compiler version if we can help it!  Last time I checked, all symbols seemed
to be exported on OS X.  This spawns a linker warning (and maybe a bug?)
when using Cscore.

If export lists need to be created or something, then we should do so.  I
used to maintain an export list for OS 9 but that was too error-prone for
just me to do by myself.  I solved the problem by enclosing all of csound.h
in a pair of pragmas.  Is there a similar workaround for GCC 3 and earlier?

Anthony Kozar
anthonykozar AT sbcglobal DOT net
http://anthonykozar.net/

Victor Lazzarini wrote on 11/6/07 12:04 PM:

> This would certainly be the better way to do things, as currently we are
> hidding
> part of the CSOUND structure with pre-compiler directives which seems to
> me to be a bit funny.
> 
> Victor
> 
> At 15:24 06/11/2007, you wrote:
>> On windows, shared libraries only export wanted symbols (functions,
>> variables,
>> etc). Historically, the reverse has been true for linux: all symbols are
>> exported by default. Recently (with gcc4), it is possible to emulate that
>> behavior. This is good because ABI breakages are less likely (only the API is
>> exported, if the API doesn't change, the ABI most likely hasn't changed).
>> 
>> The attached patch enables this by (a) defining PUBLIC on gcc systems, and
>> (b)
>> enabling it by default on a linux/shared library build/gcc4 combination.


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net

Felipe Sateler wrote:

> All other workarounds I'm aware of require gcc 4 or gcc 3+patches.

The method I use for libsndfile works for Linux, Mac OSX and Win32,
right back to gcc-2.95 *without* leaving any ugly __declspec or
__attribute__(visibility("hidden")) crap in the code.

If people are interested, they can grab the libsndfile sources. The
mthod I use is based on a python script (only needed for developer
machines, not required to build from source tarballs) called
create_symbols_file.py which lists all of the public API functions
and their Ordinal number (only used by windows). This script generates
the files:

   Symbols.linux
   Symbols.darwin (Mac OSX)
   libsndfile.def (Win32)
   cygsndfile.def (Cygwin on win32)

Theses files are generated in the development environment and shipped
in the source code tarballs. During the configure process (configure.ac)
the correct file is added to the build process and passed to the linker.

The libsndfile.def file also works with the microsoft dev tools last 
time I checked.

If someone has another compiler which also supports this symbol hiding
in shard libraries, it should be pretty easy to add support to the
Python script.

The nice things about this method:

  - It doesn't polute the code with __declspec etc.
  - Symbol list is kept in one place and one place only, and all the
    output variants are generated from this.
  - It works all the way back to gcc-2.95.

Hope this helps,
Erik
-- 
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"Perl - The only language that looks the same before and after
RSA encryption." -- Keith Bostic

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net