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.
>
Re-ordering paragraphs...
> Not on all systems, but I think that will happen with gcc/ld though.
> I think they will only export dllexported symbols if at least one such
> symbol exist. However, this causes some trouble if you e.g. have a
> library that is not decorated with dllexport and which us
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
31 matches
Mail list logo
