[xsd-users] xml_schema::exception, linux, shared libraries, and visibility=hidden

[Greg Carter]

Hi,
XSD version - xsd-3.3.0.b2-i686-linux-gnu
problem on CentOS 5.4 x86_64, CentOS 5.4 x86
work around - don't compile with visibility=hidden

I'm having a problem catching exceptions of type xml_schema::exception 
thrown from a shared library on linux.

My shared libs look like:
libxmlbase.so  - XSD generated code
libmyxml.so - XSD generated code
libmylib.so uses above libs, compiled with visibility=hidden
myapp

Code inside libmyxml.so throws:

throw ::xsd::cxx::tree::unexpected_element < char > (
      n.name (),
      n.namespace_ (),
      "tcfFile",
      "http://www.geocosm.net/200608/TcfSchema");

Stepping into the above constructor I end up in 
libxsd/xsd/cxx/tree/exceptions.txx line 106, executing in libxmlbase.so. 

My catch code in libmylib.so looks like:

catch (const xml_schema::exception& e)
            {
                cout << "XML exception reading file: " << tcfFile << endl;
                cout << e << endl;
            }

The problem is that on linux when libmylib is compiled with 
visibility=hidden I never get into the catch, I do if I compile libmylib 
with visibility=default.  With visibility=hidden I fall through to
catch (std::exception& ex)
    {
        cout << ex.what() << endl;
    }
which is in myapp.

Code is compiled with xerces 3.1.0, (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)

I'm thinking that export defines used for the XSD generated code (XSD 
option --export-symbol) may need to be extended to the exception types 
so this works correctly on linux (example #define MYXSDEXPORT 
__attribute__ ((__visibility__("default"))) ).  For additional 
information see http://gcc.gnu.org/wiki/Visibility , particularly the 
section on exceptions.

For now I can work around the problem and not compile mylib with 
visibility=hidden, but eventually it would be great if I could.

Greg.