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 wh
[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 jus
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
[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 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
[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
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 month
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/incl
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 o
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
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 somet
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, 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 al
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
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
> f
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
__attribute__((__destruct
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 programs.
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
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:
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 ent
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/ file?
>
> Well, if we're talking about an external tool to strip unnecessary NEEDED
> entries from the library, you could
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
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
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
> >
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 section
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
> > 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
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
http://greek0.net/div/checklib.t
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
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 itse
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 so
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 /usr/share/gnome-pkg-tools/1
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 p
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 tha
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-c
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, li
* 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 X
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
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
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 u
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 th
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, li
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 i
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
> t
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
> t
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 (
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: [EMAI
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
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 ou
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 r
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 lea
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 W
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
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 maintaine
[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 severa
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
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:
>> http://rerun.lefant.ne
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. Th
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 pa
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: 8883
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 c
61 matches
Mail list logo