Brian May [EMAIL PROTECTED] writes:
Jason Does anyone know *why* libtool requires this? It strikes me
Jason as totally unnecessary for runtime linking on linux. Maybe
Jason someone should fix libltdl.
Lets not get off-topic into a flame war over why does libtool do it
Marcelo == Marcelo E Magallon [EMAIL PROTECTED] writes:
Marcelo Jason's is actually a valid question concerning this
Marcelo thread.
Well, sorry if I misunderstood the question, but I interpreted it as
why does libltdl need libx.la instead of loading libx.so directly?
Well, when
On 5 Feb 2001, Brian May wrote:
Marcelo Jason's is actually a valid question concerning this
Marcelo thread.
Well, sorry if I misunderstood the question, but I interpreted it as
My question was retorical. I know the answer is 'because it is too lame to
become a no-op on SUS
Brian == Brian May [EMAIL PROTECTED] writes:
Brian foo-dev (2.1) /usr/include/foo.h /usr/lib/libfoo.so -
Brian libfoo.so.2.1
For everyone concerned: versions of libtool already support this.
eg. cvs version of libtool 1.4, and cvs tree for libtool 1.3x (not
sure if includes the latest
Frank == Frank Belew [EMAIL PROTECTED] writes:
Frank --snip -- You have to watch this one. We've found that
Frank things like rep require the la in the main package, not the
Frank dev due to linking to libltdl. This one was somewhat hard
Frank to discover since everyone always
On 4 Feb 2001, Brian May wrote:
Frank --snip -- You have to watch this one. We've found that
Frank things like rep require the la in the main package, not the
Frank dev due to linking to libltdl. This one was somewhat hard
Frank to discover since everyone always seems to have
Jason == Jason Gunthorpe [EMAIL PROTECTED] writes:
Jason Does anyone know *why* libtool requires this? It strikes me
Jason as totally unnecessary for runtime linking on linux. Maybe
Jason someone should fix libltdl.
Lets not get off-topic into a flame war over why does libtool do it
Frank == Frank Belew [EMAIL PROTECTED] writes:
Frank --snip -- You have to watch this one. We've found that
Frank things like rep require the la in the main package, not the
Frank dev due to linking to libltdl. This one was somewhat hard
Frank to discover since everyone always
Brian == Brian May [EMAIL PROTECTED] writes:
Brian However, this exposes other issues, since the version of
Brian *.la required depends on the version of the library
Brian required, however only one copy of the *.la file can be
Brian installed, while a number of different
On Sat, 27 Jan 2001, Brian May wrote:
Henrique == Henrique M Holschuh [EMAIL PROTECTED] writes:
Henrique In other words, if this bug is deemed to be correct, we
Henrique will have to add hard-link support to dpkg and
Henrique .debs. Anything else will simply DOUBLE the already
Herbert Xu [EMAIL PROTECTED] writes:
and allow shlibs with different minor version numbers to be installed
together by encoding it into the package name. Of course, we'll have
to manage /usr/lib/libfoo.so.2 dynamically as well.
Break the second you run ldconfig. Plus the fact that the
Brian May [EMAIL PROTECTED] writes:
If so, what is the problem with installing the unstable version of
libl6? Oh, you explain it here.
Ian L-dev from unstable, but then when you compile S it ends up
Ian needing the L from unstable.
Ugh. I finally understand the intention
Marcelo E. Magallon [EMAIL PROTECTED] wrote:
Herbert Xu [EMAIL PROTECTED] writes:
and allow shlibs with different minor version numbers to be installed
together by encoding it into the package name. Of course, we'll have
to manage /usr/lib/libfoo.so.2 dynamically as well.
Break the
On Fri, Jan 26, 2001 at 08:34:07PM -0600, David Engel wrote:
On Fri, Jan 26, 2001 at 03:04:22PM -0500, Ben Collins wrote:
Can we say archive, system, mirror and update bloat horror!? DO you
My very rough estimate would be about 300 MB per distribution. Not
insignificant, but not completely
On Sat, Jan 27, 2001 at 01:40:48AM +, Ian Jackson wrote:
Ben Collins writes (Bug#83669: Shared libraries):
On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote:
foo-dev (2.1) /usr/include/foo.h
/usr/lib/libfoo.so (copy of actual library
Herbert Xu [EMAIL PROTECTED] writes:
and allow shlibs with different minor version numbers to be installed
together by encoding it into the package name. Of course, we'll have
to manage /usr/lib/libfoo.so.2 dynamically as well.
Break the second you run ldconfig. Plus the
Marcelo E. Magallon [EMAIL PROTECTED] wrote:
I don't think I understand what you mean by manage here. You can't
prevent users from running 'ldconfig'. If you run 'ldconfig' it will
read the sonames and place symlinks to the newer versions of the
library.
If you've got both foo 2.0
Marcelo == Marcelo E Magallon [EMAIL PROTECTED] writes:
Marcelo libfoo-dev (2.1-1) was compiled with libbar-dev (1.1-1).
Marcelo libbar1 (1.1-1) exists in unstable and libbar1 (1.0-1)
Marcelo exists in stable. Due to bad judgement, libbar1 (1.1-1)
Marcelo (and libbar-dev 1.1-1
Marcelo == Marcelo E Magallon [EMAIL PROTECTED] writes:
Marcelo I don't think I understand what you mean by manage here.
Marcelo You can't prevent users from running 'ldconfig'. If you
Marcelo run 'ldconfig' it will read the sonames and place
Marcelo symlinks to the newer
Ben == Ben Collins [EMAIL PROTECTED] writes:
Ben So? This makes things consistent, and much easier to track
Ben bugs and problems. Your proposal would make things really
Ben difficult to track bugs The bug only shows up when I have
Ben libfoo1_1.0 and libfoo-dev_0.9 installed.
Package: debian-policy
Version: 3.2.1.2
(We've had this argument before, and it degenerated into the policy
process row. It seems that Wichert is unwilling to act to fix the
process, so I'll just reopen the issue like this. I can't find it in
the archives anywhere.)
Currently, wrt shared
On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote:
foo-dev (2.1) /usr/include/foo.h
/usr/lib/libfoo.so (copy of actual library)
Can we say archive, system, mirror and update bloat horror!? DO you
realize what this would mean for lib packages like
Ian Jackson [EMAIL PROTECTED] wrote:
Currently, wrt shared libraries, we mandate (or do) this:
foo2 (2.1) /usr/lib/libfoo.so.2 - libfoo.so.2.1
/usr/lib/libfoo.so.2.1 (actual library)
foo-dev (2.1) /usr/include/foo.h
/usr/lib/libfoo.so
Ian == Ian Jackson [EMAIL PROTECTED] writes:
Ian The effect is that foo-dev (2.1) has to have a dependency on
Ian foo2 (2.1) because otherwise you might compile against a .so
Ian file and headers from different versions.
Ian This is bad because it makes it hard to upgrade your
* Brian May [EMAIL PROTECTED] [010126 15:32]:
Please give me a real life example of why distinguishing libraries
solely by their major version number is not good enough...
How does this work with the glibc mess I seem to recall from about a
month ago?
--
``Oh Lord; Ooh you are so big; So
Seth == Seth Arnold [EMAIL PROTECTED] writes:
Seth How does this work with the glibc mess I seem to recall from
Seth about a month ago?
I don't recall the details - can somebody please give me a URL?
--
Brian May [EMAIL PROTECTED]
Brian May writes (Re: Bug#83669: Shared libraries):
You seem to imply that the versions of the libraries are incompatible,
despite having the same major version. If this is really the case, I
think the potential exists to break a lot more then just the build
process.
Please give me a real
Ben Collins writes (Bug#83669: Shared libraries):
On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote:
foo-dev (2.1) /usr/include/foo.h
/usr/lib/libfoo.so (copy of actual library)
Can we say archive, system, mirror and update bloat horror!? DO
On Fri, Jan 26, 2001 at 03:04:22PM -0500, Ben Collins wrote:
Can we say archive, system, mirror and update bloat horror!? DO you
My very rough estimate would be about 300 MB per distribution. Not
insignificant, but not completely untenable either.
This is bad, and creates plenty of problems
Ian == Ian Jackson [EMAIL PROTECTED] writes:
Ian In general, it's not safe to use a minor version of a library
Ian lower than that with which the binary was compiled.
Ian So you if you have a library L used by both an program S
Ian which you want to compile for stable and a
On Fri, 26 Jan 2001, Ben Collins wrote:
On Fri, Jan 26, 2001 at 07:34:08PM +, Ian Jackson wrote:
foo-dev (2.1) /usr/include/foo.h
/usr/lib/libfoo.so (copy of actual library)
Can we say archive, system, mirror and update bloat horror!? DO you
realize what
Herbert == Herbert Xu [EMAIL PROTECTED] writes:
Herbert Ian Jackson [EMAIL PROTECTED] wrote:
Currently, wrt shared libraries, we mandate (or do) this:
foo2 (2.1) /usr/lib/libfoo.so.2 - libfoo.so.2.1
/usr/lib/libfoo.so.2.1 (actual library)
foo-dev (2.1)
On Fri, Jan 26, 2001 at 08:34:07PM -0600, David Engel wrote:
I think this would be more trouble than it's worth. Not only would
That's probably true.
packagers have to deal with all of the possible overlaps between
packages, it would also potentially add even more packages to the
Ian == Ian Jackson [EMAIL PROTECTED] writes:
Ian The net effect is that nearly all packages in Debian are compiled
Ian against the libraries from unstable, and that it's hard for a
Ian developer running mostly unstable to build packages for stable.
The conventional solution for this
Hi,
We seem to be balancing 300MB for all archives, mirrors,
transfers, CD's, everyone downloading packages, etc, against the
requirements of a few developers who need to create debs for
libraries older than those they are running? And who could always
create a chroot jail for
Manoj == Manoj Srivastava [EMAIL PROTECTED] writes:
Manoj Hi, We seem to be balancing 300MB for all archives,
Look at Herbert's proposal - it doesn't require any extra space,
except for storing multiple versions of the library (which could be
done privately too, if Debian doesn't want to do
Brian == Brian May [EMAIL PROTECTED] writes:
I previously misunderstood Herbert's proposal, here it is again (I
hope it is accurate this time...).
foo2.0 (2.0) /usr/lib/libfoo.so.2.0 (actual library)
Provides: foo2 version 2.0
foo2.1 (2.1) /usr/lib/libfoo.so.2.1 (actual library)
Provides:
37 matches
Mail list logo
