On Fri, 2008-01-04 at 17:52 -0800, Steve Langasek wrote:
On Wed, Jan 02, 2008 at 11:53:16AM +, Neil Williams wrote:
That's upstream covered, it appears I also need debian/libqof1.symbols
from http://qa.debian.org/cgi-bin/mole/seedsymbols ? If I had done
symbol versioning correctly
On Wed, Jan 02, 2008 at 11:53:16AM +, Neil Williams wrote:
Because *all* libraries which have other libs as reverse-dependencies should
implement symbol versioning, precisely as the shortest path for reliably and
permanently addressing the various issues we're discussing.
It *is*
On Tue, 1 Jan 2008 23:17:50 -0800
Steve Langasek [EMAIL PROTECTED] wrote:
On Wed, Dec 26, 2007 at 01:11:40PM +, Neil Williams wrote:
I think I'm doing this already - if libfoo1 implements and exports types
from libbar2 and libbar2 moves to libbar3, I would expect to have to
port libfoo
On Wed, Dec 26, 2007 at 01:11:40PM +, Neil Williams wrote:
... until both the application and libfoo are rebuilt. So the issue
here is triggering rebuilds of reverse dependencies of libbar?
No. That doesn't cause previously released binaries to blink out of
existence.
What's
On Wed, 2007-12-26 at 13:11 +, Neil Williams wrote:
So could I ask, from an upstream perspective, what kind of changes in
the underlying lib might *not* cause such a port and therefore end up
with libfoo1 still being buildable against libbar3 yet *still* require
a
SONAME bump to
On Tue, 2007-12-25 at 20:12 -0800, Steve Langasek wrote:
On Fri, Dec 21, 2007 at 10:55:32AM +, Neil Williams wrote:
On Thu, 20 Dec 2007 21:44:19 -0800
Steve Langasek [EMAIL PROTECTED] wrote:
But *nothing* here guarantees that the version of libbar the application
is
linked
On Fri, Dec 21, 2007 at 10:55:32AM +, Neil Williams wrote:
On Thu, 20 Dec 2007 21:44:19 -0800
Steve Langasek [EMAIL PROTECTED] wrote:
Consider two libraries, libfoo and libbar. libfoo depends on libbar,
references functions from it and uses some of libbar's types in its own
exported
On Thu, 20 Dec 2007 21:44:19 -0800
Steve Langasek [EMAIL PROTECTED] wrote:
Consider two libraries, libfoo and libbar. libfoo depends on libbar,
references functions from it and uses some of libbar's types in its own
exported API.
We assume the Debian-style libbar-dev, which ensures that
On Mon, Dec 10, 2007 at 05:45:27PM +0100, Josselin Mouette wrote:
Le dimanche 09 décembre 2007 à 15:44 -0800, Steve Langasek a écrit :
For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
-lglib-2.0 and -lm. And this is perfectly intentional.
Just because it's
On Mon, Dec 10, 2007 at 09:47:36PM +0100, Simon Richter wrote:
No, what can be done is to fix upstream's broken declaration that 'you can
assume glib functions are available when doing #include gtk/gtk.h'. It
doesn't follow that just because this works in practice, it should be a
supported
Le jeudi 20 décembre 2007 à 00:41 -0800, Steve Langasek a écrit :
When many of the types used by GTK+ are those provided by GLib, it
sounds wrong to ask developers to include the GLib headers to have these
types available.
Well, that part is fairly reasonable, I admit. What isn't
On Thu, 2007-12-20 at 00:51 -0800, Steve Langasek wrote:
On Mon, Dec 10, 2007 at 09:47:36PM +0100, Simon Richter wrote:
No, what can be done is to fix upstream's broken declaration that 'you can
assume glib functions are available when doing #include gtk/gtk.h'.
It
doesn't follow
On Fri, Dec 21, 2007 at 04:08:28AM +1100, Robert Collins wrote:
(BTW, pkg-config upstream wrongly claims that exporting dependent libs
in the pkg-config --libs output provides this protection. :/)
It doesn't? (I must be missing something as I thought it did, just over
aggressively).
Nope.
On Mon, Dec 10, 2007 at 18:29:36 +0100, Raphael Hertzog wrote:
On Mon, 10 Dec 2007, Sune Vuorela wrote:
Isn't the new dpkg-shlipdeps warning about symbols it can't find ?
Only if the library has a SONAME. This is intended so that
perl/python/apache modules do not generate bad warnings:
On Mon, Dec 10, 2007 at 17:45:27 +0100, Josselin Mouette wrote:
When many of the types used by GTK+ are those provided by GLib, it
sounds wrong to ask developers to include the GLib headers to have these
types available.
It sounds wrong not to ask them to use -lglib-2.0 themselves if they
Le lundi 10 décembre 2007 à 18:24 +, Neil Williams a écrit :
I don't have a problem with libglib2.0-0 in gtk+2.0.pc - it may well be
correct to have that one in the pkgconfig because gtk headers define
variables in terms of Glib typedefs. (I have to do the same with libqof1).
The actual
Le Monday 10 December 2007 20:03:50 Pierre Habouzit, vous avez écrit :
Perhaps the absurd and wrong part is that pkg-config does not
provide a way to distinguish between use cases, and that the name for
Wrong, please read pkg-config(1) and think again.
$ pkg-config tokyocabinet --libs
On Sun, Dec 09, 2007, Simon Richter wrote:
If there are broken scripts adding too many libraries then it is time to
fix those scripts, not employ an evil hack that makes the symptoms go away.
We met actual cases were --as-needed breaks things; however, for pure C
program, I think combining it
On Sun, Dec 09, 2007, Zack Weinberg wrote:
I have in the past argued for --as-needed to be made the default in
upstream binutils; that's how safe I think it is. (Upstream
maintainers, conscious of the above and other (isomorphic) corner
cases, wanted a distribution to try it on a large scale
On 2007-12-10, Loïc Minier [EMAIL PROTECTED] wrote:
I think in both cases it was something like the main binary being
linked to many utility libraries (because it was easy to link it to
everything which configure found), and then the plugin calling directly
into these libs, but not being
On Mon, Dec 10, 2007, Sune Vuorela wrote:
Isn't the new dpkg-shlipdeps warning about symbols it can't find ?
Indeed; I was telling a story from the dark ages where .debs were
crafted with silex in your bare hands.
That said, -z defs is a good idea to check all intermediate objects and
to
Le dimanche 09 décembre 2007 à 15:44 -0800, Steve Langasek a écrit :
For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
-lglib-2.0 and -lm. And this is perfectly intentional.
Just because it's intentional doesn't mean it isn't absurd and wrong.
It may be absurd, but I
On Mon, 10 Dec 2007, Sune Vuorela wrote:
On 2007-12-10, Loïc Minier [EMAIL PROTECTED] wrote:
I think in both cases it was something like the main binary being
linked to many utility libraries (because it was easy to link it to
everything which configure found), and then the plugin
Josselin Mouette wrote:
Le dimanche 09 décembre 2007 à 15:44 -0800, Steve Langasek a écrit :
For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
I don't have a problem with libglib2.0-0 in gtk+2.0.pc - it may well be
correct to have that one in the pkgconfig because gtk
Steve Langasek writes:
On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
Just curing the symptoms instead of the problems will not help to get
there any sooner.
What if there is no problem?
For
This one time, at band camp, Michael Poole said:
What happens for a user who (however absurd or insane he might be to
try this with gtk+) tries to link his application statically?
Perhaps the absurd and wrong part is that pkg-config does not
provide a way to distinguish between use cases,
On Mon, Dec 10, 2007 at 06:47:15PM +, Michael Poole wrote:
Steve Langasek writes:
On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
Just curing the symptoms instead of the problems will not help
On Mon, Dec 10, 2007 at 01:47:15PM -0500, Michael Poole wrote:
Steve Langasek writes:
On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
Just curing the symptoms instead of the problems will not help to
Stephen Gran writes:
This one time, at band camp, Michael Poole said:
What happens for a user who (however absurd or insane he might be to
try this with gtk+) tries to link his application statically?
Perhaps the absurd and wrong part is that pkg-config does not
provide a way to
On Mon, Dec 10, 2007 at 01:47:15PM -0500, Michael Poole wrote:
Steve Langasek writes:
For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
-lglib-2.0 and -lm. And this is perfectly intentional.
Just because it's intentional doesn't mean it isn't absurd and wrong.
Am Montag 10 Dezember 2007 schrieb Michael Poole:
Stephen Gran writes:
This one time, at band camp, Michael Poole said:
What happens for a user who (however absurd or insane he might be to
try this with gtk+) tries to link his application statically?
Perhaps the absurd and wrong part is
On Mon, Dec 10, 2007 at 08:16:10PM +, Hendrik Sattler wrote:
Am Montag 10 Dezember 2007 schrieb Michael Poole:
Stephen Gran writes:
This one time, at band camp, Michael Poole said:
What happens for a user who (however absurd or insane he might be to
try this with gtk+) tries to
Hi,
Josselin Mouette wrote:
No, what can be done is to fix upstream's broken declaration that 'you can
assume glib functions are available when doing #include gtk/gtk.h'. It
doesn't follow that just because this works in practice, it should be a
supported usage.
When many of the types used
On Mon, 10 Dec 2007 22:10:49 +0100
Pierre Habouzit [EMAIL PROTECTED] wrote:
That is supported in pkg-config, but no upstream I've ever met seems to
understand it yet.
Ah, I see. I overlooked the --static flag to pkg-config because (case
in point) pkg-config --libs gtk+-2.0 only
On Mon, Dec 10, 2007 at 12:35:11AM -0300, Felipe Sateler wrote:
Steve Langasek wrote:
... also, -Wl,--as-needed is *not* a complete solution for the problems
caused by generating extra -l arguments. Every -lfoo option passed to the
linker requires the corresponding -dev package to be
Hi,
due to the recent dpkg-shlibdeps changes, people have started adding
-Wl,--as-needed into their LDFLAGS.
THIS IS NOT A GOOD IDEA.
You are essentially telling gcc to pass an option to the linker without
understanding what it does, and, more specifically, an option that tells
the linker to
due to the recent dpkg-shlibdeps changes, people have started adding
-Wl,--as-needed into their LDFLAGS.
THIS IS NOT A GOOD IDEA.
You are essentially telling gcc to pass an option to the linker without
understanding what it does, and, more specifically, an option that tells
the linker to
Le Sunday 09 December 2007 09:56:39 Zack Weinberg, vous avez écrit :
I'm curious what prompted your message. Did a program you use
actually break? What was the failure mode?
Yes, I agree too.
I've been using this flag recently, and in most cases it just does what's
required...
I think
Le dimanche 09 décembre 2007 à 09:03 +0100, Simon Richter a écrit :
Hi,
due to the recent dpkg-shlibdeps changes, people have started adding
-Wl,--as-needed into their LDFLAGS.
THIS IS NOT A GOOD IDEA.
Of course it is. This is the most reliable way of dropping unneeded
dependencies. All
* Josselin Mouette [EMAIL PROTECTED] [071209 18:48]:
due to the recent dpkg-shlibdeps changes, people have started adding
-Wl,--as-needed into their LDFLAGS.
THIS IS NOT A GOOD IDEA.
If there are broken scripts adding too many libraries then it is time to
fix those scripts, not
Hi,
Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
Just curing the symptoms instead of the problems will not help to get
there any sooner.
What if there is no problem?
For example, pkg-config --libs gtk+-x11-2.0 will return, among others,
-lglib-2.0 and -lm. And this
On Sun, Dec 09, 2007 at 07:23:00PM +0100, Josselin Mouette wrote:
Hi,
Le dimanche 09 décembre 2007 à 19:11 +0100, Bernhard R. Link a écrit :
Just curing the symptoms instead of the problems will not help to get
there any sooner.
What if there is no problem?
For example, pkg-config
Le Sunday 09 December 2007 20:03:27 Kurt Roeckx, vous avez écrit :
Anyway, I think it is bad style to use macro's in public header
files that call functions from another library. It's also easy
to replace them with real functions. If there are such functions
being called I suggest you
Romain Beauxis [EMAIL PROTECTED] writes:
Ok, let's consider another very simple case:
libshout allows to perform streaming of speex, vorbis, and theora formats.
Hence, when asking for the libs to link with, you got -lspeex and -ltheora
since it's needed to cover all build cases.
Why?
Ok, let's consider another very simple case:
libshout allows to perform streaming of speex, vorbis, and theora formats.
Hence, when asking for the libs to link with, you got -lspeex and -ltheora
since it's needed to cover all build cases.
However, most of the applications don't need to
On Mon, Dec 10, 2007 at 12:45:46AM +0300, Nikita V. Youshchenko wrote:
Ok, let's consider another very simple case:
libshout allows to perform streaming of speex, vorbis, and theora formats.
Hence, when asking for the libs to link with, you got -lspeex and -ltheora
since it's needed to
Le Sunday 09 December 2007 22:45:46 Nikita V. Youshchenko, vous avez écrit :
However, most of the applications don't need to link against theora and
speex.
Doesn't libshout reference symbols from libspeex and libtheora?
Yes
If it does, resulting binary must be linked against both these
Steve Langasek wrote:
... also, -Wl,--as-needed is *not* a complete solution for the problems
caused by generating extra -l arguments. Every -lfoo option passed to the
linker requires the corresponding -dev package to be installed at build
time; while it is a bug if the -dev packages don't
48 matches
Mail list logo
