On Tue, Aug 20, 2002 at 02:10:18PM +0200, Eduard Bloch wrote:
Because of naivity of some programers. I suggest to begin getting rid of
such kludges and forbid usage of .la files at runtimer in the Policy for
Sarge.
Policy is not a stick to beat with. If there is a bug, report it as such,
and
On Sat, 24 Aug 2002, Marcus Brinkmann wrote:
On Tue, Aug 20, 2002 at 02:10:18PM +0200, Eduard Bloch wrote:
Because of naivity of some programers. I suggest to begin getting rid of
such kludges and forbid usage of .la files at runtimer in the Policy for
Sarge.
Policy is not a stick to
On Mon, 19 Aug 2002, Ben Collins wrote:
Not only that, it's only useful for linking, so has no reason being in
the primary runtime.
ltdl needs them at runtime.
Then ltdl is broken. How does one install libfoo.so.1 and libfoo.so.2
and only have libfoo.la, and ltdl expect to work?
On 20 Aug 2002 01:50:22 +0200
Luca Barbieri [EMAIL PROTECTED] wrote:
According to Junichi's manual they should be in -dev packages (that
makes sense, since they are only used by libtool builds).
My solution to the problem would be to create
libwhatever-la packages which contains .la file
Ben Collins wrote:
Then ltdl is broken. How does one install libfoo.so.1 and libfoo.so.2
and only have libfoo.la, and ltdl expect to work?
Broken...
So, i guess that kdelibs3 (4:2.2.2-13) is also broken...
$ dpkg -L kdelibs3 | grep \\.la$
/usr/lib/libDCOP.la
/usr/lib/dcopserver.la
Roberto Gordo Saez [EMAIL PROTECTED] writes:
$ dpkg -L kdelibs3 | grep \\.la$
/usr/lib/libDCOP.la
/usr/lib/dcopserver.la
/usr/lib/libkdefakes.la
/usr/lib/libkdeui.la
/usr/lib/libkdesu.la
/usr/lib/libkssl.la
diverted by kdelibs3-crypto to: /usr/lib/libkssl-nossl.la
Marcelo E. Magallon wrote:
A wild guess: I don't know about the files named lib*.la, but the other
ones could be plug-ins. ltdl opens the .la file to find out the actual
Yes, you are right, but... why does a plugin need both .so and .la files?
(Please, CC to me also)
--
Roberto Gordo - Free
#include hallo.h
* Roberto Gordo Saez [Tue, Aug 20 2002, 02:01:44PM]:
A wild guess: I don't know about the files named lib*.la, but the other
ones could be plug-ins. ltdl opens the .la file to find out the actual
Yes, you are right, but... why does a plugin need both .so and .la files?
Roberto Gordo Saez [EMAIL PROTECTED] writes:
Marcelo E. Magallon wrote:
A wild guess: I don't know about the files named lib*.la, but the other
ones could be plug-ins. ltdl opens the .la file to find out the actual
Yes, you are right, but... why does a plugin need both .so and .la
Christian Marillat [EMAIL PROTECTED] writes:
Adam Heath [EMAIL PROTECTED] writes:
On Mon, 19 Aug 2002, Ben Collins wrote:
Not only that, it's only useful for linking, so has no reason being in
the primary runtime.
ltdl needs them at runtime.
and librep9 too.
I forgot my last changes in
On Tue, Aug 20, 2002 at 12:25:57PM +0200, Roberto Gordo Saez wrote:
Ben Collins wrote:
Then ltdl is broken. How does one install libfoo.so.1 and libfoo.so.2
and only have libfoo.la, and ltdl expect to work?
Broken...
So, i guess that kdelibs3 (4:2.2.2-13) is also broken...
Absolutely.
Eduard Bloch [EMAIL PROTECTED] writes:
Because of naivity of some programers. I suggest to begin getting rid
of such kludges and forbid usage of .la files at runtimer in the
Policy for Sarge.
I beg your pardon? Which naiveness? That particular bit of libtool
solves a very real
#include hallo.h
* Marcelo E. Magallon [Tue, Aug 20 2002, 02:24:21PM]:
I've seen is *that* stupid), but libtool produces filanames named after
the platform's own conventions. So, under Linux you get libfoo.so and
under HP/UX you get libfoo.sl. *That* information is stored in the .la
Eduard Bloch [EMAIL PROTECTED] writes:
Yes, and this breaks the whole idea of SONAMES. I wonder how such shit
has ever been allowed to enter Debian.
Are we still talking about plug-ins here? I had that impression.
Say, how is a SONAME useful for a plugin? A plug-in is not something
#include hallo.h
* Marcelo E. Magallon [Tue, Aug 20 2002, 04:19:02PM]:
Yes, and this breaks the whole idea of SONAMES. I wonder how such shit
has ever been allowed to enter Debian.
Are we still talking about plug-ins here? I had that impression.
Say, how is a SONAME useful for a
On Tue, 20 Aug 2002, Marcelo E. Magallon wrote:
I beg your pardon? Which naiveness? That particular bit of libtool
solves a very real problem: dlopen is *not* portable.
Careful here, dlopen is defined by SUSv2, all the libtool hackage is does
is allow OS's to get away with not conforming
On Mon, Aug 19, 2002 at 10:06:20PM -0600, Jason Gunthorpe wrote:
On Mon, 19 Aug 2002, Ben Collins wrote:
Not only that, it's only useful for linking, so has no reason being in
the primary runtime.
ltdl needs them at runtime.
Then ltdl is broken. How does one install
On Tue, Aug 20, 2002 at 02:24:21PM +0200, Marcelo E. Magallon wrote:
Roberto Gordo Saez [EMAIL PROTECTED] writes:
Marcelo E. Magallon wrote:
A wild guess: I don't know about the files named lib*.la, but the other
ones could be plug-ins. ltdl opens the .la file to find out the
On Tue, Aug 20, 2002 at 10:43:58AM -0600, Jason Gunthorpe wrote:
On Tue, 20 Aug 2002, Marcelo E. Magallon wrote:
I beg your pardon? Which naiveness? That particular bit of libtool
solves a very real problem: dlopen is *not* portable.
Careful here, dlopen is defined by SUSv2, all
According to Junichi's manual they should be in -dev packages (that
makes sense, since they are only used by libtool builds).
The following packages might be affected. The list only includes
packages from unstable in libs/ with digits in the name.
hamlib1
kdelibs3
kdelibs3-cups
libaspell10
On Tue, Aug 20, 2002 at 01:50:22AM +0200, Luca Barbieri wrote:
According to Junichi's manual they should be in -dev packages (that
makes sense, since they are only used by libtool builds).
Yes, it's a bug. Consider that the .la file is usually without soname
(e.g. libfoo.la) it will clash when
On Mon, 19 Aug 2002, Ben Collins wrote:
Not only that, it's only useful for linking, so has no reason being in
the primary runtime.
ltdl needs them at runtime.
Adam Heath [EMAIL PROTECTED] writes:
On Mon, 19 Aug 2002, Ben Collins wrote:
Not only that, it's only useful for linking, so has no reason being in
the primary runtime.
ltdl needs them at runtime.
and librep9 too.
Christian
ltdl needs them at runtime.
If so, how should parallel installation be handled?
How does one decide whether the .la file should be put in the main
package or the dev one?
The shared library packaging manual should be updated to included this
information if this is the case.
signature.asc
On Mon, Aug 19, 2002 at 07:29:23PM -0500, Adam Heath wrote:
On Mon, 19 Aug 2002, Ben Collins wrote:
Not only that, it's only useful for linking, so has no reason being in
the primary runtime.
ltdl needs them at runtime.
Then ltdl is broken. How does one install libfoo.so.1 and
On Mon, 19 Aug 2002, Ben Collins wrote:
Then ltdl is broken. How does one install libfoo.so.1 and libfoo.so.2
and only have libfoo.la, and ltdl expect to work?
libtool itself is broken, but I digress.
On Mon, Aug 19, 2002 at 09:22:54PM -0400, Ben Collins wrote:
On Mon, Aug 19, 2002 at 07:29:23PM -0500, Adam Heath wrote:
On Mon, 19 Aug 2002, Ben Collins wrote:
Not only that, it's only useful for linking, so has no reason being in
the primary runtime.
ltdl needs them at runtime.
Then
27 matches
Mail list logo
