[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Symbol versioning bug
From: |
Simon Josefsson |
Subject: |
Symbol versioning bug |
Date: |
Wed, 03 Feb 2010 09:00:00 +0100 |
User-agent: |
Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (gnu/linux) |
After debugging this bug report
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=561291
I noticed that recent libidn, since version 1.13, did not export all
symbols that it used to. The relevant 1.13 NEWS entry was:
** libidn: Use a LD version script on platforms where it is supported.
Currently only GNU LD and the Solaris linker supports it. This helps
Debian package tools to produce better dependencies. Before we used
Libtool -export-symbols-regex that created an anonymous version tag.
Libidn uses -export-symbols-regex if the system does not support LD
version scripts, but that only affect symbol visibility.
** libidn: Compiled with -fvisibility=hidden by default if supported.
Currently only GCC supports it for ELF targets. This hides internal
symbols and has other advantages, see
<http://gcc.gnu.org/wiki/Visibility>.
There are two sub-problems:
1) The following variables (declared in stringprep.h) where NOT visible
in the shared library:
stringprep_rfc3454_A_1
stringprep_rfc3454_B_1
stringprep_rfc3454_B_2
stringprep_rfc3454_B_3
stringprep_rfc3454_C_1_1
stringprep_rfc3454_C_1_2
stringprep_rfc3454_C_2_1
stringprep_rfc3454_C_2_2
stringprep_rfc3454_C_3
stringprep_rfc3454_C_4
stringprep_rfc3454_C_5
stringprep_rfc3454_C_6
stringprep_rfc3454_C_7
stringprep_rfc3454_C_8
stringprep_rfc3454_C_9
stringprep_rfc3454_D_1
stringprep_rfc3454_D_2
2) The following variables (NOT declared in stringprep.h) where visible
in the shared library:
stringprep_iscsi_prohibit
stringprep_saslprep_space_map
Thoughts on resolving this mess?
My proposal is to:
A) Make sure the stringprep_rfc3454_* variables are visible.
B) Make sure that stringprep_iscsi_prohibit and
stringprep_saslprep_space_map are declared in stringprep.h.
I note that given that nobody has complained about this since version
1.13, it seems that use of these variables in real applications is quite
rare, which is expected. Exporting variables from libraries is not a
good idea generally (see Ulrich's DSO howto), so we could also just
officially deprecate these symbols. However, we'd still have other
variables left, and it doesn't feel right to remove them all without
bumping the shared library version. So my proposal is to just fix the
bug that was introduced in version 1.13.
Comments on this proposal are welcome.
/Simon
- Symbol versioning bug,
Simon Josefsson <=
- Re: Symbol versioning bug, Simon Josefsson, 2010/02/03
- Re: Symbol versioning bug, Simon Josefsson, 2010/02/03
- Re: Symbol versioning bug, Marco d'Itri, 2010/02/06
- Re: Bug#561291: Symbol versioning bug, Simon Josefsson, 2010/02/05
- Re: Bug#561291: Symbol versioning bug, Marco d'Itri, 2010/02/06
- Re: Bug#561291: Symbol versioning bug, Simon Josefsson, 2010/02/05