* Jakub Wilk , 2016-04-14, 18:06:
It would be helpful if we could check if a dynamic binary is linked to
a static library from another package; but I'm not aware of any
reliable method to implement such check.
Maybe we could exploit the fact that static libraries are normally
stripped, unlike
On Apr 19 2016, Bas Wijnen wrote:
> On Thu, Apr 14, 2016 at 02:57:00PM +0200, Vincent Danjean wrote:
>> > If users have such specialized needs, I think it is not only reasonable
>> > that
>> > they build their own versions of their libraries; I expect them to prefer
>> > that.
>> > So we should
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, Apr 19, 2016 at 10:13:28PM +0200, Vincent Danjean wrote:
> The initial argument was:
> > We in Debian are in a good position to defend our users from the
> > fallout from this problem. We could change our default compiler
> > options to favour
Le 19/04/2016 19:57, Bas Wijnen a écrit :
> You seem to suggest that we should compile for
> maximum performance, at the cost of security, because some people want that.
No. Reread what I wrote.
I think security is important but this is only one thing between many.
I'm convinced that we cou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 14, 2016 at 02:57:00PM +0200, Vincent Danjean wrote:
> > If users have such specialized needs, I think it is not only reasonable that
> > they build their own versions of their libraries; I expect them to prefer
> > that.
> > So we should
On 2016-04-13 17:19, Vincent Lefevre wrote:
On 2016-04-13 12:40:39 +0100, Ian Jackson wrote:
Vincent Lefevre writes ("Re: Packaging of static libraries"):
Note that by default, shared libraries would still be used, so that
this would affect only users with specific applications, who
On 2016-04-13 15:29, Ian Jackson wrote:
Adam Borowski writes ("Re: Packaging of static libraries"):
On Tue, Apr 12, 2016 at 02:52:33PM +0100, Ian Jackson wrote:
I'm afraid that LTO is probably too dangerous to be used as a
substitute for static linking. See my comments in
* Milan Kupcevic , 2016-04-10, 20:34:
We should change policy and packaging tools such that static
linking are not enabled by default and only enabled when there is a
good reason to do so; when requested by users or when there is some
other
No, we should not.
+1
A lintian check should suffic
Le 13/04/2016 20:02, Bas Wijnen a écrit :
> On Wed, Apr 13, 2016 at 05:17:54PM +0200, Marco d'Itri wrote:
>> On Apr 13, Ian Jackson wrote:
>>> We in Debian are in a good position to defend our users from the
>>> fallout from this problem. We could change our default compiler
>>> options to favour
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, Apr 13, 2016 at 05:17:54PM +0200, Marco d'Itri wrote:
> On Apr 13, Ian Jackson wrote:
> > We in Debian are in a good position to defend our users from the
> > fallout from this problem. We could change our default compiler
> > options to favo
On Apr 13, Ian Jackson wrote:
> We in Debian are in a good position to defend our users from the
> fallout from this problem. We could change our default compiler
> options to favour safety, and provide more traditional semantics.
Which would not solve any problem in this case, because then the
On 2016-04-13 12:40:39 +0100, Ian Jackson wrote:
> Vincent Lefevre writes ("Re: Packaging of static libraries"):
> > Note that by default, shared libraries would still be used, so that
> > this would affect only users with specific applications, who would
> > want
Adam Borowski writes ("Re: Packaging of static libraries"):
> On Tue, Apr 12, 2016 at 02:52:33PM +0100, Ian Jackson wrote:
> > I'm afraid that LTO is probably too dangerous to be used as a
> > substitute for static linking. See my comments in the recent LTO
> &
Vincent Lefevre writes ("Re: Packaging of static libraries"):
> On 2016-04-12 14:52:33 +0100, Ian Jackson wrote:
> > I'm afraid that LTO is probably too dangerous to be used as a
> > substitute for static linking. See my comments in the recent LTO
> > thread h
On Tue, Apr 12, 2016 at 02:52:33PM +0100, Ian Jackson wrote:
> Vincent Lefevre writes ("Re: Packaging of static libraries"):
> > On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote:
> > > (1) When performance matters. Here we need the static library to be
On 2016-04-12 14:52:33 +0100, Ian Jackson wrote:
> I'm afraid that LTO is probably too dangerous to be used as a
> substitute for static linking. See my comments in the recent LTO
> thread here, where I referred to the problem of undefined behaviour,
> and pointed at John Regehr's blog.
This is n
Vincent Lefevre writes ("Re: Packaging of static libraries"):
> On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote:
> > (1) When performance matters. Here we need the static library to be
> > built without position independent code. This can still give several
>
On 2016-04-10 14:28:02 +0100, Alastair McKinstry wrote:
> (1) When performance matters. Here we need the static library to be
> built without position independent code. This can still give several
> percent gains depending on arch / programming language.
Yes, but in that case, the best thing to do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Apr 11, 2016 at 03:25:46PM +0900, Mike Hommey wrote:
> > What uses require PIC static libraries that cannot be satisfied by building
> > -static --whole-archive ?
>
> https://wiki.debian.org/Hardening#DEB_BUILD_HARDENING_PIE_.28gcc.2Fg.2B-.2B-
On 2016-04-11, Alastair McKinstry wrote:
> What uses require PIC static libraries that cannot be satisfied by building
> -static --whole-archive ?
Linking a static library into a dynamic library.
/Sune
On Mon, Apr 11, 2016 at 06:44:45AM +0100, Alastair McKinstry wrote:
>
>
> On 10/04/2016 23:08, Mike Hommey wrote:
> > On Sun, Apr 10, 2016 at 02:28:02PM +0100, Alastair McKinstry wrote:
> >>
> >> On 10/04/2016 08:05, Andreas Tille wrote:
> >>> Hi,
> >>>
> >>> > The only use case I could imagine
On 10/04/2016 23:08, Mike Hommey wrote:
> On Sun, Apr 10, 2016 at 02:28:02PM +0100, Alastair McKinstry wrote:
>>
>> On 10/04/2016 08:05, Andreas Tille wrote:
>>> Hi,
>>>
>>> > The only use case I could imagine is to create an executable that can
>>> > run outside of Debian.
>> Static builds a
On 04/10/2016 06:05 PM, Jakub Wilk wrote:
> * Milan Kupcevic , 2016-04-10, 16:51:
We should change policy and packaging tools such that static linking
are not enabled by default and only enabled when there is a good
reason to do so; when requested by users or when there is some other
Mike Hommey writes:
> That's the funny part. Some use cases require non-PIC static libraries,
> and others require PIC static libraries. Should we then ship both? I
> think we can all agree that would be terrible.
Actually, if the library is needed in both forms, it's not that bad of an
idea.
On Sun, Apr 10, 2016 at 02:28:02PM +0100, Alastair McKinstry wrote:
>
>
> On 10/04/2016 08:05, Andreas Tille wrote:
> > Hi,
> >
> > > The only use case I could imagine is to create an executable that can
> > > run outside of Debian.
> Static builds are still common in (parts of) scientific co
* Milan Kupcevic , 2016-04-10, 16:51:
We should change policy and packaging tools such that static linking
are not enabled by default and only enabled when there is a good
reason to do so; when requested by users or when there is some other
No, we should not.
+1
A lintian check should suffic
On 04/10/2016 12:15 PM, Clint Adams wrote:
> On Mon, Apr 11, 2016 at 12:13:20AM +0800, Paul Wise wrote:
>> We should change policy and packaging tools such that static linking
>> are not enabled by default and only enabled when there is a good
>> reason to do so; when requested by users or when the
On Sun, Apr 10, 2016 at 10:24 PM, Henrique de Moraes Holschuh <
h...@debian.org> wrote:
> 1) make it clearn that static linking is to be used only when strongly
> justified (e.g. system rescue tools like sash).
>
>
As I see it, static libraries are mostly meant for the end-user, not for
distribut
On Sun, 10 Apr 2016, Clint Adams wrote:
> On Mon, Apr 11, 2016 at 12:13:20AM +0800, Paul Wise wrote:
> > We should change policy and packaging tools such that static linking
> > are not enabled by default and only enabled when there is a good
> > reason to do so; when requested by users or when the
Alastair McKinstry:
>
>
> On 10/04/2016 08:05, Andreas Tille wrote:
>> Hi,
>>
>> > The only use case I could imagine is to create an executable that can
>> > run outside of Debian.
> Static builds are still common in (parts of) scientific computing.
> Two main reasons:
>
> (1) When performan
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sun, Apr 10, 2016 at 09:06:50PM +0500, Andrey Rahmatullin wrote:
> On Sun, Apr 10, 2016 at 05:57:16PM +0200, Andreas Tille wrote:
> > > > whether it is advisable to try hard to provide static libraries even if
> > > > upstream build system does not
On Mon, Apr 11, 2016 at 12:13:20AM +0800, Paul Wise wrote:
> We should change policy and packaging tools such that static linking
> are not enabled by default and only enabled when there is a good
> reason to do so; when requested by users or when there is some other
No, we should not.
On Sun, Apr 10, 2016 at 11:57 PM, Andreas Tille wrote:
> I do not mind about the severity of the bug (since IMHO also wishlist
> bugs should be closed). My point was that to my understanding people
> are misunderstanding policy when giving the advise to ignore static
> library.
We should change
On Sun, Apr 10, 2016 at 05:57:16PM +0200, Andreas Tille wrote:
> > > whether it is advisable to try hard to provide static libraries even if
> > > upstream build system does not easily provide both.
> > Note that it's only a wishlist severity bug if you don't provide it.
> I do not mind about the s
On Sun, Apr 10, 2016 at 07:12:05PM +0500, Andrey Rahmatullin wrote:
> On Sun, Apr 10, 2016 at 09:05:36AM +0200, Andreas Tille wrote:
> > whether it is advisable to try hard to provide static libraries even if
> > upstream build system does not easily provide both.
> Note that it's only a wishlist s
On Sun, Apr 10, 2016 at 09:05:36AM +0200, Andreas Tille wrote:
> whether it is advisable to try hard to provide static libraries even if
> upstream build system does not easily provide both.
Note that it's only a wishlist severity bug if you don't provide it.
--
WBR, wRAR
signature.asc
Descript
On 10/04/2016 08:05, Andreas Tille wrote:
> Hi,
>
> > The only use case I could imagine is to create an executable that can
> > run outside of Debian.
Static builds are still common in (parts of) scientific computing.
Two main reasons:
(1) When performance matters. Here we need the static li
Hi,
when I was asking for help to create shared *and* static library on
Debian Mentors list[0] I received two answers that static libraries
are not needed. My reply
Policy says[1]:
The static library (libraryname.a) is usually provided in addition to
the shared version.
I have no go
38 matches
Mail list logo
