Re: Writing symbols files for C++ libraries.
Hi! On Wed, Apr 08, 2009 at 02:42:16AM +0200, Michael Biebl wrote: Daniel Kobras schrieb: Have you used this option successfully with a C++ library? In this case, libtool creates input for the linker option -retain-symbols-file rather than a version script like it does with C libs. In my tests, -retain-symbols-file only affected static symbols, but didn't touch the list of dynamic symbols. Which is quite pointless for my use case. Is this a known bug/misfeature or might I by doing something wrong here? libtool's -export-symbols(-regex) only works with C libraries afaik. For C++ libs the only way I know of is to use GCC's visibility support [1]. As Mike noted earlier on in this thread, the troublemaker symbols are forced to default visibility in the standard headers. Hence, -fvisibility doesn't gain us much here. I conclude from this thread that using symbols files for C++ ABIs is pretty much a bad idea at the moment. Thanks for the input! Daniel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Writing symbols files for C++ libraries.
Hi!
I'm currently fighting with deb symbols files for a C++ library I'm
packaging, and I'd like to get some insight in how others are coping
with this task. In particular, I wonder how to get rid of symbols from
standard template instances that leak into the ABI, eg.
$ cat test.cpp
#include string
std::string foome(const std::string bar)
{
return foo + bar + foo;
}
$ g++ -fPIC -c test.cpp
$ readelf -Wds test.o | grep -v UND | grep -v HIDDEN | grep -E
'(FUNC|OBJECT)'
18: 23 FUNCWEAK DEFAULT9
_ZNSt11char_traitsIcE6lengthEPKc
22: 155 FUNCWEAK DEFAULT 11
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_
30: 104 FUNCWEAK DEFAULT 14
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_
33: 124 FUNCGLOBAL DEFAULT5 _Z5foomeRKSs
I can hide the operator+() and related instances from with a version
script, of course, but due to C++ name mangling they tend to be
arch-specific and thus hard to maintain. Does anyone know of a more
lightweight solution to limit visibility of template instances and
ensure a clean ABI for C++ libraries? What are the current best
practises when writing symbols files for C++ libraries, or is it simply
not recommended?
Regards,
Daniel.
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Writing symbols files for C++ libraries.
On Tue, Apr 07, 2009 at 01:22:51AM +0200, Daniel Kobras kob...@debian.org
wrote:
Hi!
I'm currently fighting with deb symbols files for a C++ library I'm
packaging, and I'd like to get some insight in how others are coping
with this task. In particular, I wonder how to get rid of symbols from
standard template instances that leak into the ABI, eg.
$ cat test.cpp
#include string
std::string foome(const std::string bar)
{
return foo + bar + foo;
}
$ g++ -fPIC -c test.cpp
$ readelf -Wds test.o | grep -v UND | grep -v HIDDEN | grep -E
'(FUNC|OBJECT)'
18: 23 FUNCWEAK DEFAULT9
_ZNSt11char_traitsIcE6lengthEPKc
22: 155 FUNCWEAK DEFAULT 11
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EPKS3_RKS6_
30: 104 FUNCWEAK DEFAULT 14
_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_ERKS6_PKS3_
33: 124 FUNCGLOBAL DEFAULT5 _Z5foomeRKSs
I can hide the operator+() and related instances from with a version
script, of course, but due to C++ name mangling they tend to be
arch-specific and thus hard to maintain. Does anyone know of a more
lightweight solution to limit visibility of template instances and
ensure a clean ABI for C++ libraries? What are the current best
practises when writing symbols files for C++ libraries, or is it simply
not recommended?
Unfortunately, gcc upstream consider this as a feature, and not a bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36022
I found nothing better than using a version script. I'm lucky that the
library in question (WebKit) only really exports C symbols, and C++ is only
internal details, so I'm filtering everything that starts with _Z, now.
Mike
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Writing symbols files for C++ libraries.
Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit : I found nothing better than using a version script. I'm lucky that the library in question (WebKit) only really exports C symbols, and C++ is only internal details, so I'm filtering everything that starts with _Z, now. BTW, for such simple things, you can let libtool create the version script for you, using -export-symbols-regex. -- .''`. Debian 5.0 Lenny has been released! : :' : `. `' Last night, Darth Vader came down from planet Vulcan and told `-me that if you don't install Lenny, he'd melt your brain. signature.asc Description: Ceci est une partie de message numériquement signée
Re: Writing symbols files for C++ libraries.
On Tue, Apr 07, 2009 at 12:15:19PM +0200, Josselin Mouette j...@debian.org wrote: Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit : I found nothing better than using a version script. I'm lucky that the library in question (WebKit) only really exports C symbols, and C++ is only internal details, so I'm filtering everything that starts with _Z, now. BTW, for such simple things, you can let libtool create the version script for you, using -export-symbols-regex. The problem with libtool's option is that it is inclusive, i.e. what you give it will be exported, not hidden, which is sometimes much easier to handle. Mike -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Writing symbols files for C++ libraries.
On Tue, Apr 07, 2009 at 12:15:19PM +0200, Josselin Mouette wrote: Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit : I found nothing better than using a version script. I'm lucky that the library in question (WebKit) only really exports C symbols, and C++ is only internal details, so I'm filtering everything that starts with _Z, now. BTW, for such simple things, you can let libtool create the version script for you, using -export-symbols-regex. Have you used this option successfully with a C++ library? In this case, libtool creates input for the linker option -retain-symbols-file rather than a version script like it does with C libs. In my tests, -retain-symbols-file only affected static symbols, but didn't touch the list of dynamic symbols. Which is quite pointless for my use case. Is this a known bug/misfeature or might I by doing something wrong here? Regards, Daniel. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Writing symbols files for C++ libraries.
Daniel Kobras schrieb: On Tue, Apr 07, 2009 at 12:15:19PM +0200, Josselin Mouette wrote: Le mardi 07 avril 2009 à 11:57 +0200, Mike Hommey a écrit : I found nothing better than using a version script. I'm lucky that the library in question (WebKit) only really exports C symbols, and C++ is only internal details, so I'm filtering everything that starts with _Z, now. BTW, for such simple things, you can let libtool create the version script for you, using -export-symbols-regex. Have you used this option successfully with a C++ library? In this case, libtool creates input for the linker option -retain-symbols-file rather than a version script like it does with C libs. In my tests, -retain-symbols-file only affected static symbols, but didn't touch the list of dynamic symbols. Which is quite pointless for my use case. Is this a known bug/misfeature or might I by doing something wrong here? libtool's -export-symbols(-regex) only works with C libraries afaik. For C++ libs the only way I know of is to use GCC's visibility support [1]. Cheers, Michael [1] http://gcc.gnu.org/wiki/Visibility -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature
