Update Debian policy for Multi-Arch

[Francois Gouget]

A large number of packages, particularly development packages, are not 
multi-arch aware. This raises the barrier of entry for performing 32 bit 
development on a 64 bit system and actively hurts some projects like 
Wine where it is very important to be able to compile both versions.

Looking into this I found that multi-arch was a release goal of Debian 7 
(Wheezy) and that it is marked as completed:

https://wiki.debian.org/ReleaseGoals/


So I looked to see whether the Debian Policy was saying multi-arch is a 
should, a must or something else.

It turns out it does not say anything of value: multi-arch is mentioned 
as being an exception to the FHS in section "9.1.1 File System 
Structure" and in footnotes 60, 78 and 79. That's all!


That does not seem compatible with multi-arch being a completed goal of 
the old-stable release. So what about adding a section like this:


   3.10 Multi-arch support

   Packages must be multi-arch aware and architecture-specific 
   development packages must be tagged as Multi-Arch: same.


-- 
Francois Gouget   http://fgouget.free.fr/
 Advice is what we ask for when we already know the answer but wish we didn't
 -- Eric Jong

Re: Update Debian policy for Multi-Arch

[Holger Levsen]

On Tue, May 03, 2016 at 11:23:40AM +0200, Francois Gouget wrote:
> So I looked to see whether the Debian Policy was saying multi-arch is a 
> should, a must or something else.
> 
> It turns out it does not say anything of value: multi-arch is mentioned 
> as being an exception to the FHS in section "9.1.1 File System 
> Structure" and in footnotes 60, 78 and 79. That's all!

yes, that's rather odd and annoying. it would be great if someone could
pick up the existing work and make sure Multi-Arch *is* properly
documented in policy…

> That does not seem compatible with multi-arch being a completed goal of 
> the old-stable release. So what about adding a section like this:

there are already 7 or so bugs about multi-arch missing in various
places in policy, I'd suggest you go to the BTS, search for those and
help there.


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Update Debian policy for Multi-Arch

[Simon McVittie]

On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:
> A large number of packages, particularly development packages, are not 
> multi-arch aware.
...
>3.10 Multi-arch support
> 
>Packages must be multi-arch aware and architecture-specific 
>development packages must be tagged as Multi-Arch: same.

See  if you want to push
this forward.

However, I suspect the Policy editors will object that Policy normally
documents what is already broadly true, not what someone wants to be true
(even if the desired state is widely agreed to be what the project wants).

A mass-bug-filing or mass-patch-attaching to make libraries and development
packages Multi-arch: same would be more in line with how things like this
usually go.

Note that for the subset of development packages that contain
architecture-specific binaries in $PATH (most commonly "foo-config"), it is
not trivial to switch to Multi-arch: same without breaking existing
reverse-dependencies.

S

Re: Update Debian policy for Multi-Arch

[Francois Gouget]

On Tue, 3 May 2016, Holger Levsen wrote:
[...]
> there are already 7 or so bugs about multi-arch missing in various
> places in policy, I'd suggest you go to the BTS, search for those and
> help there.

Those are not the same. They are about documenting various aspects of 
multi-arch, not about stating whether multi-arch *should* or *must* be 
implemented by packages.

For reference here are the multi-arch policy bugs that I could find:

621050 - Document dependencies needed to use multiarch paths
Last updated 11 months ago

636383 - debian-policy: 10.2 and others: private libraries may also be 
multi-arch-ified
Last updated over 4 years ago

650974 - Make Policy references to /usr/lib multiarch-aware
Last updated over 4 years ago

684672 - document multiarch tuple definitions
Last updated over 4 years ago

687900 - document multiarch
Last updated 13 months ago

748380 - perl-policy: @INC changes for multiarch
Last updated 19 months ago

749826 - debian-policy: [multiarch] please document the use of Multi-Arch field 
in debian/control
Opened 23 months ago, never updated

759101 - Minor warning if "Multi-Arch: no" is used as it's the default
Last updated 19 months ago

798309 - debian-policy: Adjustments to perl policy for multi-arch
Last updated 4 months ago


As for contributing I've tried to contribute to packages but so far the 
feed back I have gotten is mostly a whole lot of nothing (as is most 
often the case with Debian). So that's not very motivating.


-- 
Francois Gouget   http://fgouget.free.fr/
 Any sufficiently advanced technology is indistinguishable from magic.
Arthur C. Clarke

Bug#823320: ITP: r-cran-maptree -- GNU R package "maptree: Mapping, pruning, and graphing tree models"

[Pablo Oliveira]

Package: wnpp
Severity: wishlist
Owner: Pablo Oliveira 
User: debian-scie...@lists.debian.org
Usertags: field..statistics

  Package name: r-cran-maptree
  Version : 1.4-7
  Upstream Author : Denis White, Robert B. Gramacy 
  URL : https://cran.r-project.org/web/packages/maptree/
  License : Unlimited 
  Programming Lang: R 
  Description : GNU R package "maptree: Mapping, pruning, and graphing tree 
models"

r-cran-maptree is a CRAN package. The CRAN description of the package follows:

 Functions with example data for graphing, pruning, and mapping models
 from hierarchical clustering, and classification and regression trees.

This package has become a dependency for r-cran-tgp 2.4-14,
I would like to package r-cran-maptree so we can update r-cran-tgp
to the latest upstream version (2.4-14).

Bug#823321: ITP: python3-protobuf3 -- Implementation of Google's Protocol Buffers for Python 3

[Jonathon Love]

Package: wnpp
Severity: wishlist
Owner: Jonathon Love 

* Package name: python3-protobuf3
  Version : 0.2.1
  Upstream Author : Sergey Petrov 
* URL : https://github.com/Pr0Ger/protobuf3
* License : MIT
  Programming Lang: Python
  Description : Implementation of Google's Protocol Buffers for Python 3

python3-protobuf3 provides an implementation of Google's Protocol
 Buffers for Python 3

python3-protobuf3 is being packaged by Jonathon Love

Re: Update Debian policy for Multi-Arch

[Cyril Brulebois]

Simon McVittie  (2016-05-03):
> On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:
> > A large number of packages, particularly development packages, are not 
> > multi-arch aware.
> ...
> >3.10 Multi-arch support
> > 
> >Packages must be multi-arch aware and architecture-specific 
> >development packages must be tagged as Multi-Arch: same.
> 
> See  if you want to push
> this forward.
> 
> However, I suspect the Policy editors will object that Policy normally
> documents what is already broadly true, not what someone wants to be true
> (even if the desired state is widely agreed to be what the project wants).
> 
> A mass-bug-filing or mass-patch-attaching to make libraries and development
> packages Multi-arch: same would be more in line with how things like this
> usually go.
> 
> Note that for the subset of development packages that contain
> architecture-specific binaries in $PATH (most commonly "foo-config"), it is
> not trivial to switch to Multi-arch: same without breaking existing
> reverse-dependencies.

Well, sure. But Policy could certainly start containing documentation
about multi-arch being a possibility, and how it should be implemented
in a given (set of) package(s). A few years back, or right now. :)

Making it a should or must (not even sure it makes sense to have that
mandatory) would be another long-reaching step.


KiBi.


signature.asc
Description: Digital signature

Re: Update Debian policy for Multi-Arch

[Wookey]

+++ Holger Levsen [2016-05-03 11:33 +0200]:
> On Tue, May 03, 2016 at 11:23:40AM +0200, Francois Gouget wrote:
> > So I looked to see whether the Debian Policy was saying multi-arch is a 
> > should, a must or something else.
> > 
> > It turns out it does not say anything of value: multi-arch is mentioned 
> > as being an exception to the FHS in section "9.1.1 File System 
> > Structure" and in footnotes 60, 78 and 79. That's all!
> 
> yes, that's rather odd and annoying. it would be great if someone could
> pick up the existing work and make sure Multi-Arch *is* properly
> documented in policy…

Yes, it's very embarassing that it's not in policy. 

However, I tried once and found that it was hard!

The form of the multiarch spec is very different to the form of
policy. And as soon as you start to write policy you realise that you
need to know about all sorts of corner cases. Trying to find out those
caused us to discover that apt and dpkg disgreed which didn't help
with documentation.

At last year's debconf mini-sprint we sorted out those inconsistencies
(by deciding to do it as dpkg did), and I believe that apt and
aptitude have been changed to match. However SFAIK no-one has tried
again to update policy (including me). 

Yes, lots of people have noticed that it needs doing. Not that many
people understand it well enough to do so.

I've not got any spare cycles at the moment (climate change action a
more pressing issue than Debian's policiy omissions :-) but I will try
and help if someone gets enthused, and I might get back to another
attempt in a few months if not.

> > That does not seem compatible with multi-arch being a completed goal of 
> > the old-stable release. So what about adding a section like this:
> 
> there are already 7 or so bugs about multi-arch missing in various
> places in policy, I'd suggest you go to the BTS, search for those and
> help there.

Right.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Update Debian policy for Multi-Arch

[Holger Levsen]

On Tue, May 03, 2016 at 02:33:34PM +0200, Francois Gouget wrote:
> Those are not the same. They are about documenting various aspects of 
> multi-arch, not about stating whether multi-arch *should* or *must* be 
> implemented by packages.

well, before we can require something must be implemented, we surely
also must document what exactly and how. Or? :)

> For reference here are the multi-arch policy bugs that I could find:
[...]
> 687900 - document multiarch

IIRC this is blocking the others, so you could take this as the one
requiring multi-arch readyness for a package.

Also: time has passed indeed and it seems by now Multi-Arch is not
controversial anymore. The only thing blocking further widespread usage
is probably documentation and a change in policy indeed. So the next
step should be to either updating policy bugs with patches for the
concrete wordings or updating these bugs saying that old patches still
make sense today.
 
> As for contributing I've tried to contribute to packages but so far the 
> feed back I have gotten is mostly a whole lot of nothing (as is most 
> often the case with Debian). So that's not very motivating.

Maybe this time things will be different. Please keep trying. I'd be very
happy to finally see Multi-Arch propoerly documented in debian-policy one
day! :-)


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Update Debian policy for Multi-Arch

[Matthias Klose]

On 03.05.2016 13:25, Simon McVittie wrote:

On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:

A large number of packages, particularly development packages, are not
multi-arch aware.

...

3.10 Multi-arch support

Packages must be multi-arch aware and architecture-specific
development packages must be tagged as Multi-Arch: same.


See  if you want to push
this forward.

However, I suspect the Policy editors will object that Policy normally
documents what is already broadly true, not what someone wants to be true
(even if the desired state is widely agreed to be what the project wants).


What is "broadly true"?  If you look at the whole archive, multiarch certainly 
doesn't apply to the term "broadly".  If you look at a subset, like packages 
involved in bootstrapping a essential or build-essential environment, or looking 
at a desktop image, then the term "broadly" applies more.


A mass-bug-filing or mass-patch-attaching to make libraries and development
packages Multi-arch: same would be more in line with how things like this
usually go.


Sure, but even if you provide patches in these bug reports, some package 
maintainers ignore these patches or even refuse to apply those because *they* 
don't like multiarch, blocking goals like cross-buildability.


So what would make more sense would be to first establish best practices to make 
packages multiarch aware, and then file bug reports pointing to such best 
practices. Config scripts is one example, another is one packages bundling 
shared libraries and plugins in the same binary package.



Note that for the subset of development packages that contain
architecture-specific binaries in $PATH (most commonly "foo-config"), it is
not trivial to switch to Multi-arch: same without breaking existing
reverse-dependencies.


That doesn't have to be true. For this particular example, you could:

 - split out the binary into a new package (e.g. splitting out the
   seldom used libtool binary into libtool-bin) and then fix things.

 - modifying the script to remove multiarch bits like removing paths
   inc --cflags or --ldflags/--libs options, because these libs are
   on the standard path anyway.

 - removing options like --includedir/--libdir and returning an
   error when this option is used. Most of these scripts are
   historical, and ship a pkg-config file as well.  Of course things
   can break, but not silently.

Unbundling plugins and shared libs is probably more problematic, assuming you'll 
keep the name for the shared library package, and introducing a new binary for 
the plugins. You'll now have to find out for each reverse dependency of the 
original library package, if plugins are required or not.


Matthias

Re: Update Debian policy for Multi-Arch

[Wookey]

+++ Simon McVittie [2016-05-03 12:25 +0100]:
> On Tue, 03 May 2016 at 11:23:40 +0200, Francois Gouget wrote:

> A mass-bug-filing or mass-patch-attaching to make libraries and development
> packages Multi-arch: same would be more in line with how things like this
> usually go.

There has already been a _lot_ of 'please multiarch this' bugs filed
(often with patches), although it's not mostly been does as an
explicit mass-filing. -dev packages much less so because often it's
harder and the existing spec encouraged people not to bother. 

> Note that for the subset of development packages that contain
> architecture-specific binaries in $PATH (most commonly "foo-config"), it is
> not trivial to switch to Multi-arch: same without breaking existing
> reverse-dependencies.

The foo-config thing is a real pain, which is indeed holding up
various packages. We should agree Debian best-practice for these and
then start implementing it (and of course put it in policy
:-). Debconf session anyone?

This is the page that documents 'multiarchification' pratice for packagers:
https://wiki.debian.org/Multiarch/Implementation

put helpful advice there.

Wookey
-- 
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/


signature.asc
Description: Digital signature

Re: Update Debian policy for Multi-Arch

[Matthias Klose]

On 03.05.2016 11:33, Holger Levsen wrote:

On Tue, May 03, 2016 at 11:23:40AM +0200, Francois Gouget wrote:

So I looked to see whether the Debian Policy was saying multi-arch is a
should, a must or something else.

It turns out it does not say anything of value: multi-arch is mentioned
as being an exception to the FHS in section "9.1.1 File System
Structure" and in footnotes 60, 78 and 79. That's all!


yes, that's rather odd and annoying. it would be great if someone could
pick up the existing work and make sure Multi-Arch *is* properly
documented in policy…


That does not seem compatible with multi-arch being a completed goal of
the old-stable release. So what about adding a section like this:


there are already 7 or so bugs about multi-arch missing in various
places in policy, I'd suggest you go to the BTS, search for those and
help there.


while I understand that some bits should go to the Debian policy, there are 
others which should stay vendor neutral.  The Debian wiki might not be the best 
place to document the tuples, but the policy is neither.  So somebody might want 
to add it to the FHS, or create a separate spec on i.e. freedesktop.org.


Matthias

Bug#823342: ITP: golang-github-kr-binarydist -- Go implementation of the bspatch algorithm

[Nicolas Braud-Santoni]

Package: wnpp
Severity: wishlist
Owner: Nicolas Braud-Santoni 

* Package name: golang-github-kr-binarydist
  Version : 0.0~git20120828.0.9955b0a-1
  Upstream Author : Keith Rarick
* URL : https://github.com/kr/binarydist
* License : MIT
  Programming Lang: Go
  Description : Go implementation of the bspatch algorithm

 binarydist Package binarydist implements binary diff and patch as
 described on http://www.daemonology.net/bsdiff/. It reads and writes
 files compatible with the tools there.
 .
 Documentation at http://go.pkgdoc.org/github.com/kr/binarydist.

 This is a dependency of golang-github-inconshreveable-go-update

Time to reevaluate the cost of -fPIC?

[Josh Triplett]

Debian Policy requires the use of -fPIC for shared libraries, but
documents potential exceptions for libraries with position-dependent
assembly, and for libraries that would incur a significant performance
hit.  We can't do anything automated about the former, only fix the
assembly.  But regarding the latter, conventional wisdom advises that
-fPIC incurs a particularly high cost on x86-32, since it burns a
register across the whole program, of which the architecture has
precious few.

However, since GCC 5, that advice doesn't actually hold true anymore.
Quoting https://gcc.gnu.org/gcc-5/changes.html:
> Reuse of the PIC hard register, instead of using a fixed register, was
> implemented on x86/x86-64 targets. This improves generated PIC code
> performance as more hard registers can be used. Shared libraries can
> significantly benefit from this optimization.

While this doesn't make PIC absolutely free, it does eliminate almost
all of the cost, to the point that it no longer seems worthwhile to
build without -fPIC.  Apart from that, building *all* code with -fPIC
(including both programs and libraries) helps with hardening.

With GCC 5 already the default as of the last stable release, I think
we may want to reevaluate the conventional wisdom.  Perhaps this
information might help support the current iteration of any proposals to
adopt more hardening flags by default, for instance.

- Josh Triplett

Re: Time to reevaluate the cost of -fPIC?

[Matthias Klose]

On 03.05.2016 22:50, Josh Triplett wrote:

Debian Policy requires the use of -fPIC for shared libraries, but
documents potential exceptions for libraries with position-dependent
assembly, and for libraries that would incur a significant performance
hit.  We can't do anything automated about the former, only fix the
assembly.  But regarding the latter, conventional wisdom advises that
-fPIC incurs a particularly high cost on x86-32, since it burns a
register across the whole program, of which the architecture has
precious few.

However, since GCC 5, that advice doesn't actually hold true anymore.
Quoting https://gcc.gnu.org/gcc-5/changes.html:

Reuse of the PIC hard register, instead of using a fixed register, was
implemented on x86/x86-64 targets. This improves generated PIC code
performance as more hard registers can be used. Shared libraries can
significantly benefit from this optimization.


While this doesn't make PIC absolutely free, it does eliminate almost
all of the cost, to the point that it no longer seems worthwhile to
build without -fPIC.  Apart from that, building *all* code with -fPIC
(including both programs and libraries) helps with hardening.

With GCC 5 already the default as of the last stable release, I think
we may want to reevaluate the conventional wisdom.  Perhaps this
information might help support the current iteration of any proposals to
adopt more hardening flags by default, for instance.


No, GCC 5 is not part of jessie.

Did you intend to speak about -fPIE instead of -fPIC?

Re: Time to reevaluate the cost of -fPIC?

[Josh Triplett]

On Wed, May 04, 2016 at 12:41:25AM +0200, Matthias Klose wrote:
> On 03.05.2016 22:50, Josh Triplett wrote:
> > Debian Policy requires the use of -fPIC for shared libraries, but
> > documents potential exceptions for libraries with position-dependent
> > assembly, and for libraries that would incur a significant performance
> > hit.  We can't do anything automated about the former, only fix the
> > assembly.  But regarding the latter, conventional wisdom advises that
> > -fPIC incurs a particularly high cost on x86-32, since it burns a
> > register across the whole program, of which the architecture has
> > precious few.
> > 
> > However, since GCC 5, that advice doesn't actually hold true anymore.
> > Quoting https://gcc.gnu.org/gcc-5/changes.html:
> > > Reuse of the PIC hard register, instead of using a fixed register, was
> > > implemented on x86/x86-64 targets. This improves generated PIC code
> > > performance as more hard registers can be used. Shared libraries can
> > > significantly benefit from this optimization.
> > 
> > While this doesn't make PIC absolutely free, it does eliminate almost
> > all of the cost, to the point that it no longer seems worthwhile to
> > build without -fPIC.  Apart from that, building *all* code with -fPIC
> > (including both programs and libraries) helps with hardening.
> > 
> > With GCC 5 already the default as of the last stable release, I think
> > we may want to reevaluate the conventional wisdom.  Perhaps this
> > information might help support the current iteration of any proposals to
> > adopt more hardening flags by default, for instance.
> 
> No, GCC 5 is not part of jessie.

Misreading of https://packages.debian.org/gcc; skimmed through the
versions too quickly.

Nonetheless, GCC 5 is available in current testing and unstable, and
this optimization will apply to the next stable release, so I think the
point still holds.

> Did you intend to speak about -fPIE instead of -fPIC?

No, I was referring to -fPIC, though for an executable -fPIE would be
more appropriate.  I would hope the same optimization applies there too.

- Josh Triplett

How to properly remove obsolete init script?

[Iustin Pop]

Hi and sorry for what is a basic question, but I can't find a clear
answer.

It seems that dpkg-maintscript-helper is the tool to remove conffiles,
but it doesn't seem to have any special handling for init scripts. Which
means that simply calling "rm_conffile …" will just remove the
/etc/init.d/ script, leaving potential symlinks in /etc/rc?.d around.

The snippets inserted by dh_installinit in postrm will only call
"update-rc.d xxx remove" in case of purge, so they won't be called
during a package upgrade.

Any smarter solution than just adding code to postinst/configure with
the old version to call update-rc.d remove?

thanks,
iustin


signature.asc
Description: PGP signature

dpkg-genchanges warning for -dbgsym packages

[Iustin Pop]

Hi all,

I'm very glad for the automatic debug packages, but I wonder if I'm
doing something wrong since I get this warning:

dpkg-genchanges: warning: package foo-dbgsym listed in files list
but not in control info

The package is generated, so this mostly seems like a harmless warning.
I checked but I don't see any bug about it, and searching the internet
turns out nothing. Thoughts?

thanks,
iustin


signature.asc
Description: PGP signature

Re: dpkg-genchanges warning for -dbgsym packages

[Andrey Rahmatullin]

On Wed, May 04, 2016 at 02:06:56AM +0200, Iustin Pop wrote:
> I'm very glad for the automatic debug packages, but I wonder if I'm
> doing something wrong since I get this warning:
> 
> dpkg-genchanges: warning: package foo-dbgsym listed in files list
>   but not in control info
> 
> The package is generated, so this mostly seems like a harmless warning.
> I checked but I don't see any bug about it, and searching the internet
> turns out nothing. Thoughts?
It's harmless.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: How to properly remove obsolete init script?

[Michael Biebl]

Am 04.05.2016 um 01:21 schrieb Iustin Pop:
> Hi and sorry for what is a basic question, but I can't find a clear
> answer.
> 
> It seems that dpkg-maintscript-helper is the tool to remove conffiles,
> but it doesn't seem to have any special handling for init scripts. Which
> means that simply calling "rm_conffile …" will just remove the
> /etc/init.d/ script, leaving potential symlinks in /etc/rc?.d around.
> 
> The snippets inserted by dh_installinit in postrm will only call
> "update-rc.d xxx remove" in case of purge, so they won't be called
> during a package upgrade.
> 
> Any smarter solution than just adding code to postinst/configure with
> the old version to call update-rc.d remove?

There isn't really. So you'll have to do the cleanup manually.




-- 
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?



signature.asc
Description: OpenPGP digital signature

Bug#823381: ITP: r-cran-markdown -- GNU R package providing R bindings to the Sundown Markdown rendering library

[Andreas Tille]

Package: wnpp
Severity: wishlist
Owner: Andreas Tille 

* Package name: r-cran-markdown
  Version : 0.7.7
  Upstream Author :  Yihui Xie 
* URL : https://cran.r-project.org/web/packages/markdown
* License : GPL
  Programming Lang: R
  Description : GNU R package providing R bindings to the Sundown Markdown 
rendering library
 Provides R bindings to the Sundown Markdown rendering library by
 Vicent Marti
 e.a., based upon work by Natacha Porté. Markdown is a plain-text
 formatting syntax that can be converted to XHTML or other formats.
 .
 The R function `markdownToHTML` renders a markdown file to HTML. Options
 controlling HTML output and supported markdown extensions can be
 optionally specified.
 .
 The package also exports the underlying Sundown C extension API which
 enables creating and calling custom renderers using the
 `renderMarkdown` function.
 .
 Please note: the rmarkdown package (with leading r) converts R Markdown
 documents into even more formats, by using pandoc; the CRAN rmarkdown
 package is a newer and enhanced version of this markdown package.


Remark: This package was prepared by Joost van Baal-Ili for the Debian
Science team as a predependency for r-cran-knitr.  It will be team
maintained at
https://anonscm.debian.org/git/debian-science/packages/r-cran-markdown.git

Processed: block 820036 with 823003

[Debian Bug Tracking System]

Processing commands for cont...@bugs.debian.org:

> block 820036 with 823003
Bug #820036 [general] Debian does not run on systems with Secure Boot enabled
820036 was blocked by: 820041 821053 821055 820010 821084 820008 820052 820124 
820050 821051 820038 821054 820129 821088 821307
820036 was not blocking any bugs.
Added blocking bug(s) of 820036: 823003
> thanks
Stopping processing here.

Please contact me if you need assistance.
-- 
820036: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=820036
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Re: Time to reevaluate the cost of -fPIC?

[Marco d'Itri]

On May 03, Josh Triplett  wrote:

> While this doesn't make PIC absolutely free, it does eliminate almost
> all of the cost, to the point that it no longer seems worthwhile to
> build without -fPIC.  Apart from that, building *all* code with -fPIC
> (including both programs and libraries) helps with hardening.
I think that this is worth exploring.
Did you check what other (relevant) distributions are doing?

-- 
ciao,
Marco


signature.asc
Description: PGP signature