Debian Bug report logs - #262026
libraries not correctly linked

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Marco d'Itri <md@Linux.IT>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libraries not correctly linked

Date: Thu, 29 Jul 2004 14:59:19 +0200

Package: libswig1.3.21
Version: 1.3.21-5
Severity: serious
Justification: RC issues list, section 5.f

[This is a standard text.]

This bug has serious severity because it is a policy violation and
an item in aj's list of release showstoppers, section 5.f:
http://people.debian.org/~ajt/sarge_rc_policy.txt .

One or more libraries in this package are buggy.
All libraries need to be linked against other libraries which they
reference. You can check this by running this command:

ldd -d -r /usr/lib/libYOUR-LIBRARY.so

Then you will have to find which other libraries contain the undefined
symbols and rebuild your library by explicitly linking it against them
(e.g. -lglib).

The broken libraries are:

/usr/lib/libswigphp4-1.3.21.so		(? php stuff)
/usr/lib/libswigpl-1.3.21.so		(-lperl, -lpthread)
/usr/lib/libswigpy-1.3.21.so		(-lpython2.3)
/usr/lib/libswigrb-1.3.21.so		(?)


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.7
Locale: LANG=it_IT@euro, LC_CTYPE=it_IT@euro

Versions of packages libswig1.3.21 depends on:
ii  libc6                       2.3.2.ds1-13 GNU C Library: Shared libraries an

-- 
ciao, |
Marco | [7359 in2UuSBrr82H.]

Message #10 received at 262026@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: 262026@bugs.debian.org

Subject: Re: libraries not correctly linked

Date: Sun, 1 Aug 2004 01:32:44 -0700

[Message part 1 (text/plain, inline)]

tags 262026 normal
thanks

Hello,

I was asked by Adam Conrad to comment on this bug.

The .so files in question are explained in Doc/Manual/Advanced.html in
the swig source tree.  These files provide a shared runtime typing
system that allows swig modules to build on one another; for various
reasons, this can only work if there is a single copy of this runtime
typing system loaded into memory.  However, the runtime library also
needs to be able to call back into the corresponding language, for error
reporting, etc.  The result is that /usr/lib/libswig<lang>.so are
"shared libraries" that also have an ELF dependency on the interpreter
for the corresponding language.

This is a rather wonky edge case; as the proposer of that particular
clause in policy, I can say that this is not something that was a
consideration when it was written.  However, as it happens, the wording
of Policy 10.2 is the following:

        Shared libraries must normally be linked with all libraries they
        use symbols from.

This is not a case of a library using symbols from a library; this is
the case of a library using symbols from a *language interpreter*.
E.g., for libswigphp4.so, the missing zend_* symbols are provided by
/usr/bin/php4, which is not a library at all.  These libraries are not
linked against the source of those symbols because they *cannot* be.

Now, I happen to think that using symbols from the interpreter this way
is rather inelegant in something that's going to be treated as a shared
library by other language bindings; so I'm only downgrading this bug
rather than closing it.  It would be nice to be able to use prelink for
swig (although it seems there are better, cleaner solutions than prelink
afoot), and it would be nice to be able to use the linker options
described in Policy 10.2 to check your libraries for correctness at
build time.  Achieving this would be rather complicated, however, as you
would need to replace all of the runtime libs' references to
language-supplied symbols with either callbacks into the swing
extension, or calls to dlopen().  I'm not sure that this is worth the
effort.

Thanks,
-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #19 received at 262026@bugs.debian.org (full text, mbox, reply):

From: Laszlo 'GCS' Boszormenyi <gcs@lsc.hu>

To: Steve Langasek <vorlon@debian.org>, 262026@bugs.debian.org

Subject: Re: Bug#262026: libraries not correctly linked

Date: Sun, 1 Aug 2004 12:59:04 +0200

[Message part 1 (text/plain, inline)]

* Steve Langasek <vorlon@debian.org> [2004-08-01 01:32:44 -0700]:

> I was asked by Adam Conrad to comment on this bug.
 Thanks for the answer, it was me who asked him what can be done.

[...]
> This is not a case of a library using symbols from a library; this is
> the case of a library using symbols from a *language interpreter*.
> E.g., for libswigphp4.so, the missing zend_* symbols are provided by
> /usr/bin/php4, which is not a library at all.  These libraries are not
> linked against the source of those symbols because they *cannot* be.
 Well, as I could check just now, the php4 package contains a shared
php4 library; and I can link libswigphp4.so against it. Now, if I set
LD_LIBRARY_PATH to /usr/lib/apache/1.3/, where libphp4.so resides and
check the linkink, then it seems the Zend unknown symbols are gone, but I 
get other undefined symbols as:
undefined symbol: ap_block_alarms       (/usr/lib/apache/1.3/libphp4.so)
undefined symbol: ap_unblock_alarms     (/usr/lib/apache/1.3/libphp4.so)
undefined symbol: ap_user_id    (/usr/lib/apache/1.3/libphp4.so)
... and so on. Going to look into it soon.

Regards,
Laszlo/GCS

[signature.asc (application/pgp-signature, inline)]

Message #24 received at 262026@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Laszlo 'GCS' Boszormenyi <gcs@lsc.hu>

Cc: 262026@bugs.debian.org

Subject: Re: Bug#262026: libraries not correctly linked

Date: Sun, 1 Aug 2004 04:16:11 -0700

[Message part 1 (text/plain, inline)]

On Sun, Aug 01, 2004 at 12:59:04PM +0200, Laszlo 'GCS' Boszormenyi wrote:
> * Steve Langasek <vorlon@debian.org> [2004-08-01 01:32:44 -0700]:

> > I was asked by Adam Conrad to comment on this bug.
>  Thanks for the answer, it was me who asked him what can be done.

> [...]
> > This is not a case of a library using symbols from a library; this is
> > the case of a library using symbols from a *language interpreter*.
> > E.g., for libswigphp4.so, the missing zend_* symbols are provided by
> > /usr/bin/php4, which is not a library at all.  These libraries are not
> > linked against the source of those symbols because they *cannot* be.
>  Well, as I could check just now, the php4 package contains a shared
> php4 library;

No, it does not.  This is an Apache plugin, not a library; do NOT link
things against it, as the php4 package will never provide a shlibs file
supporting this.

 and I can link libswigphp4.so against it. Now, if I set
> LD_LIBRARY_PATH to /usr/lib/apache/1.3/, where libphp4.so resides and
> check the linkink, then it seems the Zend unknown symbols are gone, but I 
> get other undefined symbols as:
> undefined symbol: ap_block_alarms       (/usr/lib/apache/1.3/libphp4.so)
> undefined symbol: ap_unblock_alarms     (/usr/lib/apache/1.3/libphp4.so)
> undefined symbol: ap_user_id    (/usr/lib/apache/1.3/libphp4.so)
> ... and so on. Going to look into it soon.

Don't bother.  Those symbols come from Apache, and there's no way you
can link against apache.

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #29 received at 262026@bugs.debian.org (full text, mbox, reply):

From: Laszlo 'GCS' Boszormenyi <gcs@lsc.hu>

To: Steve Langasek <vorlon@debian.org>

Cc: 262026@bugs.debian.org

Subject: Re: Bug#262026: libraries not correctly linked

Date: Sun, 1 Aug 2004 13:22:53 +0200

[Message part 1 (text/plain, inline)]

* Steve Langasek <vorlon@debian.org> [2004-08-01 04:16:11 -0700]:

> No, it does not.  This is an Apache plugin, not a library; do NOT link
> things against it, as the php4 package will never provide a shlibs file
> supporting this.
 Yes, it is an Apache plugin; and then I stop finding a solution for
libswigphp4.so, as you have alredy wrote it can not be fixed now.

> Don't bother.  Those symbols come from Apache, and there's no way you
> can link against apache.
 OK. Only one question left: as this bug is about swig libraries in
general, should I clone it, leave one for this PHP4 issue, and close the
other from debian/changelog as soon as the Python/Perl/etc libraries are
fixed? I think yes, I should do it.

Thanks for your time,
Laszlo/GCS

[signature.asc (application/pgp-signature, inline)]

Message #34 received at 262026@bugs.debian.org (full text, mbox, reply):

From: Thom May <thom@debian.org>

To: 262026@bugs.debian.org

Subject: patch to link libraries correctly

Date: Mon, 2 Aug 2004 16:15:29 +0100

tags 262026 patch
thanks

Hi, 
there's a patch at http://www.no-name-yet.com/patches/swig-262026.diff that
fixes the linking for ruby, perl, python and tcl. PHP is trickier since
there is no PHP shared library to link against. 
-Thom

Message #41 received at 262026-quiet@bugs.debian.org (full text, mbox, reply):

From: Laszlo 'GCS' Boszormenyi <gcs@lsc.hu>

To: Thom May <thom@debian.org>, 262026-quiet@bugs.debian.org

Subject: Re: Bug#262026: patch to link libraries correctly

Date: Mon, 2 Aug 2004 18:26:35 +0200

Hi Thom,

* Thom May <thom@debian.org> [2004-08-02 16:15:29 +0100]:

> there's a patch at http://www.no-name-yet.com/patches/swig-262026.diff that
> fixes the linking for ruby, perl, python and tcl. PHP is trickier since
> there is no PHP shared library to link against. 
 Thanks for your work. I am also sent a patch to Torsten; hopefully he
will accept one of our method of fixing this bug, as a new Subversion
release is pending upload, and it would be good to have it link against
the fixed Swig.
 The PHP4 part can not be fixed, as Steve Langasek already noted it. :-|

Regards,
Laszlo/GCS

Message #46 received at 262026@bugs.debian.org (full text, mbox, reply):

From: Steve Langasek <vorlon@debian.org>

To: Laszlo 'GCS' Boszormenyi <gcs@lsc.hu>

Cc: 262026@bugs.debian.org

Subject: Re: Bug#262026: libraries not correctly linked

Date: Mon, 2 Aug 2004 21:17:53 -0700

[Message part 1 (text/plain, inline)]

On Sun, Aug 01, 2004 at 01:22:53PM +0200, Laszlo 'GCS' Boszormenyi wrote:
> * Steve Langasek <vorlon@debian.org> [2004-08-01 04:16:11 -0700]:

> > No, it does not.  This is an Apache plugin, not a library; do NOT link
> > things against it, as the php4 package will never provide a shlibs file
> > supporting this.
>  Yes, it is an Apache plugin; and then I stop finding a solution for
> libswigphp4.so, as you have alredy wrote it can not be fixed now.

> > Don't bother.  Those symbols come from Apache, and there's no way you
> > can link against apache.
>  OK. Only one question left: as this bug is about swig libraries in
> general, should I clone it, leave one for this PHP4 issue, and close the
> other from debian/changelog as soon as the Python/Perl/etc libraries are
> fixed? I think yes, I should do it.

PHP is the norm here, not the exception.  You will find that the runtime
libraries for other language bindings have the same issue; the reason
they all have unresolved symbols is because these symbols are provided
by the languaage interpreter which loads the swig extensions.  I don't
think you will find that any of these languages have a self-contained
"extension library" providing the symbols that you can link against,
because there would be almost no benefit.

So, I don't think you're going to want to clone this bug for the other
languages, because this isn't a bug in any of them; it's a design
decision.

-- 
Steve Langasek
postmodern programmer

[signature.asc (application/pgp-signature, inline)]

Message #53 received at 262026-done@bugs.debian.org (full text, mbox, reply):

From: Torsten Landschoff <torsten@debian.org>

To: 262026-done@bugs.debian.org

Subject: Runtime is no more

Date: Sat, 12 Feb 2005 17:11:37 +0100

[Message part 1 (text/plain, inline)]

As the runtime was removed there is nothing that can be incorrectly
linked. Closing this bug.

[signature.asc (application/pgp-signature, inline)]

Send a report that this bug log contains spam.