[gentoo-science] sci-libs/mpir for the main tree

[gentoo-science] sci-libs/mpir for the main tree

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 437 bytes --]

Hi,

my next migration victim will be mpir, the friendly clone of gmp.  The
current ebuild is the same in sage-on-gentoo and science.  It has this
assembler stuff in it that I don't understand.  Who did this? What is
the latest here, can we remove the fat TODO-banner (or DO it?).

Any other hints/objections?  (Yes, I know that there is a bump
waiting...)

Cheers,
Thomas

-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-science] sci-libs/mpir for the main tree

[François Bissey]

> Hi,
> 
> my next migration victim will be mpir, the friendly clone of gmp.  The
> current ebuild is the same in sage-on-gentoo and science.  It has this
> assembler stuff in it that I don't understand.  Who did this? What is
> the latest here, can we remove the fat TODO-banner (or DO it?).
> 
> Any other hints/objections?  (Yes, I know that there is a bump
> waiting...)
> 
Hi Thomas,

Christopher did it. mpir like gmp suffer from executable stacks.
There are talk on sage-devel which is very close to mpir upstream
to take a different approach: using an m4 macro and a linker flag
to remove them -Wl,-z,noexecstack. 
The motivation to fix this is fedora 14 which doesn't allow executable stacks 
by default.
I think the warning could be removed for now but the ebuild will probably
need a little TLC in the near future.

Francois

Re: [gentoo-science] sci-libs/mpir for the main tree

[Christopher Schwan]

Hi,

On Tuesday 09 November 2010 09:19:54 François Bissey wrote:
> > Hi,
> > 
> > my next migration victim will be mpir, the friendly clone of gmp.  The
> > current ebuild is the same in sage-on-gentoo and science.  It has this
> > assembler stuff in it that I don't understand.  Who did this? What is
> > the latest here, can we remove the fat TODO-banner (or DO it?).
> > 
> > Any other hints/objections?  (Yes, I know that there is a bump
> > waiting...)
> 
> Hi Thomas,
> 
> Christopher did it. mpir like gmp suffer from executable stacks.

I followed the instructions listed in number 6 of the following page: 
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml . However, the fix is 
incomplete (some architectures still have executable stacks) and I had some 
problems with BASH:

for i in $(find . -type f -name '*.asm') ; do
	echo $i >/dev/null
	cat >> $i <<-EOF
		#if defined(__linux__) && defined(__ELF__)
		.section .note.GNU-stack,"",%progbits
		#endif
	EOF
done

If I remove the line with "echo" (which *should* be completely useless), the 
cat command does not patch files - WHY ?! Also, mpir seemed to have dropped 
yasm beginning with mpir-2.1 (?), so I think at least one loop in mpir's 
ebuild is superfluous.

> There are talk on sage-devel which is very close to mpir upstream
> to take a different approach: using an m4 macro and a linker flag
> to remove them -Wl,-z,noexecstack.

This seems to be a better idea.

> The motivation to fix this is fedora 14 which doesn't allow executable
> stacks by default.
> I think the warning could be removed for now but the ebuild will probably
> need a little TLC in the near future.
> 
> Francois

Christopher

Re: [gentoo-science] sci-libs/mpir for the main tree

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1289 bytes --]

Hi,

On 09:41 Wed 10 Nov     , Christopher Schwan wrote:
> I followed the instructions listed in number 6 of the following page: 
> http://www.gentoo.org/proj/en/hardened/gnu-stack.xml . However, the fix is 
> incomplete (some architectures still have executable stacks) and I had some 
> problems with BASH:
> 
> for i in $(find . -type f -name '*.asm') ; do
> 	echo $i >/dev/null
> 	cat >> $i <<-EOF
> 		#if defined(__linux__) && defined(__ELF__)
> 		.section .note.GNU-stack,"",%progbits
> 		#endif
> 	EOF
> done
> 
> If I remove the line with "echo" (which *should* be completely useless), the 
> cat command does not patch files - WHY ?! Also, mpir seemed to have dropped 
> yasm beginning with mpir-2.1 (?), so I think at least one loop in mpir's 
> ebuild is superfluous.

I will look into this.  What is the state for ppc and prefix ?  In
short: What keywords should we have on mpir?  I can only test ~amd64 and
~x86.

> > There are talk on sage-devel which is very close to mpir upstream
> > to take a different approach: using an m4 macro and a linker flag
> > to remove them -Wl,-z,noexecstack.
> 
> This seems to be a better idea.

Will that be available anytime soon?

Cheers,
Thomas



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-science] sci-libs/mpir for the main tree

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 893 bytes --]

On 09:41 Wed 10 Nov     , Christopher Schwan wrote:
> for i in $(find . -type f -name '*.asm') ; do
> 	echo $i >/dev/null
> 	cat >> $i <<-EOF
> 		#if defined(__linux__) && defined(__ELF__)
> 		.section .note.GNU-stack,"",%progbits
> 		#endif
> 	EOF
> done
> 
> If I remove the line with "echo" (which *should* be completely useless), the 
> cat command does not patch files - WHY ?!

Can't reproduce what you are saying.  Here it works like a charm without
the superflous line.

> Also, mpir seemed to have dropped yasm beginning with mpir-2.1 (?), so
> I think at least one loop in mpir's ebuild is superfluous.

Hmm, also no. mpir-2.1.3 tarball contains yasm... I'm confused.

My current version is always here:

https://github.com/tom111/TomOverlay/blob/master/sci-libs/mpir/mpir-2.1.3.ebuild

Cheers,
Thomas


-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-science] sci-libs/mpir for the main tree

[François Bissey]

> Hi,
> 
> On 09:41 Wed 10 Nov     , Christopher Schwan wrote:
> > I followed the instructions listed in number 6 of the following page:
> > http://www.gentoo.org/proj/en/hardened/gnu-stack.xml . However, the fix
> > is incomplete (some architectures still have executable stacks) and I
> > had some problems with BASH:
> > 
> > for i in $(find . -type f -name '*.asm') ; do
> > 
> > 	echo $i >/dev/null
> > 	cat >> $i <<-EOF
> > 	
> > 		#if defined(__linux__) && defined(__ELF__)
> > 		.section .note.GNU-stack,"",%progbits
> > 		#endif
> > 	
> > 	EOF
> > 
> > done
> > 
> > If I remove the line with "echo" (which *should* be completely useless),
> > the cat command does not patch files - WHY ?! Also, mpir seemed to have
> > dropped yasm beginning with mpir-2.1 (?), so I think at least one loop
> > in mpir's ebuild is superfluous.
> 
> I will look into this.  What is the state for ppc and prefix ?  In
> short: What keywords should we have on mpir?  I can only test ~amd64 and
> ~x86.
> 
Does work on ppc, I have emerged it regularly on my test machine.
We have stopped caring about using mpir in sage for now, so I don't think
Christopher tested it on prefix.
As for the echo stuff we had a chat with xarty the other day and they don't 
seem to be necessary anymore. We suspect it was a bash (old version) problem.

As for your question for the executable stack flag, we don't really know, but 
sage basically added it to LDFLAGS and we could try to do the same thing.

Francois

Re: [gentoo-science] sci-libs/mpir for the main tree

[François Bissey]

Also, I put a cpudetection useflag for amd64 and x86. This produce generic
code for these cpu. As it says in the ebuild that works only for those archs.
So if you want to add ppc either drop the useflag or mask on ppc.
I put clues on how to do the later in the ebuild.

Francois

Re: [gentoo-science] sci-libs/mpir for the main tree

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1103 bytes --]

Hi,

On 21:19 Tue 09 Nov     , François Bissey wrote:
> > my next migration victim will be mpir, the friendly clone of gmp.  The
> > current ebuild is the same in sage-on-gentoo and science.  It has this
> > assembler stuff in it that I don't understand.  Who did this? What is
> > the latest here, can we remove the fat TODO-banner (or DO it?).
> > 
> > Any other hints/objections?  (Yes, I know that there is a bump
> > waiting...)
> > 
> Hi Thomas,
> 
> Christopher did it. mpir like gmp suffer from executable stacks.
> There are talk on sage-devel which is very close to mpir upstream
> to take a different approach: using an m4 macro and a linker flag
> to remove them -Wl,-z,noexecstack. 
> The motivation to fix this is fedora 14 which doesn't allow executable stacks 
> by default.

The changelog of mpir-2.2 shows:

-) Enable noexecstack for x86/x86_64 with GCC

So what should be done to use this in our ebuild.  I tried to simply
append -Wl,-z,noexecstack to ldflags, but this did nothing.

Cheers,
Thomas



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-science] sci-libs/mpir for the main tree

[Christopher Schwan]

Hi,

On Friday 17 December 2010 14:00:16 Thomas Kahle wrote:
> Hi,
> 
> On 21:19 Tue 09 Nov     , François Bissey wrote:
> > > my next migration victim will be mpir, the friendly clone of gmp.  The
> > > current ebuild is the same in sage-on-gentoo and science.  It has this
> > > assembler stuff in it that I don't understand.  Who did this? What is
> > > the latest here, can we remove the fat TODO-banner (or DO it?).
> > > 
> > > Any other hints/objections?  (Yes, I know that there is a bump
> > > waiting...)
> > 
> > Hi Thomas,
> > 
> > Christopher did it. mpir like gmp suffer from executable stacks.
> > There are talk on sage-devel which is very close to mpir upstream
> > to take a different approach: using an m4 macro and a linker flag
> > to remove them -Wl,-z,noexecstack.
> > The motivation to fix this is fedora 14 which doesn't allow executable
> > stacks by default.
> 
> The changelog of mpir-2.2 shows:
> 
> -) Enable noexecstack for x86/x86_64 with GCC
> 
> So what should be done to use this in our ebuild.  I tried to simply
> append -Wl,-z,noexecstack to ldflags, but this did nothing.

Mpir's configure scripts looks like its adding "-Wl,-z,noexecstack" if it 
detects a gcc+x86/amd64 configuration - so I guess noexecstack should work out 
of the box. If it does not I would consider this as broken.

> 
> Cheers,
> Thomas

Cheers,

Christopher

Re: [gentoo-science] sci-libs/mpir for the main tree

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 794 bytes --]

On 14:22 Fri 17 Dec     , Christopher Schwan wrote:
> Mpir's configure scripts looks like its adding "-Wl,-z,noexecstack" if it 
> detects a gcc+x86/amd64 configuration - so I guess noexecstack should work out 
> of the box. If it does not I would consider this as broken.

Yes, I saw that. The configure method fails directly, it just does *not*
add the ldflag (at least when configure is run by portage).

I also tried to add "-Wl,-z,noexecstack" via append-ldflags, and it is
indeed appended as visible in the compile output, but the exec stacks
are still there and the QA warning comes up, so I guess we can consider
this broken and stick with your solution of patching the asm (which sill
works fine)

Cheers,
Thomas



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-science] sci-libs/mpir for the main tree

[Christopher Schwan]

On Friday 17 December 2010 14:55:03 Thomas Kahle wrote:
> On 14:22 Fri 17 Dec     , Christopher Schwan wrote:
> > Mpir's configure scripts looks like its adding "-Wl,-z,noexecstack" if it
> > detects a gcc+x86/amd64 configuration - so I guess noexecstack should
> > work out of the box. If it does not I would consider this as broken.
> 
> Yes, I saw that. The configure method fails directly, it just does *not*
> add the ldflag (at least when configure is run by portage).
> 
> I also tried to add "-Wl,-z,noexecstack" via append-ldflags, and it is
> indeed appended as visible in the compile output, but the exec stacks
> are still there and the QA warning comes up, so I guess we can consider
> this broken and stick with your solution of patching the asm (which sill
> works fine)

Did you read http://www.gentoo.org/proj/en/hardened/gnu-stack.xml ? The 
document proposes a slightly different approach for assembler files:

    append-flags -Wa,--noexecstack

Which tells the assembler to use --nostack (instead of telling the linker to 
use -z,noexecstack).

> 
> Cheers,
> Thomas

Cheers,
Christopher

Re: [gentoo-science] sci-libs/mpir for the main tree

[Thomas Kahle]

[-- Attachment #1: Type: text/plain, Size: 1367 bytes --]

On 15:16 Fri 17 Dec     , Christopher Schwan wrote:
> On Friday 17 December 2010 14:55:03 Thomas Kahle wrote:
> > On 14:22 Fri 17 Dec     , Christopher Schwan wrote:
> > > Mpir's configure scripts looks like its adding "-Wl,-z,noexecstack" if it
> > > detects a gcc+x86/amd64 configuration - so I guess noexecstack should
> > > work out of the box. If it does not I would consider this as broken.
> > 
> > Yes, I saw that. The configure method fails directly, it just does *not*
> > add the ldflag (at least when configure is run by portage).
> > 
> > I also tried to add "-Wl,-z,noexecstack" via append-ldflags, and it is
> > indeed appended as visible in the compile output, but the exec stacks
> > are still there and the QA warning comes up, so I guess we can consider
> > this broken and stick with your solution of patching the asm (which sill
> > works fine)
> 
> Did you read http://www.gentoo.org/proj/en/hardened/gnu-stack.xml ? The 
> document proposes a slightly different approach for assembler files:
> 
>     append-flags -Wa,--noexecstack

Read it again now.  Indeed, "-Wa,--noexecstack" also works, but the page
says that patching is the preferred approach... well at least if the
patches land upstream at some point. I guess it just does not matter.

Cheers,
Thomas



-- 
Thomas Kahle
http://dev.gentoo.org/~tomka/

[-- Attachment #2: Type: application/pgp-signature, Size: 316 bytes --]