[ sox-Feature Requests-2214694 ] Do not export lsx_ symbols in libsox

[SourceForge.net <noreply@sourceforge.net>]

Feature Requests item #2214694, was opened at 2008-11-01 14:12
Message generated for change (Comment added) made by uklauer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360706&aid=2214694&group_id=10706

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Chris Bagwell (cbagwell)
Assigned to: Nobody/Anonymous (nobody)
Summary: Do not export lsx_ symbols in libsox

Initial Comment:
If you look at the public symbols in libsox, you'll see a lot of symbols that we do not advertise as part of the SoX API.  They have all been prefixed with lsx_ to help distinguish them.

It would be nice to not export those as public symbols.  Most obvious option is to make use of -retain-symbols-file where it is supported.  

I think I've also seen attempts to do this at compile time by png.h (not sure if it works or worth the trouble it looks like it causes).

----------------------------------------------------------------------

>Comment By: Ulrich Klauer (uklauer)
Date: 2013-03-08 04:01

Message:
This can, in principle, be easily done via libtool's -export-symbols-regex
option ("-export-symbols-regex '^sox_'").

However, SoX-the-application uses several internal functions (see "nm -Du
`which sox` | grep lsx_"), and the modules built via --with-whatever=dyn
some more. Therefore, the regex to use is more like:
"^(sox_.*|lsx_(check_read_params|(close|open)_dllibrary|(debug(_more|_most)?|fail|report|warn)_impl|eof|fail_errno|filelength|find_(enum_(text|value)|file_extension)|getopt(_init)?|lpc10_(create_(de|en)coder_state|(de|en)code)|raw(read|write)|read(_b_buf|buf|chars)|realloc|rewind|seeki|sigfigs3p?|strcasecmp|tell
|unreadb|write(b|_b_buf|buf|s)))$"
Still, this hides about 90% of the private symbols, so I think I will
actually add this, as a step in the right direction.

To deal with the rest, we'd need to create a self-contained helper library
that can be linked (statically) into the modules, and into
SoX-the-application. But it is probably difficult to make it
self-contained, as those functions in turn call more internal functions,
etc.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360706&aid=2214694&group_id=10706

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev