Re: [openssl-dev] Personal configuration in 1.1.0

[Erik Forsberg]

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] Personal configuration in 1.1.0

[Richard Levitte]

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] Upcoming build system change

[Corinna Vinschen]

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

[openssl-dev] [openssl.org #4253] [PATCH] Build system fixes for GCC

[Alessandro Ghedini via RT]

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

[openssl-dev] [openssl.org #4248] Link error under Windows

[Richard Levitte via RT]

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

[openssl-dev] Personal configuration in 1.1.0

[Richard Levitte]

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

[Michel]

> 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

Re: [openssl-dev] OpenSSL version 1.1.0 pre release 2 published

[Richard Levitte]

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

Re: [openssl-dev] [openssl-commits] [openssl] master update

[Salz, Rich]

> 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.org #4115] [PATCH] Remove remaining FIPS code

[Salz, Rich]

> 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

[Salz, Rich via RT]

> 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 version 1.1.0 pre release 2 published

[Corinna Vinschen]

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 version 1.1.0 pre release 2 published

[Corinna Vinschen]

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

[openssl-dev] [openssl.org #4251] PR request: Add OCSP_SINGLERESP_get0_id() accessor

[Rich Salz via RT]

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

[openssl-dev] [openssl.org #4252] [PATCH] Fix the inclusion of e_os2.h

[Bheesham Persaud via RT]

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

[Richard Levitte]

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 

Re: [openssl-dev] Upcoming build system change

[Richard Levitte]

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] Upcoming build system change

[Corinna Vinschen]

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] OpenSSL version 1.1.0 pre release 2 published

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Corinna Vinschen]

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

[Richard Levitte]

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] Upcoming build system change

[Richard Levitte]

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] OpenSSL version 1.1.0 pre release 2 published

[Richard Levitte]

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] OpenSSL version 1.1.0 pre release 2 published

[Richard Levitte]

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