Re: Bug#834864: hisat2: FTBFS on kfreebsd-amd64: help2man: can't get `--help' info from ./hisat2

[Steven Chamberlain]

Tags: 834864 + patch
User: debian-bsd@lists.debian.org
Usertags: kfreebsd

Hello,

The hisat2 binary actually had this problem on kfreebsd:

| $ ./hisat2
| (ERR): Expected hisat2 to be in same directory with hisat-align:
| /build/hisat2-2.0.4/
| Exiting now ...

which happens because it looks for a different filename, when the OS is
not "linux" or "darwin".

Please see the attached patch to correctly recognise *freebsd platforms.
It fixes the hisat2 binary and the Debian package build.

(Though I might suggest to upstream, that they change the test to
"os_is_windows" and use the ordinary filename otherwise).

Thanks!
Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.org
Date: Sun, 21 Aug 2016 21:32:59 +0100
From: Steven Chamberlain 
Subject: Identify *freebsd as a UNIX-like OS

Match "gnukfreebsd" or "freebsd", when assigning $os_is_nix.

--- a/hisat2
+++ b/hisat2
@@ -45,7 +45,7 @@
 
 ($vol,$script_path,$prog) 
 = File::Spec->splitpath($prog);
-my $os_is_nix   = ($^O eq "linux") || ($^O eq "darwin");
+my $os_is_nix   = ($^O eq "linux") || ($^O eq "darwin") || ($^O =~ /freebsd$/);
 my $align_bin_s = $os_is_nix ? 'hisat2-align-s' : 'hisat2-align-s.exe'; 
 my $build_bin   = $os_is_nix ? 'hisat2-build' : 'hisat2-build.exe';
   
 my $align_bin_l = $os_is_nix ? 'hisat2-align-l' : 'hisat2-align-l.exe'; 


signature.asc
Description: Digital signature

Re: Porter roll call for Debian Stretch

[Guillem Jover]

Hi!

On Sun, 2016-08-21 at 08:22:09 +0200, Niels Thykier wrote:
> Kurt Roeckx:
> > On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
> >>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
> >>also apply to this port? [0]
> > 
> > If -fPIE is the default will -fPIC override it?
> > 
> > It will also default to tell the linker to use -pie, but then
> > don't do it when you want to create a shared library?
> 
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.

As I mentioned on IRC, the Gentoo people seems to have done so as well
in their Gentoo Hardened Toolchain project
.

> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).

I think there are some bugs tracked in Fedora about this
, And this
is what I based the dpkg patch on as a potential alternative instead
of modifying our toolchain, which I think would be preferable. But see
below.

> >>From what I understand, depending on what the .o file is going to
> > be used for you want different things:
> > - shared library: -fPIC
> > - executable: -fPIC or -fPIE both work, but prefer -fPIE
> > - static library: Same as executables
> > 
> > For static libraries we now have a policy to not use -fPIC,
> > should that then get replaced by using -fPIE?

> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I think that's what we are getting right now for any package enabling
the "pie" build flags feature anyway.

> [1] Example spec files for this case seems to be something like:
> 
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
> 
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
> 
> NB: I manually carved them out of a diff without testing them.

That would be
,
which neither I tested. Testing should first be done for gcc, g++, gcj,
gobjc, gobjc++, gccgo (although I've not managed to use shared libraries
with latest releases, but used to be able to) and gfortran. If someone
wants to test these first to see if it works and then later on do an
archive rebuild, that would also be appreciated.

At that point I could then at least switch the current implementation
so that we can just enable the "pie" feature per package regardless of
it building prorgrams or shared libraries. Enabling it by default
globally would require the usual process described in the dpkg FAQ.

Thanks,
Guillem

Re: Porter roll call for Debian Stretch

[Bálint Réczey]

Hi,

2016-08-21 8:22 GMT+02:00 Niels Thykier :
> Kurt Roeckx:
>> On Wed, Aug 17, 2016 at 10:05:06PM +0200, ni...@thykier.net wrote:
>>>  * If we were to enable -fPIE/-pie by default in GCC-6, should that change
>>>also apply to this port? [0]
>>
>> If -fPIE is the default will -fPIC override it?
>>
>> It will also default to tell the linker to use -pie, but then
>> don't do it when you want to create a shared library?
>>
>
> I believe so.  At least, Ubuntu made PIE default in their compiler
> without having to change all SO packages to still build.
>
> Admittedly, it could also be that GCC uses some built "compiler spec"
> files for this case (a la an implicit "-specs=$FILE"), which are similar
> to those Redhat uses for this purposes (see [1] for an example of such
> files).
>
> Regardless, it seems to "just work(TM)" if you pass the proper flags
> when compiling your SOs.
>
>>>From what I understand, depending on what the .o file is going to
>> be used for you want different things:
>> - shared library: -fPIC
>> - executable: -fPIC or -fPIE both work, but prefer -fPIE
>> - static library: Same as executables
>>
>> For static libraries we now have a policy to not use -fPIC,
>> should that then get replaced by using -fPIE?
>>
>>
>>
>> Kurt
>>
>
> Honestly, I had not thought about that.  From the looks of it, de facto
> we will end up with -fPIE being the default for static libraries as well.
>   I would be supporting that change on the assumption that it requires
> less work from individual maintainers (and presumably has no notable
> downsides in the final result).

I'm testing a set of patches [2] for gcc and dpkg which enable bindnow for all
arches and PIE for amd64, ppc64el and s390x in sync with Ubuntu.

My assumption was that this set of architectures need the least amount of
additional work since they are tested already in Ubuntu, but I would be happy
if more ports would opt in for PIE.

I plan filing wishlist bugs against dpkg and gcc with the patches
after I rebuilt a
few packages with the defaults.

Cheers,
Balint

[2] https://people.debian.org/~rbalint/ppa/pie-bindnow/


>
> Thanks,
> ~Niels
>
> [1] Example spec files for this case seems to be something like:
>
> pie-compile.specs
> """
> *cc1_options:
> + %{!r:%{!fpie:%{!fPIE:%{!fpic:%{!fPIC:%{!fno-pic:-fPIE}}
> """
>
> pie-link.specs:
> """
> *self_spec:
> + %{!shared:%{!r:-pie}}
> """
>
> NB: I manually carved them out of a diff without testing them.
>