[openssl-dev] [openssl.org #4253] [PATCH] Build system fixes for GCC
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 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
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 <20160117154353.gc9...@calimero.vinschen.de> on Sun, > 17 Jan 2016 16:43:53 +0100, Corinna Vinschen said: > vinschen> > > > vinschen> > > vinschen> On Jan 17 01:04, Richard Levitte wrote: > vinschen> > > vinschen> > If you have a look in "config", it doesn't generate > "Cygwin-x86_64" at > vinschen> > > vinschen> > all. Would you be willing to have a look at that > script and modernise > vinschen> > > vinschen> > it regarding Cygwin? > vinschen> > > vinschen> > vinschen> > > vinschen> Like the attached? > vinschen> > > > vinschen> > > Thank you, that helped... it was less traumatic than I > imagined ;-) > vinschen> > > I've attached a small fixup, your thoughts? > vinschen> > > vinschen> > Well, that works, too. But if we ever support another > architecture, > vinschen> > we'd have to tweak two files, config and 10-main.conf, rather > then just > vinschen> > one, 10-main.conf. > vinschen> > vinschen> Btw., when calling Configure rather than config, i686 would be > simpler > vinschen> for the package builder since it could just use the build variable > vinschen> ${ARCH}, rather than having to check and explicitely turn this to > "x86". > vinschen> > vinschen> > vinschen> Just saying... > > I was just thinking of that, as well as a backward compatibility name > Cygwin. Looks good to me, as discussed in PM. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Personal configuration in 1.1.0
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 was quite a self gratifying move, exactly for the reason you state! :-) Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Personal configuration in 1.1.0
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 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 >new style configurations found in Configurations/, but those bits >haven't been tried for some time. As a matter of fact, those last >traces are completely removed in my my refactor-build branch. > >If you want to keep some personal configurations around, I'd suggest >having a look at the personal ones some of us in the team are keeping >around in Configurations/, and build your own using them as a model on >how to do so. > >Unfortunately, the documentation isn't there yet, at least in master. >(have a look at my refactor-build branch, it has a Configurations/README >which I hope does a fair enough job... if there are enhancements >needed, feedback is welcome!) > >The older configuration strings still work as usual in the 1.0.x >releases. That won't change, of course. > >Cheers, >Richard > >-- >Richard Levitte levi...@openssl.org >OpenSSL Project http://www.openssl.org/~levitte/ >___ >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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 lines) is still necessary, otherwise building the debuginfo files vinschen> fails. No worries, those previous patches are on my todo list Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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: vinschen> > [...] vinschen> > vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from the vinschen> > vinschen> environment, you require all distros to patch the OpenSSL package to fit vinschen> > vinschen> their needs in terms of the build flags. vinschen> > vinschen> > Actually, I forgot another possibility, to just pass them on the vinschen> > Configure / config command line, like so: vinschen> > vinschen> > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ vinschen> > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ vinschen> > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 vinschen> > vinschen> > Basically, anything start with a dash or plus that Configure doesn't vinschen> > recognise as its own, it will pass down: vinschen> > vinschen> > * if it starts with -l. -L or -Wl, into EX_LIBS, which is vinschen> > essentially flags to the linker. vinschen> > * otherwise, into CFLAG / CFLAGS. vinschen> > vinschen> > Can't believe I forgot to mention that, considering I use it all the vinschen> > time... vinschen> vinschen> This works. I can't believe this worked so simple all the time. Is vinschen> that documented somewhere? If not, it certainly should. Badly, I have to admit. Looks like this in the big wall of commenting at the beginning of Configure: # - + compiler options are passed through vinschen> > If my info about the Configure command line above wasn't good enough, vinschen> > I do have a fairly simple idea on how to allow for using environment vinschen> > variables to expand the diverse flag items, more or less directly into vinschen> > the target structure. vinschen> vinschen> I guess it's your choice then. The above seems to work vinschen> nicely for us, so there's no pressure. Well, the path of least resistance and all that ;-) Seriously, it'll stay on my mind, but unless someone screams bloody murder, it's not gonna be on my top ten priority list. I'm sure you understand. Of course, if someone else in the team feels compelled, by all means! vinschen> It would be good to know if that helps for Debian as well, vinschen> of course. Yup, agreed. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
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, 17 Jan 2016 16:43:53 +0100, Corinna Vinschen said: vinschen> > > vinschen> > > vinschen> On Jan 17 01:04, Richard Levitte wrote: vinschen> > > vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at vinschen> > > vinschen> > all. Would you be willing to have a look at that script and modernise vinschen> > > vinschen> > it regarding Cygwin? vinschen> > > vinschen> vinschen> > > vinschen> Like the attached? vinschen> > > vinschen> > > Thank you, that helped... it was less traumatic than I imagined ;-) vinschen> > > I've attached a small fixup, your thoughts? vinschen> > vinschen> > Well, that works, too. But if we ever support another architecture, vinschen> > we'd have to tweak two files, config and 10-main.conf, rather then just vinschen> > one, 10-main.conf. vinschen> vinschen> Btw., when calling Configure rather than config, i686 would be simpler vinschen> for the package builder since it could just use the build variable vinschen> ${ARCH}, rather than having to check and explicitely turn this to "x86". vinschen> vinschen> vinschen> Just saying... I was just thinking of that, as well as a backward compatibility name Cygwin. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ >From 264c39920dd8b37345837adec251334db766ac4e Mon Sep 17 00:00:00 2001 From: Richard Levitte Date: Sun, 17 Jan 2016 18:03:04 +0100 Subject: [PATCH 2/2] Add some extra Cygwin targets as aliases for Cygwin-x86 Cygwin was used for x86 before, so let's keep it around for those who still use it (it make Configure reconf possible). Cygwin-i[3456]86 for those that might generate and pass a target name directly to Configure. --- Configurations/10-main.conf | 17 + 1 file changed, 17 insertions(+) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index 479bc58..06911ac 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1251,6 +1251,23 @@ shared_ldflag=> "-shared", shared_extension => ".dll.a", }, +# Backward compatibility for those using this target +"Cygwin" => { + inherit_from => [ "Cygwin-x86" ] +}, +# In case someone constructs the Cygwin target name themself +"Cygwin-i386" => { + inherit_from => [ "Cygwin-x86" ] +}, +"Cygwin-i486" => { + inherit_from => [ "Cygwin-x86" ] +}, +"Cygwin-i586" => { + inherit_from => [ "Cygwin-x86" ] +}, +"Cygwin-i686" => { + inherit_from => [ "Cygwin-x86" ] +}, NetWare from David Ward (dsw...@novell.com) # requires either MetroWerks NLM development tools, or gcc / nlmconv -- 2.7.0.rc3 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
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: vinschen> > vinschen> > vinschen> On Jan 17 01:04, Richard Levitte wrote: vinschen> > vinschen> > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at vinschen> > vinschen> > all. Would you be willing to have a look at that script and modernise vinschen> > vinschen> > it regarding Cygwin? vinschen> > vinschen> vinschen> > vinschen> Like the attached? vinschen> > vinschen> > Thank you, that helped... it was less traumatic than I imagined ;-) vinschen> > I've attached a small fixup, your thoughts? vinschen> vinschen> Well, that works, too. But if we ever support another architecture, vinschen> we'd have to tweak two files, config and 10-main.conf, rather then just vinschen> one, 10-main.conf. I can live with that. Or, well, that's actually just a slightly different fixup away. -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ >From 2ec18167fdaeb03f45a2f3b726aa6f7fdcf31178 Mon Sep 17 00:00:00 2001 From: Richard Levitte Date: Sun, 17 Jan 2016 17:48:53 +0100 Subject: [PATCH 1/2] FIXUP to adjust names and include i[345]86 --- Configurations/10-main.conf | 2 +- config | 2 ++ 2 files changed, 3 insertions(+), 1 deletion(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index b1528c1..479bc58 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1221,7 +1221,7 @@ }, Cygwin -"Cygwin-i686" => { +"Cygwin-x86" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", cflags => "-DTERMIOS -DL_ENDIAN -Wall", diff --git a/config b/config index 6f8ee91..000b7f0 100755 --- a/config +++ b/config @@ -806,6 +806,8 @@ case "$GUESSOS" in fi ;; # these are all covered by the catchall below + x86_64-pc-cygwin) OUT="Cygwin-x86_64" ;; + i[3456]86-*-cygwin) OUT="Cygwin-x86" ;; *-*-cygwin) OUT="Cygwin-${MACHINE}" ;; x86pc-*-qnx6) OUT="QNX6-i386" ;; *-*-qnx6) OUT="QNX6" ;; -- 2.7.0.rc3 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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 > > from the > > vinschen> environment, you require all distros to patch the OpenSSL package > > to fit > > vinschen> their needs in terms of the build flags. > > > > Actually, I forgot another possibility, to just pass them on the > > Configure / config command line, like so: > > > > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ > > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ > > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 > > > > Basically, anything start with a dash or plus that Configure doesn't > > recognise as its own, it will pass down: > > > > * if it starts with -l. -L or -Wl, into EX_LIBS, which is > > essentially flags to the linker. > > * otherwise, into CFLAG / CFLAGS. > > > > Can't believe I forgot to mention that, considering I use it all the > > time... > > This works. I can't believe this worked so simple all the time. > [...] Just to be clear, this does not help unless the -s option is dropped from the linker command line. This part of my patch (or something along the lines) is still necessary, otherwise building the debuginfo files fails. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
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 look in "config", it doesn't generate > > "Cygwin-x86_64" at > > vinschen> > all. Would you be willing to have a look at that script and > > modernise > > vinschen> > it regarding Cygwin? > > vinschen> > > vinschen> Like the attached? > > > > Thank you, that helped... it was less traumatic than I imagined ;-) > > I've attached a small fixup, your thoughts? > > Well, that works, too. But if we ever support another architecture, > we'd have to tweak two files, config and 10-main.conf, rather then just > one, 10-main.conf. Btw., when calling Configure rather than config, i686 would be simpler for the package builder since it could just use the build variable ${ARCH}, rather than having to check and explicitely turn this to "x86". Just saying... Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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 distros to patch the OpenSSL package > to fit > vinschen> their needs in terms of the build flags. > > Actually, I forgot another possibility, to just pass them on the > Configure / config command line, like so: > > ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ > -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ > -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 > > Basically, anything start with a dash or plus that Configure doesn't > recognise as its own, it will pass down: > > * if it starts with -l. -L or -Wl, into EX_LIBS, which is > essentially flags to the linker. > * otherwise, into CFLAG / CFLAGS. > > Can't believe I forgot to mention that, considering I use it all the > time... This works. I can't believe this worked so simple all the time. Is that documented somewhere? If not, it certainly should. > vinschen> CFLAGS+=$(OPENSSL_CFLAGS) > > += is a GNU make extension, and therefore a no can do. We need to > stay with generic make. I expected that but had to point it out ;) > vinschen> OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB > -DOPENSSL_THREADS[...etc...] > vinschen> CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" > vinschen> > vinschen> and the package build system has to set $BUILD_CFLAGS. That would > vinschen> be sufficient as well. > > If my info about the Configure command line above wasn't good enough, > I do have a fairly simple idea on how to allow for using environment > variables to expand the diverse flag items, more or less directly into > the target structure. I guess it's your choice then. The above seems to work nicely for us, so there's no pressure. It would be good to know if that helps for Debian as well, of course. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
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" at > vinschen> > all. Would you be willing to have a look at that script and > modernise > vinschen> > it regarding Cygwin? > vinschen> > vinschen> Like the attached? > > Thank you, that helped... it was less traumatic than I imagined ;-) > I've attached a small fixup, your thoughts? Well, that works, too. But if we ever support another architecture, we'd have to tweak two files, config and 10-main.conf, rather then just one, 10-main.conf. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] Upcoming build system change
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 a look at that script and modernise vinschen> > it regarding Cygwin? vinschen> vinschen> Like the attached? Thank you, that helped... it was less traumatic than I imagined ;-) I've attached a small fixup, your thoughts? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ >From 3551960614f451350b791182f423284a2be6f389 Mon Sep 17 00:00:00 2001 From: Richard Levitte Date: Sun, 17 Jan 2016 17:48:53 +0100 Subject: [PATCH] FIXUP to adjust names and include i[345]86 --- Configurations/10-main.conf | 2 +- config | 3 ++- 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index b1528c1..479bc58 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1221,7 +1221,7 @@ }, Cygwin -"Cygwin-i686" => { +"Cygwin-x86" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", cflags => "-DTERMIOS -DL_ENDIAN -Wall", diff --git a/config b/config index 6f8ee91..f962dce 100755 --- a/config +++ b/config @@ -806,7 +806,8 @@ case "$GUESSOS" in fi ;; # these are all covered by the catchall below - *-*-cygwin) OUT="Cygwin-${MACHINE}" ;; + x86_64-pc-cygwin) OUT="Cygwin-x86_64" ;; + *-*-cygwin) OUT="Cygwin-x86" ;; x86pc-*-qnx6) OUT="QNX6-i386" ;; *-*-qnx6) OUT="QNX6" ;; x86-*-android|i?86-*-android) OUT="android-x86" ;; -- 2.7.0.rc3 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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> > vinschen> > kurt> On Sun, Jan 17, 2016 at 01:14:14AM +0100, Richard Levitte wrote: vinschen> > kurt> > OPT_FLAGS would be for optimizing, do I get that right? I suggest you vinschen> > kurt> > have a look at Configurations/10-main.conf, you might notice vinschen> > kurt> > configuration items like debug_cflags, release_cflags, debug_lflags vinschen> > kurt> > and release_lflags. If you have a look at my refactor-build branch, vinschen> > kurt> > you will see a fairly thorough Configurations/README. If you look the vinschen> > kurt> > commit titled "Refactor config - move templates docs asm templates to vinschen> > kurt> > Configurations", you'll find the documentation that's applicable to vinschen> > kurt> > what Configure in the master branch supports... later editions are vinschen> > kurt> > currently only supported in my branch. vinschen> > kurt> vinschen> > kurt> In Debian we have a system that where you can override things like vinschen> > kurt> the CFLAGS, and I wonder how easy it will be to integrate that vinschen> > kurt> with your new system. vinschen> > kurt> [...] vinschen> > kurt> Is there an easy way to I can override the flags with vinschen> > kurt> dpkg-buildflags? vinschen> > vinschen> > I see where you're going with this. vinschen> > vinschen> > As it is right now, there is no way to affect Configure via the vinschen> > environment, except for the names of certain commands. Personally, vinschen> > I'd say that using those should be done carefully. I have no plans to vinschen> > expand on the use of environment variables... vinschen> > vinschen> > However, there is always the possibility to quickly write up a small vinschen> > config target for yourself in Configurations, and have them inherit vinschen> > the items for an already existing target. For example: vinschen> > vinschen> > cflags=` ... dpkg-buildflags --get CFLAGS`; \ vinschen> > cat < Configurations/01-debian-tmp.conf vinschen> > %targets = ( vinschen> > "debian-linux-x86_64" => { vinschen> > inherit_from => [ "linux-x86_64" ], vinschen> > cflags => "$cflags", vinschen> > } vinschen> > ); vinschen> > 1; vinschen> > EOF vinschen> > vinschen> > If you want to just append or prepend your flags, you do this with the vinschen> > cflags item: vinschen> > vinschen> > cflags => sub { join(" ", $@, "$cflags"); }, vinschen> > vinschen> > In my refactor-build branch, I've added some lazy functions to do the vinschen> > same: vinschen> > vinschen> > cflags => add("$cflags"), vinschen> > vinschen> > or vinschen> > vinschen> > cflags => add_before("$cflags"), # to prepend vinschen> > vinschen> > Did that help? vinschen> vinschen> This is pretty non-standard. By not allowing to extend CFLAGS from the vinschen> environment, you require all distros to patch the OpenSSL package to fit vinschen> their needs in terms of the build flags. Actually, I forgot another possibility, to just pass them on the Configure / config command line, like so: ./config -ggdb -O2 -pipe -Wimplicit-function-declaration \ -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 Basically, anything start with a dash or plus that Configure doesn't recognise as its own, it will pass down: * if it starts with -l. -L or -Wl, into EX_LIBS, which is essentially flags to the linker. * otherwise, into CFLAG / CFLAGS. Can't believe I forgot to mention that, considering I use it all the time... vinschen> Why is that necessary? It's no problem at all with autotool vinschen> or cmake-based configurations, and it's really *needed* by vinschen> distros. Before we all go off on a tangent, I'd like to point out that I'm only stating how it works as it is right now. We're not strangers to making changes, even though carefully most of the times ;-) vinschen> CFLAGS+=$(OPENSSL_CFLAGS) += is a GNU make extension, and therefore a no can do. We need to stay with generic make. vinschen> OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] vinschen> CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" vinschen> vinschen> and the package build system has to set $BUILD_CFLAGS. That would vinschen> be sufficient as well. If my info about the Configure command line above wasn't good enough, I do have a fairly simple idea on how to allow for using environment variables to expand the diverse flag items, more or less directly into the target structure. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project
Re: [openssl-dev] Upcoming build system change
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. > vinschen> Rather than choosing the "Cygwin-x86_64" configuration, it chooses > vinschen> the "Cygwin" configuration which is for the i686 based 32 bit > vinschen> version of Cygwin. > vinschen> > vinschen> Can this be recified easily. > vinschen> > vinschen> Btw., for the new unified configuration it might make sense to > vinschen> rename "Cygwin" to "Cygwin-i686". -march could then be set for > vinschen> i686 as well since 32 bit Cygwin won't run on older CPUs anyway. > > Hey Corinna, > > This particular issue has nothing at all to do with with my build > system changes, and everything to do with the "config" script. Its > responsability is to figure out what the platform target should be and > then call Configure with it. > > If you have a look in "config", it doesn't generate "Cygwin-x86_64" at > all. Would you be willing to have a look at that script and modernise > it regarding Cygwin? Like the attached? Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat From d8b509832d9e8cab2cb8e8fd3cf4d34ada792818 Mon Sep 17 00:00:00 2001 From: Corinna Vinschen Date: Sun, 17 Jan 2016 16:42:38 +0100 Subject: [PATCH] Fix configuration system to support different architectures on Cygwin. This patch allows to recognize the architectures supported by Cygwin and to choose the right configuration from there. Drop -march to use default architecture on 32 bit x86. Drop pre-Cygwin-1.3 recognition since it's long gone and there's no valid configuration for this anymore. Signed-off-by: Corinna Vinschen --- Configurations/10-main.conf | 4 ++-- config | 13 ++--- 2 files changed, 4 insertions(+), 13 deletions(-) diff --git a/Configurations/10-main.conf b/Configurations/10-main.conf index 4085e10..6315b2c 100644 --- a/Configurations/10-main.conf +++ b/Configurations/10-main.conf @@ -1232,10 +1232,10 @@ }, Cygwin -"Cygwin" => { +"Cygwin-i686" => { inherit_from => [ asm("x86_asm") ], cc => "gcc", -cflags => "-DTERMIOS -DL_ENDIAN -march=i486 -Wall", +cflags => "-DTERMIOS -DL_ENDIAN -Wall", debug_cflags => "-g -O0", release_cflags => "-O3 -fomit-frame-pointer", sys_id => "CYGWIN", diff --git a/config b/config index e805a84..a888fd8 100755 --- a/config +++ b/config @@ -324,15 +324,7 @@ case "${SYSTEM}:${RELEASE}:${VERSION}:${MACHINE}" in echo "${MACHINE}-whatever-mingw"; exit 0; ;; CYGWIN*) - case "$RELEASE" in - [bB]*|1.0|1.[12].*) - echo "${MACHINE}-whatever-cygwin_pre1.3" - ;; - *) - echo "${MACHINE}-whatever-cygwin" - ;; - esac - exit 0 + echo "${MACHINE}-pc-cygwin"; exit 0 ;; vxworks*) @@ -815,8 +807,7 @@ case "$GUESSOS" in fi ;; # these are all covered by the catchall below - *-*-cygwin_pre1.3) OUT="Cygwin-pre1.3" ;; - *-*-cygwin) OUT="Cygwin" ;; + *-*-cygwin) OUT="Cygwin-${MACHINE}" ;; x86pc-*-qnx6) OUT="QNX6-i386" ;; *-*-qnx6) OUT="QNX6" ;; x86-*-android|i?86-*-android) OUT="android-x86" ;; -- 2.5.0 signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4251] PR request: Add OCSP_SINGLERESP_get0_id() accessor
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
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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 you > kurt> > have a look at Configurations/10-main.conf, you might notice > kurt> > configuration items like debug_cflags, release_cflags, debug_lflags > kurt> > and release_lflags. If you have a look at my refactor-build branch, > kurt> > you will see a fairly thorough Configurations/README. If you look the > kurt> > commit titled "Refactor config - move templates docs asm templates to > kurt> > Configurations", you'll find the documentation that's applicable to > kurt> > what Configure in the master branch supports... later editions are > kurt> > currently only supported in my branch. > kurt> > kurt> In Debian we have a system that where you can override things like > kurt> the CFLAGS, and I wonder how easy it will be to integrate that > kurt> with your new system. > kurt> [...] > kurt> Is there an easy way to I can override the flags with > kurt> dpkg-buildflags? > > I see where you're going with this. > > As it is right now, there is no way to affect Configure via the > environment, except for the names of certain commands. Personally, > I'd say that using those should be done carefully. I have no plans to > expand on the use of environment variables... > > However, there is always the possibility to quickly write up a small > config target for yourself in Configurations, and have them inherit > the items for an already existing target. For example: > > cflags=` ... dpkg-buildflags --get CFLAGS`; \ > cat < Configurations/01-debian-tmp.conf > %targets = ( > "debian-linux-x86_64" => { > inherit_from => [ "linux-x86_64" ], > cflags => "$cflags", > } > ); > 1; > EOF > > If you want to just append or prepend your flags, you do this with the > cflags item: > > cflags => sub { join(" ", $@, "$cflags"); }, > > In my refactor-build branch, I've added some lazy functions to do the > same: > > cflags => add("$cflags"), > > or > > cflags => add_before("$cflags"), # to prepend > > Did that help? This is pretty non-standard. By not allowing to extend CFLAGS from the environment, you require all distros to patch the OpenSSL package to fit their needs in terms of the build flags. Why is that necessary? It's no problem at all with autotool or cmake-based configurations, and it's really *needed* by distros. Ideally you simply define CFLAGS differently, along the lines of OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] CFLAGS+=$(OPENSSL_CFLAGS) This way, the package build system can simply set CFLAGS to the desired value, as is typical. Alternatively, you can support a specific variable, e.g. OPENSSL_CFLAGS= -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS[...etc...] CFLAGS="${BUILD_CFLAGS) $(OPENSSL_CFLAGS)" and the package build system has to set $BUILD_CFLAGS. That would be sufficient as well. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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 afraid that is lost in the thin web of history ;-) Heh :) > vinschen> > vinschen> > vinschen> Please, please, please, Cygwin is a *POSIX* layer. Please don't use > vinschen> Windows functions on Cygwin, use POSIX functions and POSIX methods, > vinschen> *unless* it's really necessary. > > vinschen> > > I hear ya. > > vinschen> Last but not least, we have a small build problem when building for > the > vinschen> distro: To build the packages with additional debuginfo packages, > the > vinschen> packages must not be built with the -s option, plus we have to > induce a > vinschen> few options for the sake of creating the debuginfo information. Up > to > vinschen> 1.0.2 we do this by tweaking openssl's build system. We add an > expression > vinschen> $(OPT_CFLAGS) to the CFLAGS definition for that. If there's a > better, > vinschen> easier way to do this, I'd be grateful for a hint. > > OPT_FLAGS would be for optimizing, do I get that right? Uh no, I think OPT stands for "optional" in this case. I didn't invent the name, actually :) > 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 you have a look at my refactor-build branch, > you will see a fairly thorough Configurations/README. If you look the > commit titled "Refactor config - move templates docs asm templates to > Configurations", you'll find the documentation that's applicable to > what Configure in the master branch supports... later editions are > currently only supported in my branch. I did that, but I don't see that the new build system would allow that any better than the previous build system. There's still no way to induce optional build flags into a build, unless you manually override CFLAGS, which is quite a burdon. In our case the options in OPT_CFLAGS added by the build systems are something along the lines of -ggdb -O2 -pipe -Wimplicit-function-declaration \ -fdebug-prefix-map=${BUILDDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 \ -fdebug-prefix-map=${SOURCEDIR}=/usr/src/debug/openssl-1.1.0-pre2-1 This is required to make sure that the debuginfo is created during the build at all, and to make sure the mapping in the debuginfo is not using the build paths, but rather the installation paths. Otherwise the debuginfo pointer in the object files will point to the wrong paths. The above is provided by the package build system and depends on the path the build is done in, as well as the version of the package. This info is added by the package build system for all packages built for the distro. However, what that means is, we need to have a way to induce variable content into the release_cflags from "outside". This is usually no problem at all for packages with, e.g., autotool-based configuration. It's also not a Cygwin-specific problem. I dare say that many distro package builders have certain requirements to add variable build options to a build to allow distro-specific build options. It would be really nice if the OpenSSL build systems would allow that by default. Otherwise distros will always have to patch the package before being able to build it in a distro-specific way. > vinschen> The attached patchset fixes all of the above. With this, > vinschen> openssl-1.1.0-pre2 builds fine for Cygwin. > > I'll have a closer look at all that tomorrow. Thanks, Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code
> 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. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code
> 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. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl-commits] [openssl] master update
> 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. ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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.conf, you might notice kurt> > configuration items like debug_cflags, release_cflags, debug_lflags kurt> > and release_lflags. If you have a look at my refactor-build branch, kurt> > you will see a fairly thorough Configurations/README. If you look the kurt> > commit titled "Refactor config - move templates docs asm templates to kurt> > Configurations", you'll find the documentation that's applicable to kurt> > what Configure in the master branch supports... later editions are kurt> > currently only supported in my branch. kurt> kurt> In Debian we have a system that where you can override things like kurt> the CFLAGS, and I wonder how easy it will be to integrate that kurt> with your new system. kurt> kurt> We have a tool called dpkg-buildflags. By default it now returns: kurt> $ dpkg-buildflags kurt> CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 kurt> CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> FCFLAGS=-g -O2 -fstack-protector-strong kurt> FFLAGS=-g -O2 -fstack-protector-strong kurt> GCJFLAGS=-g -O2 -fstack-protector-strong kurt> LDFLAGS=-Wl,-z,relro kurt> OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security kurt> kurt> In the 1.0.2 branch I use this: kurt> my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . `dpkg-buildflags --get LDFLAGS` . "-Wa,--noexecstack -Wall"; kurt> kurt> And then use $debian_cflags in the targets. kurt> kurt> There were was no way to separate clfags/lfdlags, so I needed to kurt> combine it. kurt> kurt> dpkg-buildflags can return different things depending on environment variables. kurt> Some examples: kurt> $ DEB_BUILD_OPTIONS=noopt dpkg-buildflags --get CFLAGS kurt> -g -O0 -fstack-protector-strong -Wformat -Werror=format-security kurt> kurt> $ DEB_BUILD_OPTIONS=hardening=-all dpkg-buildflags --get CFLAGS kurt> -g -O2 kurt> kurt> $ DEB_CFLAGS_APPEND=-O3 dpkg-buildflags --get CFLAGS kurt> -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -O3 kurt> kurt> kurt> There are environment variables for both the maintainer to set the kurt> defaults and someone who then wants to build the package with kurt> different settings. kurt> kurt> (I should move the -Wa,--noexecstack -Wall to environment kurt> variables.) kurt> kurt> Is there an easy way to I can override the flags with kurt> dpkg-buildflags? I see where you're going with this. As it is right now, there is no way to affect Configure via the environment, except for the names of certain commands. Personally, I'd say that using those should be done carefully. I have no plans to expand on the use of environment variables... However, there is always the possibility to quickly write up a small config target for yourself in Configurations, and have them inherit the items for an already existing target. For example: cflags=` ... dpkg-buildflags --get CFLAGS`; \ cat < Configurations/01-debian-tmp.conf %targets = ( "debian-linux-x86_64" => { inherit_from => [ "linux-x86_64" ], cflags => "$cflags", } ); 1; EOF If you want to just append or prepend your flags, you do this with the cflags item: cflags => sub { join(" ", $@, "$cflags"); }, In my refactor-build branch, I've added some lazy functions to do the same: cflags => add("$cflags"), or cflags => add_before("$cflags"), # to prepend Did that help? Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] [openssl.org #4252] [PATCH] Fix the inclusion of e_os2.h
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: [PATCH] Fix the inclusion of e_os2.h --- crypto/o_dir_test.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/crypto/o_dir_test.c b/crypto/o_dir_test.c index 5dd9d21..8581e1c 100644 --- a/crypto/o_dir_test.c +++ b/crypto/o_dir_test.c @@ -35,7 +35,7 @@ #include #include #include -#include "e_os2.h" +#include "openssl/e_os2.h" #include "internal/o_dir.h" #if defined OPENSSL_SYS_UNIX || defined OPENSSL_SYS_WIN32 || defined OPENSSL_SYS_WINCE -- 2.5.0 ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published
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 you have a look at my refactor-build branch, > you will see a fairly thorough Configurations/README. If you look the > commit titled "Refactor config - move templates docs asm templates to > Configurations", you'll find the documentation that's applicable to > what Configure in the master branch supports... later editions are > currently only supported in my branch. In Debian we have a system that where you can override things like the CFLAGS, and I wonder how easy it will be to integrate that with your new system. We have a tool called dpkg-buildflags. By default it now returns: $ dpkg-buildflags CFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2 CXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security FCFLAGS=-g -O2 -fstack-protector-strong FFLAGS=-g -O2 -fstack-protector-strong GCJFLAGS=-g -O2 -fstack-protector-strong LDFLAGS=-Wl,-z,relro OBJCFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security OBJCXXFLAGS=-g -O2 -fstack-protector-strong -Wformat -Werror=format-security In the 1.0.2 branch I use this: my $debian_cflags = `dpkg-buildflags --get CFLAGS` . `dpkg-buildflags --get CPPFLAGS` . `dpkg-buildflags --get LDFLAGS` . "-Wa,--noexecstack -Wall"; And then use $debian_cflags in the targets. There were was no way to separate clfags/lfdlags, so I needed to combine it. dpkg-buildflags can return different things depending on environment variables. Some examples: $ DEB_BUILD_OPTIONS=noopt dpkg-buildflags --get CFLAGS -g -O0 -fstack-protector-strong -Wformat -Werror=format-security $ DEB_BUILD_OPTIONS=hardening=-all dpkg-buildflags --get CFLAGS -g -O2 $ DEB_CFLAGS_APPEND=-O3 dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -O3 There are environment variables for both the maintainer to set the defaults and someone who then wants to build the package with different settings. (I should move the -Wa,--noexecstack -Wall to environment variables.) Is there an easy way to I can override the flags with dpkg-buildflags? Kurt ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] [openssl.org #4115] [PATCH] Remove remaining FIPS code
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. Regards Roumen Petrov ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
[openssl-dev] Personal configuration in 1.1.0
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 new style configurations found in Configurations/, but those bits haven't been tried for some time. As a matter of fact, those last traces are completely removed in my my refactor-build branch. If you want to keep some personal configurations around, I'd suggest having a look at the personal ones some of us in the team are keeping around in Configurations/, and build your own using them as a model on how to do so. Unfortunately, the documentation isn't there yet, at least in master. (have a look at my refactor-build branch, it has a Configurations/README which I hope does a fair enough job... if there are enhancements needed, feedback is welcome!) The older configuration strings still work as usual in the 1.0.x releases. That won't change, of course. Cheers, Richard -- Richard Levitte levi...@openssl.org OpenSSL Project http://www.openssl.org/~levitte/ ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] MSVC 2015 internal compiler error
> 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
[openssl-dev] [openssl.org #4248] Link error under Windows
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 of our master branch?), it's a bit difficult to help you further. All I can suggest is that you download 1.1.0 pre 2 (was release this Thursday) or make a fresh pull of our master branch and try again. In the mean time, I'm closing this ticket. Should you run into this issue anew, feel free to report again. Cheers, Richard Vid Sat, 16 Jan 2016 kl. 03.14.17, skrev marc.st...@approach.be: > On any version of Windows (32 or 64 bits), if using the "no-deprecated" > configure flag, some functions (see list below) are not compiled but > they are still referenced in LIBEAY32.DEF. This gives the following > error: LIBEAY32.def : error LNK2001: unresolved external symbol ... > > List of functions: > - BN_BLINDING_get_thread_id > - BN_BLINDING_set_thread_id > - BN_CTX_init > - BN_generate_prime > - BN_get_params > - BN_is_prime > - BN_is_prime_fasttest > - BN_set_params > - CRYPTO_get_id_callback > - CRYPTO_set_id_callback > - CRYPTO_thread_id > - DH_generate_parameters > - DSA_generate_parameters > - ERR_remove_state > - RSA_generate_key > - bn_dup_expand > -- Richard Levitte levi...@openssl.org ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
Re: [openssl-dev] MSVC 2015 internal compiler error
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 with such a problem. > So I gave a try to Visual Studio Community 2013 SP 5, and it compiles even > without a warning. > Contrary at what I read, the update 1 of VS 2015 didn't fixed this. I think I have this "update 1" from the cl version: Microsoft (R) C/C++ Optimizing Compiler Version 19.00.23026 for x86 And did you have problems with the x86 compiler too? Did you try the x64 version also? -- --gv ___ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev