On Mon, Oct 02, 2006, Peter Samuelson wrote:
The problem is that .la files provide a way to pull in all the
dependent libraries for static linking, and unless you also ship .pc
files, there is no other automated way to do this. Some people
apparently care about this capability, which is why
On Sun, Oct 01, 2006, Peter Samuelson wrote:
A first step in that direction would be to fix .la, .pc and -config
files so that they only give the needed libraries.
binary-arch: build-arch
# [something like '$(MAKE) install DESTDIR=$(shell pwd)/debian/tmp']
#
sed -i
[Loïc Minier]
Can't we just tell people to not use *.la files for static linking?
The problem is that .la files provide a way to pull in all the
dependent libraries for static linking, and unless you also ship .pc
files, there is no other automated way to do this. Some people
apparently care
On Mon, Oct 02, 2006 at 02:10:01PM -0500, Peter Samuelson [EMAIL PROTECTED]
wrote:
[Loïc Minier]
Can't we just tell people to not use *.la files for static linking?
The problem is that .la files provide a way to pull in all the
dependent libraries for static linking, and unless you also
[Mike Hommey]
Why not add support for Libs.private in libtool ?
That's essentially what the .la file already provides, with _debian_
libtool. The main problem we have with libtool these days is packages
that use their own shipped libtool rather than debian's.
Anyway, it's probably easiest
[Mike Hommey]
A first step in that direction would be to fix .la, .pc and -config
files so that they only give the needed libraries.
The correct fix for .la files for dynamic linking (remove all dependent
libraries, relying on the runtime linker to pull them in recursively)
does not work for
Martijn van Oosterhout skrev:
Which is all crap. Yes, this is the list you need for static, but
pkg-config is recursing through modules even for dynamic linking which
is wrong. Now either pkg-config of the gtk+2 pc file needs to be
fixed, then you can start recompiling all the affected
On Wed, Sep 27, 2006 at 01:35:12PM -0700, Kevin B. McCarty wrote:
[**] I hope someone out there knows how a library maintainer can
reliably determine this!
Use the Source, Luke. For C, you should examine all functions marked
with __attribute__((__constructor__)) or
On 9/28/06, Tollef Fog Heen [EMAIL PROTECTED] wrote:
Martijn van Oosterhout skrev:
Which is all crap. Yes, this is the list you need for static, but
pkg-config is recursing through modules even for dynamic linking which
is wrong. Now either pkg-config of the gtk+2 pc file needs to be
fixed,
On Thu, Sep 28, 2006 at 04:17:39PM +0200, Martijn van Oosterhout wrote:
The gtk+2 .pc file needs to be changed to mark a bunch of those Requires
as Requires.private, pkg-config provides all the necessary
infrastructure now. (If not, please do file bugs.)
Ok, the reduces the libs list, but
On Thu, Sep 28, 2006, Tollef Fog Heen wrote:
Which is all crap. Yes, this is the list you need for static, but
pkg-config is recursing through modules even for dynamic linking which
is wrong. Now either pkg-config of the gtk+2 pc file needs to be
fixed, then you can start recompiling all the
On 9/28/06, Kurt Roeckx [EMAIL PROTECTED] wrote:
Note that Requires.private is used for cflags since the last version
of pkg-config. Please see http://bugs.debian.org/340904
Well, then something wierd is going on. I have 0.21-1 installed and I
get this. This first time is with Requires, the
On Thu, Sep 28, 2006 at 10:20:18PM +0200, Martijn van Oosterhout [EMAIL
PROTECTED] wrote:
On 9/28/06, Kurt Roeckx [EMAIL PROTECTED] wrote:
Note that Requires.private is used for cflags since the last version
of pkg-config. Please see http://bugs.debian.org/340904
Well, then something wierd
On 9/28/06, Mike Hommey [EMAIL PROTECTED] wrote:
vali:/usr/lib/pkgconfig# pkg-config --cflags gtk+-2.0
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo
I don't know what pkg-config is supposed to do, but surely you don't
need the freetype2 nor the
On Thu, Sep 28, 2006 at 10:20:18PM +0200, Martijn van Oosterhout wrote:
On 9/28/06, Kurt Roeckx [EMAIL PROTECTED] wrote:
Note that Requires.private is used for cflags since the last version
of pkg-config. Please see http://bugs.debian.org/340904
Well, then something wierd is going on. I
On Thu, Sep 28, 2006 at 10:40:43PM +0200, Martijn van Oosterhout [EMAIL
PROTECTED] wrote:
On 9/28/06, Mike Hommey [EMAIL PROTECTED] wrote:
vali:/usr/lib/pkgconfig# pkg-config --cflags gtk+-2.0
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/cairo
Am Donnerstag 28 September 2006 21:14 schrieb Kurt Roeckx:
Note that Requires.private is used for cflags since the last version
of pkg-config.
Interesting but maybe documenting Requires.private would be a good idea?
Hint: the manpage only mentions Libs.private, see #341977 #346602.
And 9 months
On Tue, Sep 26, 2006 at 06:29:25PM -0700, Russ Allbery wrote:
But folding it into shlibdeps at least would remove all those warnings
that were created by shlibdeps.
What warnings were created by shlibdeps? I'm not sure what you're
referring to here.
Sorry. I had a short look at some
On Mon, Sep 25, 2006 at 09:49:57PM +0200, Christian Aichinger wrote:
As a start, I've written a script that searches for unnecessary
dependencies and reports them. Results are available here:
http://rerun.lefant.net/checklib
Excellent work :-). I didn't see a link to the checklib script
On Wed, Sep 27, 2006 at 11:09:37AM +0200, Michael Meskes wrote:
On Tue, Sep 26, 2006 at 06:29:25PM -0700, Russ Allbery wrote:
But folding it into shlibdeps at least would remove all those warnings
that were created by shlibdeps.
What warnings were created by shlibdeps? I'm not sure
On Wed, Sep 27, 2006 at 02:05:29PM +0530, Ganesan Rajagopal wrote:
Excellent work :-).
Thanks :)
I didn't see a link to the checklib script itself.
Do you intend to release it some time? Thanks.
It's linked at the bottom of all the pages, the link points to
Sorry. I had a short look at some packages and all redundant
dependencies were created by shlibdeps. It doesn't seem to make sense to
have a list by maintainer when the dependencies weren't added by
him/her. Or did I misunderstand what this discussion is about?
Yes, I'm afraid you did.
On Tue, Sep 26, 2006 at 06:28:50PM -0700, Russ Allbery wrote:
Christian Aichinger [EMAIL PROTECTED] writes:
Maintaining such information somewhere within the library package would
be possible, but that sounds like a more complex plan, and I doubt that
many library maintainers know if their
On Wed, Sep 27, 2006 at 12:50:07PM +0100, Mark Brown wrote:
As a first approximation perhaps libraries with constructors or
destructors could be assumed to always be required? That would be more
conservative than required but perhaps so conservative as to be useless.
The problematic sections
On Wed, Sep 27, 2006 at 02:57:16AM -0700, Steve Langasek [EMAIL PROTECTED]
wrote:
On Wed, Sep 27, 2006 at 11:09:37AM +0200, Michael Meskes wrote:
On Tue, Sep 26, 2006 at 06:29:25PM -0700, Russ Allbery wrote:
But folding it into shlibdeps at least would remove all those warnings
that
On Wed, Sep 27, 2006 at 02:44:10PM +0200, Christian Aichinger wrote:
The problematic sections seem to be .init and .fini. There are
sections called .ctors and .dtors, but they aren't marked as
executable.
.ctors and .dtors contain function pointers that are called by code in
the .init/.fini
Christian Aichinger [EMAIL PROTECTED] writes:
What I could imagine was some sort of opt-in system, where library
maintainers could put a special marker into their -dev packages
indicating yes, please remove me if I'm not needed, it's save.
I'm not sure where to put it inside the -dev package
On Wed, Sep 27, 2006 at 10:54:34AM -0700, Russ Allbery wrote:
I'm not sure where to put it inside the -dev package though, perhaps
in an /usr/share/debhelper/stripdeps/pkgname file?
Well, if we're talking about an external tool to strip unnecessary NEEDED
entries from the library, you
to
run it or not. That doesn't help the folks who aren't using debhelper =
as
much, though.
But isn't the decision of the maintainer to use dh_striplibs orthogonal
to the need for a library not to be stripped? That is, some set of
libraries presumably shouldn't be stripped out of NEEDED
ugh, somehow one of Thunderbird, Enigmail or my SMTP server mangled the
quoted part of my last email at Message-id:
[EMAIL PROTECTED], maybe also the GPG sig. Sorry about
that! Everything I wanted to say went through OK though.
--
Kevin B. McCarty [EMAIL PROTECTED] Physics Department
WWW:
Hello,
On Mon, 25 Sep 2006, Christian Aichinger wrote:
As Steve Langasek detailed in his d-d-a mail[1], unnecessary
dependencies cause lots of problems, as they make transitions
bigger then they need to be.
Sorry for the noise. I wrote earlier to Christian Aichinger
(and submitted a report
Christian Aichinger [EMAIL PROTECTED] writes:
As a start, I've written a script that searches for unnecessary
dependencies and reports them. Results are available here:
http://rerun.lefant.net/checklib
A problem means that the package has useless dependencies on
library packages. This
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Christian Aichinger [EMAIL PROTECTED] writes:
A problem means that the package has useless dependencies on
library packages. This causes the kind of trouble outlined above and
should be fixed. A HOWTO is here:
Russ Allbery [EMAIL PROTECTED] writes:
Thomas Bushnell BSG [EMAIL PROTECTED] writes:
Christian Aichinger [EMAIL PROTECTED] writes:
A problem means that the package has useless dependencies on
library packages. This causes the kind of trouble outlined above and
should be fixed. A HOWTO is
[Richard Atterer]
On Mon, Sep 25, 2006 at 02:40:49PM -0700, Kevin B. McCarty wrote:
Thank you for this very cool effort! Might we see checklib
packaged for Debian soon?
Hmm, maybe the functionality could be included in lintian?
See #340934. Henning wrote this lintian check several
Re: Christian Aichinger 2006-09-25 [EMAIL PROTECTED]
As a start, I've written a script that searches for unnecessary
dependencies and reports them. Results are available here:
http://rerun.lefant.net/checklib
DDPO (aka developer.php) has a link to the list of checklib results
per maintainer.
On Mon, Sep 25, 2006 at 11:12:49PM -0700, Thomas Bushnell BSG wrote:
Hey. If we have a programmatic way of detecting this cases, why not
just fold that into the shlibdeps program, and be done with it?
Note that if a shared object has constructor and/or destructor functions
then there is NO
On Tue, Sep 26, 2006 at 01:34:50PM +0200, Gabor Gombas wrote:
You could invent a mechanism to tag a library as never to remove even
if no symbols appear to be referenced. Since this should be quite rare
even a single (config?) file listing all problematic libraries would be
enough, at least in
On Tue, Sep 26, 2006 at 12:35:35PM +0200, Christian Aichinger wrote:
On Mon, Sep 25, 2006 at 11:12:49PM -0700, Thomas Bushnell BSG wrote:
Hey. If we have a programmatic way of detecting this cases, why not
just fold that into the shlibdeps program, and be done with it?
As pointed out by
On Mon, Sep 25, 2006 at 11:12:49PM -0700, Thomas Bushnell BSG wrote:
Hey. If we have a programmatic way of detecting this cases, why not
just fold that into the shlibdeps program, and be done with it?
As pointed out by Russ Allbery, shlibdeps wouldn't do. It would be
possible to stuff it into
On Tue, Sep 26, 2006 at 12:35:35PM +0200, Christian Aichinger wrote:
AIUI the number of libraries using such tricks is minor, so it
is unnerving that we can't use the dh_ method because of that. I
don't see any solution though :-/
You could invent a mechanism to tag a library as never to
Christian Aichinger wrote:
As a start, I've written a script that searches for unnecessary
dependencies and reports them. Results are available here:
http://rerun.lefant.net/checklib
More detailed information about the meaning of the results are
available on the web page, the two most
You ([EMAIL PROTECTED]) wrote:
KBM Most of these are X-related, suggesting that quite a lot of .la
KBM and .pc files are pretty indiscriminate about which X libs they
KBM link in.
Will this problem disappear if end programs will pass --as-needed flag
to the ld command line?
--
JID: [EMAIL
Mikhail Gusarov wrote:
You ([EMAIL PROTECTED]) wrote:
KBM Most of these are X-related, suggesting that quite a lot of .la
KBM and .pc files are pretty indiscriminate about which X libs they
KBM link in.
Will this problem disappear if end programs will pass --as-needed flag
to the ld
Mikhail Gusarov wrote:
You ([EMAIL PROTECTED]) wrote:
KBM Most of these are X-related, suggesting that quite a lot of .la
KBM and .pc files are pretty indiscriminate about which X libs they
KBM link in.
Will this problem disappear if end programs will pass --as-needed flag
to the ld
On Tue, Sep 26, 2006 at 11:41:33PM +0700, Mikhail Gusarov wrote:
You ([EMAIL PROTECTED]) wrote:
KBM Most of these are X-related, suggesting that quite a lot of .la
KBM and .pc files are pretty indiscriminate about which X libs they
KBM link in.
Will this problem disappear if end
On Mon, Sep 25, 2006 at 02:40:49PM -0700, Kevin B. McCarty wrote:
One thing I noticed is that there are a lot of problems (in your
terminology) caused by unneeded dependencies on libgcc1
(/lib/libgcc_s.so.1). From my quick investigation, it appears that the
C++ and Fortran compilers (g++,
On Tue, Sep 26, 2006 at 09:36:08AM -0700, Kevin B. McCarty wrote:
In case it's of interest to anyone, I went through the checklib logs
available on the web page for problems and found the libraries that
are most often listed as bogus dependencies. Here are the top twenty
offenders, listed
On Tue, Sep 26, 2006 at 09:36:08AM -0700, Kevin B. McCarty wrote:
In case it's of interest to anyone, I went through the checklib logs
available on the web page for problems and found the libraries that
are most often listed as bogus dependencies.
This seriously rocks. Thanks.
Actually that
On Tue, Sep 26, 2006 at 11:41:33PM +0700, Mikhail Gusarov wrote:
Will this problem disappear if end programs will pass --as-needed flag
to the ld command line?
As described in the other mails, --as-needed is a hack, and can
cause trouble.
I've also thought of a debhelper script stipping out
Christian Aichinger wrote:
On Tue, Sep 26, 2006 at 09:36:08AM -0700, Kevin B. McCarty wrote:
In case it's of interest to anyone, I went through the checklib
logs available on the web page for problems and found the
libraries that are most often listed as bogus dependencies.
This seriously
On 9/26/06, Mikhail Gusarov [EMAIL PROTECTED] wrote:
You ([EMAIL PROTECTED]) wrote:
KBM Most of these are X-related, suggesting that quite a lot of .la
KBM and .pc files are pretty indiscriminate about which X libs they
KBM link in.
Will this problem disappear if end programs will pass
* Kevin B. McCarty [EMAIL PROTECTED] [060926 18:37]:
Most of these are X-related, suggesting that quite a lot of .la and .pc
files are pretty indiscriminate about which X libs they link in.
There is also AC_PATH_XTRA, which just adds all X stuff when only few
may be needed.
Also note that Xt
Le mardi 26 septembre 2006 à 09:36 -0700, Kevin B. McCarty a écrit :
In case it's of interest to anyone, I went through the checklib logs
available on the web page for problems and found the libraries that
are most often listed as bogus dependencies. Here are the top twenty
offenders, listed
On Tue, Sep 26, 2006 at 09:23:23PM +0200, Martijn van Oosterhout wrote:
Will this problem disappear if end programs will pass --as-needed flag
to the ld command line?
Some of it is also pkg-config's fault. For example, anyone using
pkg-config with gtk+2 gets the following:
# pkg-config
Christian Aichinger [EMAIL PROTECTED] writes:
I could maintain such a list for checklib, that wouldn't be
problematic. Doing such a thing for debhelper sounds evil though, I
surely don't want to be responsible if packages fail to build (or run
correctly) because a library was removed that
Michael Meskes [EMAIL PROTECTED] writes:
On Tue, Sep 26, 2006 at 12:35:35PM +0200, Christian Aichinger wrote:
On Mon, Sep 25, 2006 at 11:12:49PM -0700, Thomas Bushnell BSG wrote:
Hey. If we have a programmatic way of detecting this cases, why not
just fold that into the shlibdeps program,
On Tue, Sep 26, 2006, Josselin Mouette wrote:
for file in $(wildcard debian/$(cdbs_curpkg)/usr/lib/*.la); do \
sed -i /dependency_libs/ s/'.*'/''/ $$file ; \
done
To use this feature, if you use CDBS, simply:
include
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Creo que esto debe ser tomado muy en cuenta para los que tenemos paquetes.
Saludos.
Christian Aichinger escribió:
As Steve Langasek detailed in his d-d-a mail[1], unnecessary
dependencies cause lots of problems, as they make transitions
bigger
On Mon, Sep 25, 2006 at 02:40:49PM -0700, Kevin B. McCarty wrote:
Thank you for this very cool effort! Might we see checklib packaged for
Debian soon?
Hmm, maybe the functionality could be included in lintian?
Cheers,
Richard
--
__ _
|_) /| Richard Atterer | GnuPG key:
On Mon, Sep 25, 2006 at 02:40:49PM -0700, Kevin B. McCarty wrote:
(Sorry if you get this twice, I don't know whether you subscribe to
debian-devel.)
I am subscribed here, also sorry about the broken MFT in the
-announce mail :-/
Thank you for this very cool effort! Might we see checklib
Hi Christian,
(Sorry if you get this twice, I don't know whether you subscribe to
debian-devel.)
Christian Aichinger wrote:
As Steve Langasek detailed in his d-d-a mail[1], unnecessary
dependencies cause lots of problems, as they make transitions
bigger then they need to be.
The root cause
62 matches
Mail list logo
