help-libidn
[Top][All Lists]
Advanced

[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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]