[Gambas-user] Pre-release of Gambas 3.9.1

[Tobias Boege]

On Mon, 05 Sep 2016, Benoît Minisini wrote:
> Le 05/09/2016 à 17:22, Tobias Boege a écrit :
> >
> > Two things are preventing me from applying it:
> >
> >   1. Currently: I have exams and my thesis to do.
> 
> Hope everything goes well!
> 
> >   2. More fundamentally: I see no point in that patch. It adds code that is
> >      compiled in for openssl versions so old that the configure script would
> >      not even enable gb.openssl.
> >
> > Apparently Piccoro's openssl version, which is strictly below the requirement
> > of 1.0.0, is some marvellous chimera of patches which somehow add the
> > functions required to build gb.openssl even if the version number is too
> > small. But I have no idea where these patches come from. I have inspected the
> > squeeze-lts (which is the Debian version he is running(?)) package of openssl
> > with its patches twice and could not find a way which could have added these
> > functions.
> >
> > So, I simply don't understand how it is possible that gb.openssl compiles on
> > his deprecated system, and I /believe/ it is some specific patch on his end.
> > Therefore, I can't just lower the general version requirement, because it
> > might break on systems which don't have this mysterious patch.
> >
> > If I don't lower the version requirement from 1.0.0 to 0.9.8o, then the
> > patch is effectively useless and there is no justification to apply it.
> > My stance is that since (for all I know) his openssl is very old and very
> > special (in a way that conflicts with the openssl changelog), he should be
> > the one to patch his local Gambas source tree to compile with his local
> > openssl version.
> >
> > So the problem really is my lack of understanding. If anyone understands why
> > Piccoro's openssl 0.9.8o has the EVP_MD_do_all() function, please explain the
> > situation to me. Otherwise I'll do nothing.
> >
> > But Benoit: if you say we can just apply it even if it makes no sense, and
> > propose something sensible for the commit log, I'll just throw it in and try
> > to forget this huge waste of time. We are talking hours upon hours about
> > openssl on a Debian that has ended LTS support 6 months ago for god's sake.
> >
> > Regards,
> > Tobi
> >
> 
> OK, I get it. No, if a patch has non sense, there is no reason to apply it.
> 
> If there is only one function missing, and its source code is simple 
> enough, you can add it to the source code conditionnally, by testing its 
> unavailability in the 'configure.ac' file.
> 

I don't know if it's easy to include it. The function I was talking about
iterates over the internal tables of digests which sounds sufficiently
internal to not try to do it in gb.openssl. It also is the first symbol
where compilation fails. Who knows where it fails after I pull that
function in.

> If the problem concerns other functions of the openssl API, we will do 
> nothing. Too much work for that!
> 

Well, I didn't know you could check for the presence of functions in the
configure script. I have replaced the version check by the availability of
that function (which I admit is kind of ugly) and applied Piccoro's patch
in #7892.

It would probably be wise not to include it in 3.9.1 if it is to be released
soon. At least Sebastian and other people who compile some Gamba on
different systems should report back if it doesn't cause havoc on normal
distributions.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk