Symbols that may be leaking

[Lisandro Damián Nicanor Pérez Meyer]

Hi! Upon reviewing the so files I generate for the Debian package, I get
something like:

_ZN21QextSerialPortPrivate10setTimeoutElb

which, with the iad of c++filt, traduces to

QextSerialPortPrivate::setTimeout(long, bool)

Which means that some privtae symbols are being exported.

I'm building with -fvisibility=hidden -fvisibility-inlines-hidden. I'll do my
best to check the code and see what we can do to avoid this (better if I can
provide patches, of course :) )

Kind sregards, Lisandro.

--
Combata las características. Si una característica no es absolutamente
esencial, descártela, especialmente si tiene el mismo efecto que se
puede alcanzar mediante la combinación de otras características.
Andrew S. Tanenbaum, de su libro "Computer Networks"

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[Michal Policht]

Have you tried to explicitly add __attribute__ ((visibility ("hidden"))) before
QextSerialPortPrivate declaration and see what happens?

(http://gcc.gnu.org/wiki/Visibility).


BTW Is "_sys" suffix in function names of this class really necessary?
Since the class is already marked "Private" (i.e. implementation
specific), thus every function should be "_sys" and declaiming it twice
violates Occam's rule ("entities must not be multiplied beyond
necessity").** This also implies that functions which are not
implementation specific ("_sys") shall be moved to shared code base.

Regards.

[Lisandro Damián Nicanor Pérez Meyer]

On Mar 17 Jul 2012 07:28:14 Michal Policht escribió:
> Have you tried to explicitly add __attribute__ ((visibility ("hidden")))
> before QextSerialPortPrivate declaration and see what happens?
>
> (http://gcc.gnu.org/wiki/Visibility).

I have not tried modifying the code yet. All I did was to export
-fvisibility=hidden -fvisibility-inlines-hidden

> BTW Is "_sys" suffix in function names of this class really necessary?
> Since the class is already marked "Private" (i.e. implementation
> specific), thus every function should be "_sys" and declaiming it twice
> violates Occam's rule ("entities must not be multiplied beyond
> necessity").** This also implies that functions which are not
> implementation specific ("_sys") shall be moved to shared code base.

This I don't know :-/

--
<rata> hmm, el enchufe hace chispas...
<-- rata ha dejado este servidor ("Leaving").
<marga> ouch
Visto en #lugfi, irc.freenode.net

[Lisandro Damián Nicanor Pérez Meyer]

On Mar 17 Jul 2012 14:33:15 Lisandro Damián Nicanor Pérez Meyer escribió:
> On Mar 17 Jul 2012 07:28:14 Michal Policht escribió:
> > Have you tried to explicitly add __attribute__ ((visibility ("hidden")))
> > before QextSerialPortPrivate declaration and see what happens?
> >
> > (http://gcc.gnu.org/wiki/Visibility).
>
> I have not tried modifying the code yet. All I did was to export
> -fvisibility=hidden -fvisibility-inlines-hidden

Even worst: examples will not build if I try to hide private symbols with the
above flags :-/

--
Contrary to popular belief, Unix is user friendly. It just happens to be
very selective about who it decides to make friends with.
Unknown - http://www.linfo.org/q_unix.html

[Lisandro Damián Nicanor Pérez Meyer]

OK, I tried some stuff and this is what I've got (mostly to clean up ideas, as
I may have confused lots of you ;) )

I've made a config.pri that looks like this:

QEXTSERIALPORT_LIBRARY = yes
QEXTSERIALPORT_WITH_UDEV = yes

If I later issue qmake ; make, everything goes fine.

Now, I want to pass "-fvisibility=hidden -fvisibility-inlines-hidden" because
of [0]. This greatly reduces maintainership time filtering unwanted symbols.

So I now issue:

$ make distclean
$ qmake QMAKE_CXXFLAGS="-fvisibility=hidden -fvisibility-inlines-hidden"
$ make

and I get:

/usr/bin/moc-qt4 -DQEXTSERIALPORT_USING_SHARED -D__linux__ -DQT_NO_DEBUG -
DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -
I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -
I../../src -I. QespTest.h -o moc_QespTest.cpp
g++ -c -fvisibility=hidden -fvisibility-inlines-hidden -O2 -Wall -W -
D_REENTRANT -DQEXTSERIALPORT_USING_SHARED -D__linux__ -DQT_NO_DEBUG -
DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED -I/usr/share/qt4/mkspecs/linux-g++-64 -
I. -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -I/usr/include/qt4 -
I../../src -I. -o moc_QespTest.o moc_QespTest.cpp
g++ -m64 -Wl,-O1 -Wl,-
rpath,/home/lisandro/damian/debian/propios/qextserialport/git/lib -o qespta
main.o MainWindow.o MessageWindow.o QespTest.o moc_MainWindow.o
moc_MessageWindow.o moc_QespTest.o -L/usr/lib/x86_64-linux-gnu -
L/home/lisandro/damian/debian/propios/qextserialport/git/lib -
lqextserialport-1.2 -ludev -lQtGui -lQtCore -lpthread
QespTest.o: In function `QespTest::QespTest(QWidget*)':
QespTest.cpp:(.text+0x63): undefined reference to
`QextSerialPort::QextSerialPort(QString const&, QextSerialPort::QueryMode,
QObject*)'
QespTest.cpp:(.text+0x88): undefined reference to
`QextSerialPort::setBaudRate(BaudRateType)'
QespTest.cpp:(.text+0x93): undefined reference to
`QextSerialPort::setFlowControl(FlowType)'
QespTest.cpp:(.text+0x9e): undefined reference to
`QextSerialPort::setParity(ParityType)'
QespTest.cpp:(.text+0xac): undefined reference to
`QextSerialPort::setDataBits(DataBitsType)'
QespTest.cpp:(.text+0xba): undefined reference to
`QextSerialPort::setStopBits(StopBitsType)'
QespTest.cpp:(.text+0xc8): undefined reference to
`QextSerialPort::setTimeout(long)'
collect2: error: ld returned 1 exit status
make[2]: *** [qespta] Error 1
make[2]: Leaving directory
`/home/lisandro/damian/debian/propios/qextserialport/git/examples/qespta'
make[1]: *** [sub-qespta-make_default] Error 2
make[1]: Leaving directory
`/home/lisandro/damian/debian/propios/qextserialport/git/examples'
make: *** [sub-examples-make_default-ordered] Error 2

So clearly (at least) those symbols are getting lost. So far I'm totally lost
as to why :-/

Any ideas?

Kinds regards, Lisandro.

[0] <http://gcc.gnu.org/wiki/Visibility>


--
"Los promotores del software privativo demonizan algo tan básico y ético como
el hecho de compartir imponiendo términos como el de 'pirata'. Equiparan
ayudar al prójimo con atacar barcos. Cuando me preguntan qué pienso de la
piratería musical e informática digo que atacar barcos es muy malo y,
que yo sepa, los piratas no usan computadoras.”
Richard Stallman, 05/11/2008, anexo de la Cámara de Diputados, Argentina

[Michal Policht]

I tried to reproduce these errors on my current machine (Win XP and Qt
4.4.3), but oldie gcc 3.4.3 doesn't have "fvisibility" command ;)

If you ask for ideas, then maybe QEXTSERIALPORT_EXPORT doesn't work
correctly? Try to replace QEXTSERIALPORT_EXPORT with __attribute__
((visibility ("default"))) in qextserialport.h and see what happens.

Regards.

[Lisandro Damián Nicanor Pérez Meyer]

On Mié 25 Jul 2012 08:46:35 Michal Policht escribió:
> I tried to reproduce these errors on my current machine (Win XP and Qt
> 4.4.3), but oldie gcc 3.4.3 doesn't have "fvisibility" command ;)
>
> If you ask for ideas, then maybe QEXTSERIALPORT_EXPORT doesn't work
> correctly? Try to replace QEXTSERIALPORT_EXPORT with __attribute__
> ((visibility ("default"))) in qextserialport.h and see what happens.

This seems to improve the situation. So what I have to check is what's
happening in qextserialport_global.h

And I think I've got it: if I modify that file to read:

#ifdef QEXTSERIALPORT_BUILD_SHARED
# define QEXTSERIALPORT_EXPORT Q_DECL_EXPORT
#warning EXPOOOOOORTTT
#elif defined(QEXTSERIALPORT_USING_SHARED)
# define QEXTSERIALPORT_EXPORT Q_DECL_IMPORT
#else
# define QEXTSERIALPORT_EXPORT
#endif

Notice the #warning. Then if I do qmake QMAKE_CXXFLAGS="-fvisibility=hidden -
fvisibility-inlines-hidden" with a config.pri as described in my previous
mail, I should see the warning when compiling.... and I don't.

So QEXTSERIALPORT_LIBRARY is not correctly setting
QEXTSERIALPORT_BUILD_SHARED.

--
Only Irish coffee provides in a single glass all four essential food groups
-- alcohol, caffeine, sugar, and fat.
Alex Levine

Lisandro Damián Nicanor Pérez Meyer

http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

[Lisandro Damián Nicanor Pérez Meyer]

On Mié 25 Jul 2012 11:28:21 Lisandro Damián Nicanor Pérez Meyer escribió:
[snip]

> So QEXTSERIALPORT_LIBRARY is not correctly setting
> QEXTSERIALPORT_BUILD_SHARED.

It is not. But it doesn't seem to distinguish between static or dynamic.
And if I do

qmake QMAKE_CXXFLAGS="-fvisibility=hidden -fvisibility-inlines-hidden"
buildlib/

I also don't get the warning.

If I add more warning into src/qextserialport_global.h, I'm getting that
QEXTSERIALPORT_EXPORT is not being set, so explaining everything.

By the way, the build system seems a little too messy :-/

--
Los errores ortográficos y de redacción fueron insertados con la única
intención de testear sus conocimientos de la lengua castellana.

[1+1=2]

Hi Lisandro,

I try to play with libQtGui.so.4.8 and libQtWidgets.so.5 using

readelf -Ws libQtGui.so.4.8.0

And find that they exported many *_sys member-functions of private
class *Private too. So I think it's not a fault of us ;-)

Regards,

Debao

[Lisandro Damián Nicanor Pérez Meyer]

On Mié 15 Aug 2012 06:16:56 1+1=2 escribió:
> Hi Lisandro,
>
> I try to play with libQtGui.so.4.8 and libQtWidgets.so.5 using
>
> readelf -Ws libQtGui.so.4.8.0
>
> And find that they exported many *_sys member-functions of private
> class *Private too. So I think it's not a fault of us ;-)

Hi Debao!

In which system/distro/version are you trying?

It's very strange, I have never seen Qt leaking symbols like that.

Kinds regards, Lisandro.

--
Wiki is not WysiWyg. It's an intelligence test of sorts to be able to edit a
wiki page. It's not rocket science, but it doesn't appeal to the VideoAddicts.
If it doesn't appeal, they don't participate, which leaves those of us who
read and write to get on with rational discourse.
http://www.c2.com/cgi/wiki?WhyWikiWorks

[Lisandro Damián Nicanor Pérez Meyer]

On Wed 15 Aug 2012 06:16:56 1+1=2 escribió:
> Hi Lisandro,
>
> I try to play with libQtGui.so.4.8 and libQtWidgets.so.5 using
>
> readelf -Ws libQtGui.so.4.8.0
>
> And find that they exported many *_sys member-functions of private
> class *Private too. So I think it's not a fault of us ;-)

OK, I revisited the symbols files for Qt and that's a Qt bug. And no, it
doesn't means we should do the same ;-)

Please check the thread that starts with "Symbols re explained." The situation
up to the day I wrote that is clearly a bug.

Yes, we can have *some* leaked symbols (it is worst for downstream
maintainers, but well...) but setting the visivility flags should not make the
build to fail, but help on the symbols.

I have taken a look to the changes you made, thanks you ver much for taht :-)

Please allow me some time to review if we still have this problem.

Kinds regards, Lisandro.

--
Alas, I am dying beyond my means.
Oscar Wilde, as he sipped champagne on his deathbed