libraries not correctly linked

[Debian Bug Importer]

Automatically imported from Debian bug report #262026 http://bugs.debian.org/262026

[Debian Bug Importer (debzilla)]

Automatically imported from Debian bug report #262026 http://bugs.debian.org/262026

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Thu, 29 Jul 2004 14:59:19 +0200
From: Marco d'Itri <email address hidden>
To: Debian Bug Tracking System <email address hidden>
Subject: libraries not correctly linked

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.]

[Steve Langasek (vorlon)]

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

[Steve Langasek (vorlon)]

severity 262026 normal
thanks

[Laszlo Boszormenyi (gcs)]

* Steve Langasek <email address hidden> [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

[Steve Langasek (vorlon)]

On Sun, Aug 01, 2004 at 12:59:04PM +0200, Laszlo 'GCS' Boszormenyi wrote:
> * Steve Langasek <email address hidden> [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

[Laszlo Boszormenyi (gcs)]

* Steve Langasek <email address hidden> [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

[Thom May (thombot)]

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

[Thom May (thombot)]

Mostly fixed by the uploaded of swig1.3 1.3.21-5ubuntu1 ; typically, just PHP4
is broken but since there is no PHP4 so, it's tricky to link to it.

[Laszlo Boszormenyi (gcs)]

Hi Thom,

* Thom May <email address hidden> [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

[Steve Langasek (vorlon)]

On Sun, Aug 01, 2004 at 01:22:53PM +0200, Laszlo 'GCS' Boszormenyi wrote:
> * Steve Langasek <email address hidden> [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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 1 Aug 2004 01:32:44 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: Re: libraries not correctly linked

--ikeVEW9yuYc//A+q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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,
--=20
Steve Langasek
postmodern programmer

--ikeVEW9yuYc//A+q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBDKqpKN6ufymYLloRApdbAJ9nwfSniI/bUlB4FM0aCkk8tLXQdACeJmnf
bs/fpQH2oiSye/qKUgm4Z+o=
=gTPh
-----END PGP SIGNATURE-----

--ikeVEW9yuYc//A+q--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 1 Aug 2004 02:05:55 -0700
From: Steve Langasek <email address hidden>
To: <email address hidden>
Subject: meh meh

severity 262026 normal
thanks

[Debian Bug Importer (debzilla)]

Message-ID: <20040801105904.GA27073@pooh>
Date: Sun, 1 Aug 2004 12:59:04 +0200
From: Laszlo 'GCS' Boszormenyi <email address hidden>
To: Steve Langasek <email address hidden>, <email address hidden>
Subject: Re: Bug#262026: libraries not correctly linked

--2fHTh5uZTiUOsy+g
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

* Steve Langasek <email address hidden> [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=
=20
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)
=2E.. and so on. Going to look into it soon.

Regards,
Laszlo/GCS

--2fHTh5uZTiUOsy+g
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBDMz4MDatjqUaT90RAgW1AJ0apCL6zpvT23qXWZy9VHNY4ny27ACfQIAy
w9MMNU/cvThsZVe3kEbWCSc=
=D5L6
-----END PGP SIGNATURE-----

--2fHTh5uZTiUOsy+g--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sun, 1 Aug 2004 04:16:11 -0700
From: Steve Langasek <email address hidden>
To: Laszlo 'GCS' Boszormenyi <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#262026: libraries not correctly linked

--jy6Sn24JjFx/iggw
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 01, 2004 at 12:59:04PM +0200, Laszlo 'GCS' Boszormenyi wrote:
> * Steve Langasek <email address hidden> [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=
=20
> 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.

--=20
Steve Langasek
postmodern programmer

--jy6Sn24JjFx/iggw
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBDND5KN6ufymYLloRApsGAJwIVJpCP410KS5PhdGnvfP/8ix5tQCfdFgW
Ch9wpVTc490vm61mU3VuNoA=
=k7ii
-----END PGP SIGNATURE-----

--jy6Sn24JjFx/iggw--

[Debian Bug Importer (debzilla)]

Message-ID: <20040801112253.GA27508@pooh>
Date: Sun, 1 Aug 2004 13:22:53 +0200
From: Laszlo 'GCS' Boszormenyi <email address hidden>
To: Steve Langasek <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#262026: libraries not correctly linked

--IJpNTDwzlM2Ie8A6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

* Steve Langasek <email address hidden> [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

--IJpNTDwzlM2Ie8A6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFBDNKNMDatjqUaT90RAtasAJsGjUu/DHC/iLhTu6TnjkGrvuwhJwCfSxQn
sgkNyPYj55MhQg93des68Cs=
=ARJE
-----END PGP SIGNATURE-----

--IJpNTDwzlM2Ie8A6--

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 2 Aug 2004 16:15:29 +0100
From: Thom May <email address hidden>
To: <email address hidden>
Subject: patch to link libraries correctly

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

[Debian Bug Importer (debzilla)]

Message-ID: <20040802162635.GA30327@pooh>
Date: Mon, 2 Aug 2004 18:26:35 +0200
From: Laszlo 'GCS' Boszormenyi <email address hidden>
To: Thom May <email address hidden>, <email address hidden>
Subject: Re: Bug#262026: patch to link libraries correctly

Hi Thom,

* Thom May <email address hidden> [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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Mon, 2 Aug 2004 21:17:53 -0700
From: Steve Langasek <email address hidden>
To: Laszlo 'GCS' Boszormenyi <email address hidden>
Cc: <email address hidden>
Subject: Re: Bug#262026: libraries not correctly linked

--u3/rZRmxL6MmkK24
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Aug 01, 2004 at 01:22:53PM +0200, Laszlo 'GCS' Boszormenyi wrote:
> * Steve Langasek <email address hidden> [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.

--=20
Steve Langasek
postmodern programmer

--u3/rZRmxL6MmkK24
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)

iD8DBQFBDxHtKN6ufymYLloRAs47AJ4mAf8QMFtIhwuFlWTGqF/t0zdd+QCbBr9k
5wJV+HyaaLw7MBzN3Vw2KAY=
=hDOn
-----END PGP SIGNATURE-----

--u3/rZRmxL6MmkK24--

[Martin Michlmayr (tbm)]

reassign 262026 libswig1.3.22

--
Martin Michlmayr
http://www.cyrius.com/

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Fri, 29 Oct 2004 00:05:38 +0100
From: Martin Michlmayr <email address hidden>
To: <email address hidden>
Subject: 1.3.21 -> 1.3.22

reassign 262026 libswig1.3.22

--
Martin Michlmayr
http://www.cyrius.com/

[Torsten Landschoff (torsten)]

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

[Debian Bug Importer (debzilla)]

Message-ID: <email address hidden>
Date: Sat, 12 Feb 2005 17:11:37 +0100
From: Torsten Landschoff <email address hidden>
To: <email address hidden>
Subject: Runtime is no more

--maH1Gajj2nflutpK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--maH1Gajj2nflutpK
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFCDiq5dQgHtVUb5EcRAg1nAJ44i2wbsQrhsyWYL8HjjLVC7Qq/mgCfXr6X
x4p0hdvNB+i7cLj7QGUGD78=
=xlBz
-----END PGP SIGNATURE-----

--maH1Gajj2nflutpK--