Re: exported symbols from private headers

[James Henstridge <james daa com au>]

On 21/02/04 21:45, Owen Taylor wrote:

> On Sat, 2004-02-21 at 05:26, James Henstridge wrote:
>
>  
>
> > It is probably worth noting that all symbols get exported under Linux, 
> > even with versions of libtool with a working -export-symbols-regex 
> > implementation.  This is because -Wl,--export-dynamic is passed as a 
> > link flag, and seems to take precedence.
> >    
>
> Do you have any idea what has changed recently? I certainly tested this
> a while ago when I switched to using a patched libtool for GTK+
> releases, and it was working properly. (with nm -D).
>  
From my testing, it appears to be the --export-dynamic flag to the 
linker that changes the behaviour.  Without that flag, 
-export-symbols-regex works correctly.  This can't be classed as a 
libtool bug though, since it is just passing the flag through straight 
to the linker like it is asked to.

For reference, I compiled libgtk-x11.so with and without the 
-export-dynamic flag, and got the following results:

   $ nm -D libgtk-x11-2.0.so.0.302.0-export-dynamic | grep _gtk | wc -l
       423
   $ nm -D libgtk-x11-2.0.so.0.302.0 | grep _gtk | wc -l
         0

This was using libtool-1.5.2, which has a working -export-symbols 
implementation.  You should see similar results with older libtools if 
they are patched to make -export-symbols work correctly.

The only thing that changed that I can think of is that pkg-config 
changed a bit since I wrote that patch for libtool's -export-dynamic 
behaviour.  I remember that at one point there was a bug in pkg-config 
that meant that "-pthread" wasn't getting output when you ran 
"pkg-config --cflags gthread-2.0".  My guess is that that same bug 
caused pkg-config to strip the --export-dynamic flag, which masked the 
problem.

One solution (a bit of a hack) is to filter out the --export-dynamic 
flag from the various DEP_LIBS variables in the configure script.  
Attached is a simple patch that should do so for GTK (patches for glib, 
pango and atk would be fairly similar).

The alternative would be to not put --export-dynamic into the libs list 
for gmodule-2.0, but that might cause problems elsewhere (the main 
example I can think of is apps using libglade's autoconnect 
functionality, but not explicitly asking for --export-dynamic).

James.

--
Email: james daa com au
WWW:   http://www.daa.com.au/~james/


Index: configure.in
===================================================================
RCS file: /cvs/gnome/gtk+/configure.in,v
retrieving revision 1.357
diff -u -p -r1.357 configure.in
--- configure.in	20 Feb 2004 18:11:18 -0000	1.357
+++ configure.in	21 Feb 2004 15:06:24 -0000
@@ -1413,6 +1413,18 @@ AC_SUBST(GTK_DEP_CFLAGS)
 AC_SUBST(GTK_DEBUG_FLAGS)
 AC_SUBST(GTK_XIM_FLAGS)
 
+################################################################
+# Strip -export-dynamic from the link lines of various libraries
+################################################################
+export_dynamic=`(./libtool --config; echo eval echo \\$export_dynamic_flag_spec) | sh`
+if test -n "$export_dynamic"; then
+  GDK_PIXBUF_DEP_LIBS=`echo $GDK_PIXBUF_DEP_LIBS | sed -e "s/$export_dynamic//"`
+  GDK_PIXBUF_XLIB_DEP_LIBS=`echo $GDK_PIXBUF_XLIB_DEP_LIBS | sed -e "s/$export_dynamic//"`
+  GDK_DEP_LIBS=`echo $GDK_DEP_LIBS | sed -e "s/$export_dynamic//"`
+  GTK_DEP_LIBS=`echo $GTK_DEP_LIBS | sed -e "s/$export_dynamic//"`
+fi
+
+
 ##################################################
 # Checks for gtk-doc and docbook-tools
 ##################################################