Hi,
the appended patch makes libcrypto.so compile without executable stack
requirements. it should be portable accross all versions of binutils (and
doesn't affect any non-linux platform anyway).
Diffed against 0.9.8a.
Dirk
--- crypto/perlasm/x86unix.pl
+++ crypto/perlasm/x86unix.pl
@@ -5
On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote:
> the appended patch makes libcrypto.so compile without executable stack
> requirements. it should be portable accross all versions of binutils (and
> doesn't affect any non-linux platform anyway).
it will break non-ELF builds though
On Nov 9 01:19, Mike Frysinger wrote:
> On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote:
> > the appended patch makes libcrypto.so compile without executable stack
> > requirements. it should be portable accross all versions of binutils (and
> > doesn't affect any non-linux platform
On Wednesday 09 November 2005 10:45, Corinna Vinschen wrote:
> It's also used for Cygwin and the patch breaks the Cygwin build.
I don't have a cygwin toolchain around, but can you tell me the error message
so that I can work on fixing it?
does the attached patch work?
Thanks,
Dirk
--- crypto/p
On Nov 9 13:57, Dirk Mueller wrote:
> On Wednesday 09 November 2005 10:45, Corinna Vinschen wrote:
> > It's also used for Cygwin and the patch breaks the Cygwin build.
>
> I don't have a cygwin toolchain around, but can you tell me the error message
> so that I can work on fixing it?
x86cpuid-c
On Wednesday 09 November 2005 14:30, Corinna Vinschen wrote:
> Btw., the first asm message indicates that a \n is missing. You should
> add this at the end of the section string to avoid the warning.
Ok, thanks for your help and the hint. I'd like to suggest the following patch
for inclusion in
On Wed, Nov 09, 2005 at 02:39:47PM +0100, Dirk Mueller wrote:
> Ok, thanks for your help and the hint. I'd like to suggest the following
> patch
> for inclusion into OpenSSL.
thanks, we've just been forcing -Wa,--noexecstack in Gentoo ... this is much
nicer :)
btw, does x86nasm.pl need to be f
On Wednesday 09 November 2005 15:15, Mike Frysinger wrote:
> btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to
> generate some source files which are included in the final lib, it'll force
> back in exec stack markings ...
It doesn't seem to be used here. can you confirm t
On Wed, Nov 09, 2005 at 03:21:20PM +0100, Dirk Mueller wrote:
> On Wednesday 09 November 2005 15:15, Mike Frysinger wrote:
>
> > btw, does x86nasm.pl need to be fixed too ? in theory, if it was used to
> > generate some source files which are included in the final lib, it'll force
> > back in exe
the appended patch makes libcrypto.so compile without executable stack
requirements. it should be portable accross all versions of binutils
x86unix.pl is called to generate output suitable not only for GNU
assembler [applies to ELF, COFF and a.out targets], but even for vendor
assemblers, for
On Wed, Nov 09, 2005 at 05:38:39PM +0100, Andy Polyakov wrote:
> >(and doesn't affect any non-linux platform anyway).
>
> How come it turns from unsure "should be portable" to definitive
> "doesn't affect" so easily:-)
it should be portable across all ELF targets ... after all, you're just addin
On Wednesday 09 November 2005 17:38, Andy Polyakov wrote:
> > (and doesn't affect any non-linux platform anyway).
> How come it turns from unsure "should be portable" to definitive
> "doesn't affect" so easily:-)
What I tried to say was that the extra section is ignored on platforms that do
not
On Wed, Nov 09, 2005 at 12:00:19AM +0100, Dirk Mueller wrote:
>
> Hi,
>
> the appended patch makes libcrypto.so compile without executable stack
> requirements. it should be portable accross all versions of binutils (and
> doesn't affect any non-linux platform anyway).
The problem is that bi
(and doesn't affect any non-linux platform anyway).
How come it turns from unsure "should be portable" to definitive
"doesn't affect" so easily:-)
Do mind smilies in my previous post:-)
What I tried to say was that the extra section is ignored on platforms that do
not use a recent binutils t
14 matches
Mail list logo