[root@djt-17-109-v06 tmp]# cat tvisi.cpp extern "C" typedef struct __cook cook_t; extern "C" cook_t* myopen(); struct __attribute__ ((visibility ("hidden"))) __cook { virtual ~__cook() = 0; }; //__attribute__ ((visibility ("default"))) cook_t* myopen() { return 0; } [root@djt-17-109-v06 tmp]# g++ tvisi.cpp -o libxx.so -shared -fPIC && nm -D libxx.so | fgrep myopen 00000000000005cc T myopen The function myopen is exported by g++ 4.4.6 [root@djt-17-109-v06 tmp]# g++47 tvisi.cpp -o libxx.so -shared -fPIC && nm -D libxx.so | fgrep myopen [root@djt-17-109-v06 tmp]# The function myopen is not exported by g++ 4.7.0 Workaround: define '__cook' after the definition of 'myopen'
gcc source base: DATE 20120604 svn://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_7-branch@188193
I think this is expected behavior as if someone defines a "__cook" in the executable which links to the shared library, it will be considered a different type.
If "myopen" returns "__cook", I will agree with you. But "myopen" returns "__cook *", just a pointer. I do not think it is reasonable to hide "myopen". It is a usual method to hide the implementation detail of cook_t, but exports some free function to operate with cook_t*, such as "FILE *". (In reply to comment #2) > I think this is expected behavior as if someone defines a "__cook" in the > executable which links to the shared library, it will be considered a different > type.