Hello,
I opened two pull request regarding fixes for builds using GCC:
* Fix versioned GCC detection
https://github.com/openssl/openssl/pull/552
* Support link time optimization with GCC
https://github.com/openssl/openssl/pull/553
Cheers
signature.asc
Description: PGP signature
_
On Jan 17 18:33, Richard Levitte wrote:
> In message <20160117172014.gc16...@calimero.vinschen.de> on Sun, 17 Jan 2016
> 18:20:14 +0100, Corinna Vinschen said:
>
> vinschen> On Jan 17 18:13, Corinna Vinschen wrote:
> vinschen> > On Jan 17 17:50, Richard Levitte wrote:
> vinschen> > > In message
In message on Sun, 17 Jan 2016 10:39:31 -0800,
"Erik Forsberg" said:
erik> Just wanted to mention that I like the new configuration style
erik> a lot better than the old, much easier to automate a custom build now.
erik>
erik> Thanks.
Heh, you're welcome. Let me tell you, making that move wa
Just wanted to mention that I like the new configuration style
a lot better than the old, much easier to automate a custom build now.
Thanks.
>-- Original Message --
>
>Hi,
>
>I think I've seen this question asked a few times, an it's time for an
>explanation.
>
>In upcoming OpenSSL 1.1.0, the ol
In message <20160117172321.gd16...@calimero.vinschen.de> on Sun, 17 Jan 2016
18:23:21 +0100, Corinna Vinschen said:
vinschen> Just to be clear, this does not help unless the -s option is dropped
vinschen> from the linker command line. This part of my patch (or something
along
vinschen> the lin
In message <20160117171738.gb16...@calimero.vinschen.de> on Sun, 17 Jan 2016
18:17:38 +0100, Corinna Vinschen said:
vinschen> On Jan 17 17:30, Richard Levitte wrote:
vinschen> > In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17
Jan 2016 16:32:35 +0100, Corinna Vinschen said:
v
In message <20160117172014.gc16...@calimero.vinschen.de> on Sun, 17 Jan 2016
18:20:14 +0100, Corinna Vinschen said:
vinschen> On Jan 17 18:13, Corinna Vinschen wrote:
vinschen> > On Jan 17 17:50, Richard Levitte wrote:
vinschen> > > In message <20160117154353.gc9...@calimero.vinschen.de> on Sun,
In message <20160117171350.ga16...@calimero.vinschen.de> on Sun, 17 Jan 2016
18:13:50 +0100, Corinna Vinschen said:
vinschen> On Jan 17 17:50, Richard Levitte wrote:
vinschen> > In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 17
Jan 2016 16:43:53 +0100, Corinna Vinschen said:
v
On Jan 17 18:17, Corinna Vinschen wrote:
> On Jan 17 17:30, Richard Levitte wrote:
> > In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17 Jan 2016
> > 16:32:35 +0100, Corinna Vinschen said:
> > [...]
> > vinschen> This is pretty non-standard. By not allowing to extend CFLAGS
> >
On Jan 17 18:13, Corinna Vinschen wrote:
> On Jan 17 17:50, Richard Levitte wrote:
> > In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 17 Jan 2016
> > 16:43:53 +0100, Corinna Vinschen said:
> >
> > vinschen> On Jan 17 01:04, Richard Levitte wrote:
> > vinschen> > If you have a lo
On Jan 17 17:30, Richard Levitte wrote:
> In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17 Jan 2016
> 16:32:35 +0100, Corinna Vinschen said:
> [...]
> vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from
> the
> vinschen> environment, you require all di
On Jan 17 17:50, Richard Levitte wrote:
> In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 17 Jan 2016
> 16:43:53 +0100, Corinna Vinschen said:
>
> vinschen> On Jan 17 01:04, Richard Levitte wrote:
> vinschen> > If you have a look in "config", it doesn't generate
> "Cygwin-x86_64
In message <20160117154353.gc9...@calimero.vinschen.de> on Sun, 17 Jan 2016
16:43:53 +0100, Corinna Vinschen said:
vinschen> On Jan 17 01:04, Richard Levitte wrote:
vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64"
at
vinschen> > all. Would you be willing to have
In message <20160117153235.gb9...@calimero.vinschen.de> on Sun, 17 Jan 2016
16:32:35 +0100, Corinna Vinschen said:
vinschen> On Jan 17 14:56, Richard Levitte wrote:
vinschen> > In message <20160117131603.ga10...@roeckx.be> on Sun, 17 Jan 2016
14:16:04 +0100, Kurt Roeckx said:
vinschen> >
vins
On Jan 17 01:04, Richard Levitte wrote:
> In message <20160116164653.gh12...@calimero.vinschen.de> on Sat, 16 Jan 2016
> 17:46:53 +0100, Corinna Vinschen said:
>
> vinschen> > ./config --unified
> vinschen>
> vinschen> I tried that and it doesn't work correctly for Cygwin on x86_64.
> vinsc
done in commit 9e5cd4bac777e27ebcdc9aa411f0a63c27500468 thanks.
--
Rich Salz, OpenSSL dev team; rs...@openssl.org
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
On Jan 17 14:56, Richard Levitte wrote:
> In message <20160117131603.ga10...@roeckx.be> on Sun, 17 Jan 2016 14:16:04
> +0100, Kurt Roeckx said:
>
> kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote:
> kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest
Hi Richard,
On Jan 17 01:14, Richard Levitte wrote:
> In message <20160116183724.gi12...@calimero.vinschen.de> on Sat, 16 Jan 2016
> 19:37:24 +0100, Corinna Vinschen said:
>
> vinschen> Who had this funny idea to use the Windows definitions when
> building for
> vinschen> Cygwin?
>
> I'm afra
> What about to remove declaration of FIPS_mode and FIPS_mode_set?
> Those functions could be used by external packages at configure time to
> detect that fips is not supported at all.
> Note 1.0.0 does not declare both functions.
For various reasons, the team wants them there.
> What about to remove declaration of FIPS_mode and FIPS_mode_set?
> Those functions could be used by external packages at configure time to
> detect that fips is not supported at all.
> Note 1.0.0 does not declare both functions.
For various reasons, the team wants them there.
__
> Please note that the patch in RT4247 also contains a hunk for
> crypto/evp/e_camellia.c. This was not committed here, but without it one
> gets the same type of compilation error on SPARC. Since the RT is already
> closed I thought I better ask.
Thanks for catching this. Fixed now.
___
In message <20160117131603.ga10...@roeckx.be> on Sun, 17 Jan 2016 14:16:04
+0100, Kurt Roeckx said:
kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote:
kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest you
kurt> > have a look at Configurations/10-main.
Hey all,
`crypto/o_dir_test.c` was not using the correct path to `e_os2.h`.
Link to pull request: https://github.com/openssl/openssl/pull/561
- Bhee
>From 724a68e977fdc912033a505a59239c83e294651c Mon Sep 17 00:00:00 2001
From: Bheesham Persaud
Date: Sun, 17 Jan 2016 02:37:15 -0500
Subject:
On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote:
> OPT_FLAGS would be for optimizing, do I get that right? I suggest you
> have a look at Configurations/10-main.conf, you might notice
> configuration items like debug_cflags, release_cflags, debug_lflags
> and release_lflags. If yo
Rich Salz via RT wrote:
> we did everything we want to do, closing this.
What about to remove declaration of FIPS_mode and FIPS_mode_set?
Those functions could be used by external packages at configure time to
detect that fips is not supported at all.
Note 1.0.0 does not declare both functions.
R
Hi,
I think I've seen this question asked a few times, an it's time for an
explanation.
In upcoming OpenSSL 1.1.0, the old configuration strings supposed to
be gone, completely and entirely. There are some traces left from the
time when we still had some of them and were converting them to the
n
> And did you have problems with the x86 compiler too? Did you try the x64
version also?
No, I didn't try the x64 version.
___
openssl-dev mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Hi Marc,
is this still current? I've checked in as many ways as I can right now and I
cannot make the build fail. Those functions look properly marked as deprecated,
or in some cases, not existing at all. Since you didn't tell us the age of your
source (was it 1.1.0 pre 1? 1.1.0 pre 2? Fresh pull
Michel wrote:
> FWIW I encountered the same problem last week with the statem_srvr.c.
> I undestood that it was a compiler bug, but suspected there was an
> underlying problem with the source code, as usually it is error in MY code
> that make the compiler crashes...
Nice to seem I'm not alone wi
29 matches
Mail list logo
