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

[Corinna Vinschen]

On Jan 17 14:56, Richard Levitte wrote:
> In message <20160117131603.GA10909 at roeckx.be> on Sun, 17 Jan 2016 14:16:04 +0100, Kurt Roeckx <kurt at roeckx.be> 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 <<EOF > 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160117/369bbc12/attachment.sig>