[Vortex] Vortex OpenSSL versioning

Jeff Kenneally jkenneally at cartenav.com
Wed Jul 2 20:51:42 CEST 2014


Hi Franics,

Thanks for getting back to me.   I didn't try replacing the OpenSSL binaries directly, as I was under the impression that major version changes never match in terms of signatures (i.e. projects linked against older Libeay32.lib v0.9 would not successfully load a 1.0.1.x libeay32.dll).  At the very least it doesn't seem very safe from a stability point of view.

I should have explained myself better in the original message sent to the mailing list....I actually did move on to take a crack at building Vortex myself.  As discussed in an off-list email, I think I could ultimately get it to work, but it is far from a trivial task for a Visual Studio developer.  LibVortex has a bunch of additional dependencies, each of which have their own complexities/quirks when building on Microsoft Windows, without even getting to the issue of 64 bit targets.  These dependencies include libgsasl, libaxl,  libgsasl, openssl, and libcryto.  Most of them have to be built from source for Visual Studio/Windows, and it was not clear to me which versions of each dependency the current LibVortex should be built against.  LibAxl also turns out to require mingw installed, even if building from Visual Studio.

For now, we've decided we will try to get everything working by not using TLS, etc.  A quick experiment has shown that the basic vortex functionality is only loading libvortex/libaxl binaries, avoiding our OpenSSL conflict.

Your suggestion to build ourselves is definitely valid, and we may have to revisit in the future, but with any luck we can hold out until a future Vortex binary release.

Thanks again,
Jeff

________________________________
From: Francis Brosnan Blázquez [francis at aspl.es]
Sent: Wednesday, July 02, 2014 2:41 PM
To: Jeff Kenneally
Cc: vortex at lists.aspl.es
Subject: Re: [Vortex] Vortex OpenSSL versioning



Hello,


Hi Jeff,

Sorry for the delay...

I'm working on an application that currently needs to be built against both 32 and 64 bit Windows targets. I was happy to get confirmation recently that the Vortex SDK is produced for both.

I've since downloaded the latest versions of both SDK's from: "https://code.google.com/p/vortexlibrary/downloads/list"

There is a slight disparity in version numbers for the current w64 build (1.1.10) vs w32 (1.1.12), which in itself is not an issue.

Ok,

However, one battle that we can never seem to win with our product is that at least 3 third party packages we link against all use OpenSSL (ie libeay32.dll). Anytime we update any of them, it's a horrible juggling act to find up to date versions of all these dependencies that use a similar-enough version of Libeay32.DLL to not cause conflicts at runtime. Slight differences in build numbers tend to be fine, but the larger the gap, the more chance we start seeing missing symbol errors at run-time, or even linker errors depending on which of the various Libeay32 DLL's present actually got loaded by our process.

Did you try changing/upgrade libssl library to a newer version by just replacing them? Did it break after that?

The OpenSSL API subset used by Vortex Library is quite common and it works with openssl versions across different platforms with those version differences....

One thing I've noticed between the two Vortex Windows SDK's I mention above is that the w64 SDK contains Libeay32.dll vs 1.0.0.5, while the w64 SDK (newer version number) contains an older 0.9.8.11 version. Both versions are quite a bit behind the more recent releases (ie current GDAL binaries we are using link against Libeay32.dll v1.0.1.7).

Is there any way we can get Vortex w32 and w64 SDK's that use the same version of OpenSSL, and using a more recent version, such as 1.0.1.7?

Ok, this is obvious, but the best way is to grab source code from SVN or latest tar.gz and have them compiled with your current compiler. That way you don't have to depend on us releasing next stable release and/or producing those SDK installer plus the fact that debugging and binary output will match perfectly the entire product (without mentioning you'll be able to better control OpenSSL versions).

Best Regards,

Thanks very much,
Jeff

_______________________________________________
Vortex mailing list
Vortex at lists.aspl.es<mailto:Vortex at lists.aspl.es>
http://lists.aspl.es/cgi-bin/mailman/listinfo/vortex



--
Francis Brosnan Blázquez <francis.brosnan at aspl.es<mailto:francis.brosnan at aspl.es>>
ASPL
91 134 14 22 - 91 134 14 45 - 91 116 07 57

AVISO LEGAL

Este mensaje se dirige exclusivamente a su destinatario. Los datos
incluidos en el presente correo son confidenciales y sometidos a secreto
profesional, se prohíbe divulgarlos, en virtud de las leyes vigentes. Si
usted no lo es y lo ha recibido por error o tiene conocimiento del mismo
por cualquier motivo, le rogamos que nos lo comunique por este medio y
proceda a destruirlo o borrarlo.

En virtud de lo dispuesto en la Ley Orgánica 15/1999, de 13 de
diciembre, de Protección de Datos de Carácter Personal, le informamos de
que sus datos de carácter personal, recogidos de fuentes accesibles al
público o datos que usted nos ha facilitado previamente, proceden de
bases de datos propiedad de Advanced Software Production Line, S.L.
(ASPL). No obstante, usted puede ejercitar sus derechos de acceso,
rectificación, cancelación y oposición dispuestos en la mencionada Ley
Orgánica, notificándolo por escrito a:
ASPL - Protección Datos, C/Antonio Suárez 10 A-102, 28802, Alcalá de
Henares (Madrid).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.aspl.es/pipermail/vortex/attachments/20140702/c0484669/attachment.html>


More information about the Vortex mailing list