Author Topic: UdpSocket visibility issues with destructor & vtable (Read 2938 times)

Cornstalks · « **on:** March 14, 2012, 04:24:24 am »

So I've been excited to use the latest SFML, but I'm getting some weird warnings. Things still work and my program runs, but I'm not sure if this is just my build system or if it's an issue with SFML. I'm using the System and Network modules of SFML, and I've build and configured them with no warnings or errors. However, my program is trying to use the libraries and I'm getting the following warnings at link time:

Code: [Select]

g++ -g -L../sfml/lib -lsfml-system-s -lsfml-network-s -L../protobuf/lib -lprotobuf -I../sfml/include -I../protobuf/include -o client main.cpp Message.pb.cc
ld: warning: sf::UdpSocket::~UdpSocket()has different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: sf::UdpSocket::~UdpSocket()has different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: vtable for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: typeinfo for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o
ld: warning: typeinfo name for sf::UdpSockethas different visibility (hidden) in ../sfml/lib/libsfml-network-s.a(UdpSocket.cpp.o) and (default) in /tmp/ccZt6Ur6.o

It's complaining about the visilbility of the UdpSocket destructor, as well as the vtable and typeinfo for UdpSocket. I'm positive the headers and source files are all the same version, as I just did a clean checkout. I can't see anything wrong with UdpSocket either.

Does anyone thing this is an issue with SFML or is it probably an issue with my computer? What more can I do to narrow down the problem?

If needed, my setup is:
OS X 10.6
g++ 4.2.1
SFML revision d592b2a

Laurent · « **Reply #1 on:** March 14, 2012, 08:06:23 am »

Don't use static libraries, it makes no sense on OS X.

Cornstalks · « **Reply #2 on:** March 15, 2012, 06:57:36 am »

Hi Laurent, thanks for the reply. Normally, I would use dynamic libraries (on Windows too), but I'm currently working on a game project for school and it needed to be a static build. I just wanted to see if anyone's had these warnings before and how to resolve them. I can ignore them if necessary.

Laurent · « **Reply #3 on:** March 15, 2012, 07:48:43 am »

I have no idea, visibility stuff has never been tested on OS X, I don't even know if it's supposed to behave the same as on Linux.

Why does it have to be static? In OS X you can pack everything into a bundle, can't you?

Cornstalks · « **Reply #4 on:** March 16, 2012, 05:37:50 pm »

If it were a real world application, yes, I most certainly would do that. But for this assignment they don't want a bundle, they just want an executable.

Anyway, this should be ok for now. I'll test it with g++4.6 someday (probably during the summer, when I have time to work on my personal projects that'll use SFML), and if there are issues with g++4.6 I'll look into it more and see if I can help provide a patch (or at least a detailed bug report).