On Tuesday 01 September 2009 12:33:09 Kurt Roeckx wrote:
> On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote:
> > On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote:
> > > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote:
> > > > * Kurt Roeckx wrote on Sun, Aug 30, 2009
libxcb version 1.0 installed:
/usr/lib/libxcb-xlib.la
/usr/lib/libxcb-xlib.so
/usr/lib/libxcb-xlib.so.0
/usr/lib/libxcb-xlib.so.0.0.0
However, libxcb version 1.4 did not install the above mentioned files.
libX11 version 1.1.3 linked using /usr/lib/libxcb-xlib.la.
All software linked with libX11
On Mon, Aug 31, 2009 at 04:38:04PM -0400, Mike Frysinger wrote:
> On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote:
> > On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote:
> > > * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST:
> > > > I've mailed about this issue before.
On Monday 31 August 2009 15:56:06 Kurt Roeckx wrote:
> On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote:
> > * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST:
> > > I've mailed about this issue before. What I think needs to
> > > happen, and have proposed before, is:
> >
On Mon, Aug 31, 2009 at 08:55:21PM +0200, Ralf Wildenhues wrote:
> Hello Kurt,
>
> * Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST:
> >
> > I've mailed about this issue before. What I think needs to
> > happen, and have proposed before, is:
> > - The .la file should only contain the
Hello Kurt,
* Kurt Roeckx wrote on Sun, Aug 30, 2009 at 10:31:39PM CEST:
>
> I've mailed about this issue before. What I think needs to
> happen, and have proposed before, is:
> - The .la file should only contain the libraries the current
> library links to
That will make it impossible to sup
On Tue, Aug 25, 2009 at 05:46:12PM +0300, Anssi Hannula wrote:
>
> dependency_libs contains the dependencies of a library. These are needed
> when linking statically. These are also needed when linking dynamically,
> but only on certain systems (they are not needed on normal linux systems).
>
> I
Ralf Wildenhues wrote:
> * Anssi Hannula wrote on Wed, Aug 26, 2009 at 12:05:22PM CEST:
>> Ralf Wildenhues wrote:
>>> Do dlopen'ed modules that have indirect
>>> dependencies outside of default-searched library paths get loaded
>>> correctly now, with DT_RPATH entries only pointing to direct deplib
On Wednesday 26 August 2009 16:30:06 Ralf Wildenhues wrote:
> * Russ Allbery wrote on Wed, Aug 26, 2009 at 07:35:53AM CEST:
> > dlopened modules are something of a special case; it's one of the places
> > where Debian may not remove *.la files depending on the specific
> > situation.
>
> I have a q
Ralf Wildenhues writes:
> * Russ Allbery wrote on Wed, Aug 26, 2009 at 07:35:53AM CEST:
>> dlopened modules are something of a special case; it's one of the
>> places where Debian may not remove *.la files depending on the specific
>> situation.
> I have a question here, since it seems some of t
* Russ Allbery wrote on Wed, Aug 26, 2009 at 07:35:53AM CEST:
>
> dlopened modules are something of a special case; it's one of the places
> where Debian may not remove *.la files depending on the specific
> situation.
I have a question here, since it seems some of the involved people are
reading
* Anssi Hannula wrote on Wed, Aug 26, 2009 at 12:05:22PM CEST:
> Ralf Wildenhues wrote:
> > * Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST:
> >> Is someone here willing to contribute a portable m4 macro which
> >> tests the compiler (and/or linker) to prove beyond a shadow of a
> >
On Wed, 26 Aug 2009, Ralf Wildenhues wrote:
Linux does seem to have good dynamic linker support and its a shame
libtool effectively drags it down to a lower common denominator of other
platforms with worse support.
Actually, historically that was probably done on purpose, to remind
developers
Paul Wise wrote:
> On Tue, 2009-08-25 at 18:34 +0300, Anssi Hannula wrote:
>
>> You mean to subscribe on the debian development list? I'd think this
>> list would be the more appropriate place for discussing a proper
>> upstream solution.
>
> There is no need to subscribe, just ask people to CC y
Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST:
>> Is someone here willing to contribute a portable m4 macro which
>> tests the compiler (and/or linker) to prove beyond a shadow of a
>> doubt that it adequately supports the implicit linkage required? The
>>
Ralf Wildenhues writes:
> * Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST:
>> Is someone here willing to contribute a portable m4 macro which tests
>> the compiler (and/or linker) to prove beyond a shadow of a doubt that
>> it adequately supports the implicit linkage required? The
* Mike Frysinger wrote on Wed, Aug 26, 2009 at 01:49:18AM CEST:
> On Tuesday 25 August 2009 18:41:52 Russ Allbery wrote:
> > Bob Friesenhahn writes:
> > > libfoo-ssl_fast.so
> > > myprog --> somelib --> or
> > > libfoo-ssl_slow.so
> > >
> > >
* Richard Purdie wrote on Wed, Aug 26, 2009 at 12:37:54AM CEST:
> On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote:
> > With GNU/Linux, and libraries all being in directories searched by
> > default by both the link editor and the runtime linker, the problems
> > are fairly limited. IIRC D
* Bob Friesenhahn wrote on Wed, Aug 26, 2009 at 05:01:18AM CEST:
> Is someone here willing to contribute a portable m4 macro which
> tests the compiler (and/or linker) to prove beyond a shadow of a
> doubt that it adequately supports the implicit linkage required? The
> tests should work for more t
* Russ Allbery wrote on Wed, Aug 26, 2009 at 12:41:52AM CEST:
> Bob Friesenhahn writes:
>
> > libfoo-ssl_fast.so
> > myprog --> somelib --> or
> > libfoo-ssl_slow.so
> This case is exceptionally rare.
It used to be a lot more common, and li
Is someone here willing to contribute a portable m4 macro which tests
the compiler (and/or linker) to prove beyond a shadow of a doubt that
it adequately supports the implicit linkage required? The tests should
work for more than Linux and should be based on observed behavior.
Support for indi
Mike Frysinger wrote:
> On Tuesday 25 August 2009 20:33:25 Anssi Hannula wrote:
>> Mike Frysinger wrote:
>>> On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote:
On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST:
On Tuesday 25 August 2009 20:33:25 Anssi Hannula wrote:
> Mike Frysinger wrote:
> > On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote:
> >> On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote:
> >>> * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST:
> On Tue, 25 Aug 20
Mike Frysinger wrote:
> On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote:
>> On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote:
>>> * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST:
On Tue, 25 Aug 2009, Anssi Hannula wrote:
> I think the proper way to solve thi
dherr...@tentpost.com wrote:
> Mike wrote:
>> making the code use reduced library sets for only linux targets is fine by
>> me.
>> libtool already has plenty of target-specific code based on the quality of
>> library handling.
>
>
> I think the scope of the problem is more devious than you imagin
On Tuesday 25 August 2009 18:37:54 Richard Purdie wrote:
> On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote:
> > * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST:
> > > On Tue, 25 Aug 2009, Anssi Hannula wrote:
> > > >I think the proper way to solve this is to not link to dep
On Tuesday 25 August 2009 18:41:52 Russ Allbery wrote:
> Bob Friesenhahn writes:
> > How would you like to deal with the case where a library has multiple
> > usable dependencies, which satisify identical purposes, but via
> > different possible libraries?
> >
> > libfoo-s
Bob Friesenhahn writes:
> How would you like to deal with the case where a library has multiple
> usable dependencies, which satisify identical purposes, but via
> different possible libraries?
> libfoo-ssl_fast.so
> myprog --> somelib --> or
>
On Tue, 2009-08-25 at 20:44 +0200, Ralf Wildenhues wrote:
> * Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST:
> > On Tue, 25 Aug 2009, Anssi Hannula wrote:
> > >
> > >I think the proper way to solve this is to not link to dependency_libs
> > >when linking dynamically on systems where
On Tue, 25 Aug 2009, Russ Allbery wrote:
I know what the difference is. My point is that adding an explicit
dependency on a shared library whose ABI you do not use directly simply
doesn't scale when maintaining a distribution the size of Debian. You
have to rely on the dynamic linker to resolv
On Tuesday 25 August 2009 17:52:07 Bob Friesenhahn wrote:
> On Tue, 25 Aug 2009, Russ Allbery wrote:
> >> Relying on the OS's implicit dependency features seems to be an approach
> >> which is fraught with peril.
> >
> > Relying on the dynamic linker to resolve implicit dependencies is the
> > only
Bob Friesenhahn writes:
> On Tue, 25 Aug 2009, Russ Allbery wrote:
>>> Relying on the OS's implicit dependency features seems to be an
>>> approach which is fraught with peril.
>> Relying on the dynamic linker to resolve implicit dependencies is the
>> only way that it's really feasible to maint
On Tue, 25 Aug 2009, Russ Allbery wrote:
Relying on the OS's implicit dependency features seems to be an approach
which is fraught with peril.
Relying on the dynamic linker to resolve implicit dependencies is the only
way that it's really feasible to maintain a distribution the size of
Debian
Bob Friesenhahn writes:
> On Tue, 25 Aug 2009, Anssi Hannula wrote:
>> I think the proper way to solve this is to not link to dependency_libs
>> when linking dynamically on systems where it is not needed to link to
>> those. I haven't seen any correctly working patches that implement
>> this.
>
On Tuesday 25 August 2009 13:50:18 dherr...@tentpost.com wrote:
> Mike wrote:
> > On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote:
> >> On Tue, 25 Aug 2009, Mike Frysinger wrote:
> >> >> Relying on the OS's implicit dependency features seems to be an
> >> >> approach which is fraught with
Hello,
* Bob Friesenhahn wrote on Tue, Aug 25, 2009 at 05:17:49PM CEST:
> On Tue, 25 Aug 2009, Anssi Hannula wrote:
> >
> >I think the proper way to solve this is to not link to dependency_libs
> >when linking dynamically on systems where it is not needed to link to
> >those. I haven't seen any co
Mike wrote:
> On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote:
>> On Tue, 25 Aug 2009, Mike Frysinger wrote:
>> >> Relying on the OS's implicit dependency features seems to be an
>> >> approach which is fraught with peril.
>> >
>> > why ?
>>
>> When viewing the issue through Linux package-
On Tuesday 25 August 2009 12:42:19 Bob Friesenhahn wrote:
> On Tue, 25 Aug 2009, Mike Frysinger wrote:
> >> Relying on the OS's implicit dependency features seems to be an
> >> approach which is fraught with peril.
> >
> > why ?
>
> When viewing the issue through Linux package-maintainer spectacles
On Tue, 25 Aug 2009, Mike Frysinger wrote:
Relying on the OS's implicit dependency features seems to be an
approach which is fraught with peril.
why ?
When viewing the issue through Linux package-maintainer spectacles
everything looks pretty straightforward since the environment and
packag
On Tue, 2009-08-25 at 18:34 +0300, Anssi Hannula wrote:
> You mean to subscribe on the debian development list? I'd think this
> list would be the more appropriate place for discussing a proper
> upstream solution.
There is no need to subscribe, just ask people to CC you. I'm unsure if
you'll get
On Tuesday 25 August 2009 11:17:49 Bob Friesenhahn wrote:
> On Tue, 25 Aug 2009, Anssi Hannula wrote:
> > I think the proper way to solve this is to not link to dependency_libs
> > when linking dynamically on systems where it is not needed to link to
> > those. I haven't seen any correctly working
Paul Wise wrote:
> On Tue, 2009-08-25 at 17:46 +0300, Anssi Hannula wrote:
>
>> I don't understand what the proposed dependency_libs_shared would be for.
>>
>> dependency_libs contains the dependencies of a library. These are needed
>> when linking statically. These are also needed when linking dy
On Tue, 25 Aug 2009, Anssi Hannula wrote:
I think the proper way to solve this is to not link to dependency_libs
when linking dynamically on systems where it is not needed to link to
those. I haven't seen any correctly working patches that implement this.
Relying on the OS's implicit dependenc
On Tue, 2009-08-25 at 17:46 +0300, Anssi Hannula wrote:
> I don't understand what the proposed dependency_libs_shared would be for.
>
> dependency_libs contains the dependencies of a library. These are needed
> when linking statically. These are also needed when linking dynamically,
> but only on
Paul Wise wrote:
> Just so you know, Debian is removing all .la files where possible or
> emptying dependency_libs where not possible:
>
> http://lists.debian.org/debian-devel/2009/08/msg00783.html
> http://lists.debian.org/debian-release/2009/08/threads.html#00217
> http://lists.debian.org/debian
Hi,
Just so you know, Debian is removing all .la files where possible or
emptying dependency_libs where not possible:
http://lists.debian.org/debian-devel/2009/08/msg00783.html
http://lists.debian.org/debian-release/2009/08/threads.html#00217
http://lists.debian.org/debian-devel/2009/08/thrd2.htm
46 matches
Mail list logo
