On Tue, Oct 4, 2011 at 11:33 AM, Roger Leigh wrote:
> On Tue, Oct 04, 2011 at 09:29:27AM +0200, Bastien ROUCARIES wrote:
>> On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote:
>> > On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote:
>> >> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weim
On Tue, Oct 04, 2011 at 09:29:27AM +0200, Bastien ROUCARIES wrote:
> On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote:
> > On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote:
> >> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
> >> > Not necessarily. -fPIC and -fPIE force
On Mon, Oct 3, 2011 at 7:31 PM, Bernhard R. Link wrote:
> * Bastien ROUCARIES [111003 17:27]:
>> > Not necessarily. -fPIC and -fPIE force calls to global functions
>> > defined in the same translation unit to go through the PLT. They
>> > aren't translated to direct IP-relative calls. For -fPI
On Mon, Oct 3, 2011 at 8:33 PM, Simon McVittie wrote:
> On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote:
>> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
>> > Not necessarily. -fPIC and -fPIE force calls to global functions
>> > defined in the same translation unit to go t
On Mon, 03 Oct 2011 at 17:11:21 +0200, Bastien ROUCARIES wrote:
> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
> > Not necessarily. -fPIC and -fPIE force calls to global functions
> > defined in the same translation unit to go through the PLT. They
> > aren't translated to direct IP-rel
* Alastair McKinstry [111003 12:48]:
> I would defend static libs for scientific apps. Static libs show a
> significant performance
> benefit (2-40%, median around 5-10% but sometimes far more with C++
> apps)
Are those numbers only the position independent code (I guess mostly
the register avail
* Bastien ROUCARIES [111003 17:27]:
> > Not necessarily. -fPIC and -fPIE force calls to global functions
> > defined in the same translation unit to go through the PLT. They
> > aren't translated to direct IP-relative calls. For -fPIC, this is
> > required by the ELF specification (no kidding,
On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
> * Adam Borowski:
>
>>> I would defend static libs for scientific apps. Static libs show a
>>> significant performance benefit (2-40%, median around 5-10% but sometimes
>>> far more with C++ apps) and so are standard in HPC still;
>>
>> If you
* Bastien ROUCARIES:
> On Mon, Oct 3, 2011 at 3:02 PM, Florian Weimer wrote:
>> * Adam Borowski:
>>
I would defend static libs for scientific apps. Static libs show a
significant performance benefit (2-40%, median around 5-10% but sometimes
far more with C++ apps) and so are standa
* Adam Borowski:
>> I would defend static libs for scientific apps. Static libs show a
>> significant performance benefit (2-40%, median around 5-10% but sometimes
>> far more with C++ apps) and so are standard in HPC still;
>
> If you see that big a difference, you do a lot of cross-file calls in
* Henrique de Moraes Holschuh:
> On Sun, 02 Oct 2011, Florian Weimer wrote:
>> Couldn't we get rid of static libraries altogether, replacing static
>> linking with ahead-of-time dynamic linking?
>
> Well, the normal usecase for static libraries and static linking is to
> produce self-contained obj
On Mon, Oct 03, 2011 at 11:20:11AM +0100, Alastair McKinstry wrote:
> On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote:
> >On Sun, 02 Oct 2011, Florian Weimer wrote:
> >>Couldn't we get rid of static libraries altogether, replacing static
> >>linking with ahead-of-time dynamic linking?
> >
>
On 2011-10-02 23:08, Henrique de Moraes Holschuh wrote:
On Sun, 02 Oct 2011, Florian Weimer wrote:
Couldn't we get rid of static libraries altogether, replacing static
linking with ahead-of-time dynamic linking?
[1] but I don't feel strong enough about it to get in the way if we do
decide to d
On Sun, 02 Oct 2011, Florian Weimer wrote:
> Couldn't we get rid of static libraries altogether, replacing static
> linking with ahead-of-time dynamic linking?
Well, the normal usecase for static libraries and static linking is to
produce self-contained objects. If you can link a bunch of dynamic
* Florian Weimer (f...@deneb.enyo.de) [111002 21:59]:
> Couldn't we get rid of static libraries altogether, replacing static
> linking with ahead-of-time dynamic linking?
Could you explain what this means for people not so deep into that?
(E.g. how is the linking done? When? What does that mean fo
* Kees Cook:
> When we decide to build an entire architecture as PIE, then we'll also need
> to build those static libs with -fPIE too.
Couldn't we get rid of static libraries altogether, replacing static
linking with ahead-of-time dynamic linking?
There's still a theoretical difference between
On Thu, Sep 29, 2011 at 06:41:29AM +0900, Charles Plessy wrote:
> Le Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook a écrit :
> > On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> > > Two hardening features are not enabled by default: PIE and bindnow.
> > > If your package su
On Wed, Sep 28, 2011 at 11:38:06PM +0200, Mike Hommey wrote:
> On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote:
> > On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> > > Just to be explicit, PIE tends to have small (<1%) performance hits on
> > > register-starved architecture
On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote:
> On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> > Just to be explicit, PIE tends to have small (<1%) performance hits on
> > register-starved architectures (i386) in most cases, for for certain work
> > loads (e.g. python)
Le Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook a écrit :
> On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> > Two hardening features are not enabled by default: PIE and bindnow.
> > If your package supports PIE, you might want to consider enabling it.
> > If the binarie
On Wed, Sep 28, 2011 at 10:52:15PM +0300, Riku Voipio wrote:
> On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> > Just to be explicit, PIE tends to have small (<1%) performance hits on
> > register-starved architectures (i386) in most cases, for for certain work
> > loads (e.g. python)
On Tue, Sep 27, 2011 at 06:01:54PM -0700, Kees Cook wrote:
> Just to be explicit, PIE tends to have small (<1%) performance hits on
> register-starved architectures (i386) in most cases, for for certain work
> loads (e.g. python) the hit is large (~15%). On architectures with plenty
> of registers
* Ian Jackson [110927 20:21]:
> Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> > things to be in a users environment, so a package's rules file should
> > in
On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> Two hardening features are not enabled by default: PIE and bindnow.
> If your package supports PIE, you might want to consider enabling it.
> If the binaries are long running processes like daemons, and as such
> the startup
Bernhard R. Link writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> CFLAGS and LDFLAGS (and CPPFLAGS and so on) are in my opionion normal
> things to be in a users environment, so a package's rules file should
> in my eyes not depend on them not being set or ha
* Bernd Zeimetz [110927 15:36]:
> > I'm one of the submitters of one of the bugs which requested this
> > change. This is a reversion of dpkg to a previous behaviour, and it
> > /un/breaks packages. Or at least I think it unbreaks much more than
> > it breaks.
>
> ACtually I think that is true -
On 09/24/2011 05:48 PM, Ian Jackson wrote:
> Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
>> Raphael Hertzog wrote:
>>> * dpkg-buildpackage no longer exports
>>> CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
>>
>> | You don
I wrote:
> Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> > My concern is that we now have a whole history of ill-considered changes
> > to the build flags. To the point that it's possible to argue that every
> > build flag change save one*
Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Ian Jackson wrote:
> > It was always completely wrong of dpkg-buildpackage to set these
> > variables. Source packages are entitled to assume that strange
> > environment variables which cause th
On Monday, September 26, 2011 08:21:19 PM Raphael Hertzog wrote:
> On Mon, 26 Sep 2011, Scott Kitterman wrote:
> > I can see where this might be useful for final work before an upload,
> > what is one expected to do when one is doing successive builds where
> > things change every time while workin
On Mon, 26 Sep 2011, Scott Kitterman wrote:
> I can see where this might be useful for final work before an upload, what is
> one expected to do when one is doing successive builds where things change
> every time while working on a package? dpkg-buildpackage -b, "Oh, fail",
> "dpkg-source --co
On Friday, September 23, 2011 08:17:54 AM Raphael Hertzog wrote:
> * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail
> if it detects upstream changes which are not managed by a quilt patch.
>
> You are expected to call “dpkg-source --commit” if you want to
> record thos
On Mon, Sep 26, 2011 at 12:26 AM, Michael Gilbert wrote:
> I should have been more explicit. I was referring to dpkg-buildflags
> default outputs above.
I see, agreed then.
> I'm ok with the fact that each individual package will need to
> be changed to support this (vice forcing it into gcc).
Paul Wise wrote:
> On Sun, Sep 25, 2011 at 5:11 AM, Michael Gilbert wrote:
>
> > I think it would be better to enable all security-enhancing flags by
> > default (at least all of the included ones so far, which are fairly
> > well-tested). Yes, these two do have a larger potential to reduce
> > p
On Sat, 24 Sep 2011, Charles Plessy wrote:
> If in a large number of cases where one would like to turn off the patch
> system
> of the 3.0 (quilt) format, the source package is stored in a Git repository,
> then one way to move forward would be to make the format 3.0 (git) available
> in Debian.
On Sat, Sep 24, 2011 at 2:30 PM, Charles Plessy wrote:
> If in a large number of cases where one would like to turn off the patch
> system
> of the 3.0 (quilt) format, the source package is stored in a Git repository,
> then one way to move forward would be to make the format 3.0 (git) available
Ian Jackson wrote:
> I'm one of the submitters of one of the bugs which requested this
> change. This is a reversion of dpkg to a previous behaviour, and it
> /un/breaks packages. Or at least I think it unbreaks much more than
> it breaks.
>
> It was always completely wrong of dpkg-buildpackage
On Sun, Sep 25, 2011 at 5:11 AM, Michael Gilbert wrote:
> I think it would be better to enable all security-enhancing flags by
> default (at least all of the included ones so far, which are fairly
> well-tested). Yes, these two do have a larger potential to reduce
> performance, but its also suffi
berta...@ptitcanardnoir.org wrote:
> On Fri, Sep 23, 2011 at 11:53:36AM +0200, Marco d'Itri wrote:
> > On Sep 23, Raphael Hertzog wrote:
> >
> > > Two hardening features are not enabled by default: PIE and bindnow.
> > Why?
>
> I guess because they have more impact on performance than the oth
Joey Hess writes ("Re: Bits from dpkg developers - dpkg 1.16.1"):
> Raphael Hertzog wrote:
> > * dpkg-buildpackage no longer exports
> > CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
>
> | You don't know how many packages are broken or no longer
> | policy compl
Hello everybody,
If in a large number of cases where one would like to turn off the patch system
of the 3.0 (quilt) format, the source package is stored in a Git repository,
then one way to move forward would be to make the format 3.0 (git) available
in Debian. What are the blocking points ?
Che
On Fri, 23 Sep 2011 08:17:54 +0200, Raphael Hertzog wrote:
> * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail
> if it detects upstream changes which are not managed by a quilt patch.
> * When dpkg-source automatically applies patches at the start of the
> build process,
Raphael Hertzog wrote:
> * dpkg-buildpackage no longer exports CFLAGS/CXXFLAGS/LDFLAGS/CPPFLAGS/FFLAGS
| You don't know how many packages are broken or no longer
| policy compliant because they were relying on those environment
| variables
Who said that? Oh, yeah it was you.
How are we supposed
On Fri, 23 Sep 2011, Adam Borowski wrote:
> Old-style: rm -rf .pc debian/patches
> New-style: echo "single-debian-patch" >debian/source/options
--single-debian-patch is no longer "new" at this point. The fact that you
were not using it and relying on dpkg-source to generate a different patch
at ea
On Fri, Sep 23, 2011 at 11:53:36AM +0200, Marco d'Itri wrote:
> On Sep 23, Raphael Hertzog wrote:
>
> > Two hardening features are not enabled by default: PIE and bindnow.
> Why?
I guess because they have more impact on performance than the others.
> > If your package supports PIE, you migh
On Fri, Sep 23, 2011 at 08:17:54AM +0200, Raphael Hertzog wrote:
> we just released dpkg 1.16.1 to unstable. It comes with several disruptive
> changes that you need to be aware of. Please read carefully.
> * “dpkg-source -b” on a “2.0” or “3.0 (quilt)” source package will fail
> if it detects u
On Sep 23, Raphael Hertzog wrote:
> Two hardening features are not enabled by default: PIE and bindnow.
Why?
> If your package supports PIE, you might want to consider enabling it.
> If the binaries are long running processes like daemons, and as such
> the startup performance penalty of
47 matches
Mail list logo
