[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Intent to package: GtkGL and apps



On Wednesday 22 July 1998, at 15 h 43, the keyboard of Vincent Renardias 
<vincent@waw.com> wrote:

> Make sure that the build process didn't link statically with gtk+ and
> gtkGL. If the executable is dynamically linked with those libraries, they
> _must_ appear in the ldd output (and therefore the ${shlibs:Depends}
> substitution).

Well, there is apparently something wrong on my system (an up-to-date hamm).

Linking with gcc produces libraries which are "statically linked" according to ldd.

Linking with egcc produces libraries which depend only on libc6, which seems incorrect to me.

Here is the compile command:

/bin/sh ../libtool --mode=link gcc -g -O2  -o libgdkGL.la -rpath /usr/local/lib -version-info 0:8:0 gdkGL.lo gdkGLcontext.lo gdkGL_gdkutils.lo
mkdir .libs
gcc -shared -Wl,-soname -Wl,libgdkGL.so.0 -o .libs/libgdkGL.so.0.0.8 gdkGL.lo gdkGLcontext.lo gdkGL_gdkutils.lo
(cd .libs && ln -s libgdkGL.so.0.0.8 libgdkGL.so.0)
(cd .libs && ln -s libgdkGL.so.0.0.8 libgdkGL.so)

Seems OK, uh? -shared is used. But ldd disagrees:

% ldd ./gdkGL/.libs/libgdkGL.so.0.0.8
        statically linked

With egcc, same compiler command line:

% ldd ./gdkGL/.libs/libgdkGL.so.0.0.8
        libc.so.6 => /lib/libc.so.6 (0x40007000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00000000)


This is not a bug in the (beta) gtkGL package, I see the same behaviour with gtk+ itself.




--  
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org


Reply to: