Rubyinstaller devel - Jul 2008 - Succeed building OpenSSL (kind of)

Hello Guys,

I the issue with OpenSSL (the lack of updated version) is very annoying.

One path to solve that is what Lars implemented in his fork, which
rely on strawberry Perl and looks it works. The down side: 30MB of
perl download since strawberry "flavor" bundles it''s own
MinGW
environment.

Other alternative was using ActivePerl, which require manual
installation, and thus, cannot be automated.

There are several downsides with OpenSSL: the lack of configure / make
/ make install familiar with *nix packages that usually works with
MinGW+MSYS and the forced usage of perl to build OpenSSL :-P

I''ve been exploring the Thor recipes for building OpenSSL:

https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL

Which, so far, produced good results, excep for being static linked
libraries instead of shared ones.

When I turn on the shared ones, it fails (need to review what is wrong).

I''ll invest my time getting this working instead of depending on
another huge package like strawberry or activestate perl.

Why? is not the succeed, but sounds stupid from the OpenSSL developers
they: 1) ship with symlinks and 2) do not provide a *nix like building
solution for Windows (configure / make / make install).

In any case, Is just my opinion, but I''ll love heard other thoughts
about it.

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

On Mon, 14 Jul 2008, Luis Lavena wrote:
> Other alternative was using ActivePerl, which require manual 
> installation, and thus, cannot be automated.
It seems to be possible to automate ActivateState extraction using a 
so-called "administrative install". Check it out at

http://github.com/larsch/rubyinstaller/commits/openssl-activestate

It not a whole lot better than Strawperry perl; the AS Perl distribution 
is still 17MB, and extracting using msiexec takes quite a while. It could 
be made optional however, if an installation is detected on the build 
host.
> Why? is not the succeed, but sounds stupid from the OpenSSL developers
> they: 1) ship with symlinks and 2) do not provide a *nix like building
> solution for Windows (configure / make / make install).
Particularly ironic is this sarcastic statement from their FAQ: "autoconf 
will probably be used in future OpenSSL versions. If it was less 
Unix-centric, it might have been used much earlier.".
> In any case, Is just my opinion, but I''ll love heard other
thoughts about it.
Using an unofficial (or hacked) build procedure for OpenSSL does not 
appear as an ideal solution to me either, 
(http://metasploit.com/users/hdm/tools/debian-openssl/ comes to mind).

An alternative is to hack their Makefile-generator script to work around 
the issues with msys-perl? It seemed to be a path issue when I tried. Perl 
is not fresh in my memory however.

Lars

On Tue, Jul 15, 2008 at 12:08 AM, Lars Christensen <larsch at
belunktum.dk> wrote:
>
>
> On Mon, 14 Jul 2008, Luis Lavena wrote:
>
>> Other alternative was using ActivePerl, which require manual
installation,
>> and thus, cannot be automated.
>
> It seems to be possible to automate ActivateState extraction using a
> so-called "administrative install". Check it out at
>
> http://github.com/larsch/rubyinstaller/commits/openssl-activestate
>
> It not a whole lot better than Strawperry perl; the AS Perl distribution is
> still 17MB, and extracting using msiexec takes quite a while. It could be
> made optional however, if an installation is detected on the build host.
>
Yeah, and a administrative install still pollutes the Windows
Installer information database (ala: it keep track of your
administrative install). Couldn''t confirm with proper examples but
found issues in the past doing the same with other tools
>> Why? is not the succeed, but sounds stupid from the OpenSSL developers
>> they: 1) ship with symlinks and 2) do not provide a *nix like building
>> solution for Windows (configure / make / make install).
>
> Particularly ironic is this sarcastic statement from their FAQ:
"autoconf
> will probably be used in future OpenSSL versions. If it was less
> Unix-centric, it might have been used much earlier.".
>
Yeah, plain and simple irony... :-P
>> In any case, Is just my opinion, but I''ll love heard other
thoughts about
>> it.
>
> Using an unofficial (or hacked) build procedure for OpenSSL does not appear
> as an ideal solution to me either,
> (http://metasploit.com/users/hdm/tools/debian-openssl/ comes to mind).
>
> An alternative is to hack their Makefile-generator script to work around
the
> issues with msys-perl? It seemed to be a path issue when I tried. Perl is
> not fresh in my memory however.
>
What I did and succeed:

Replace the files that reported with symlink extraction issues with
the proper files.
(most header files and some c ones)

Removed the test folder and after executed config script, modified the
generated makefile to remove the test.

In any case, I took a look at the makefiles from GNUwin32 and they are
quite interesting (Makefile.mingw and Makefile.ssl), maybe we can base
on that for our parameters?

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams

On 14/07/2008, Luis Lavena <luislavena at gmail.com>
wrote:
> Hello Guys,
>
>  I the issue with OpenSSL (the lack of updated version) is very annoying.
>
>  One path to solve that is what Lars implemented in his fork, which
>  rely on strawberry Perl and looks it works. The down side: 30MB of
>  perl download since strawberry "flavor" bundles it''s
own MinGW
>  environment.
>
>  Other alternative was using ActivePerl, which require manual
>  installation, and thus, cannot be automated.
>
>  There are several downsides with OpenSSL: the lack of configure / make
>  / make install familiar with *nix packages that usually works with
>  MinGW+MSYS and the forced usage of perl to build OpenSSL :-P
>
>  I''ve been exploring the Thor recipes for building OpenSSL:
>
>  https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL
>
>  Which, so far, produced good results, excep for being static linked
>  libraries instead of shared ones.
>
>  When I turn on the shared ones, it fails (need to review what is wrong).
>
I think there is no problem with static libraries (as long as they can
be used to build the extension). The library is going to be used only
for a single extension so there is no sharing anyway. Actually you
might save some space by linking statically.

Thanks

Michal

On Tue, Jul 15, 2008 at 3:49 PM, Michal Suchanek <hramrach at centrum.cz>
wrote:
> On 14/07/2008, Luis Lavena <luislavena at gmail.com> wrote:
>> Hello Guys,
>>
>>  I the issue with OpenSSL (the lack of updated version) is very
annoying.
>>
>>  One path to solve that is what Lars implemented in his fork, which
>>  rely on strawberry Perl and looks it works. The down side: 30MB of
>>  perl download since strawberry "flavor" bundles
it''s own MinGW
>>  environment.
>>
>>  Other alternative was using ActivePerl, which require manual
>>  installation, and thus, cannot be automated.
>>
>>  There are several downsides with OpenSSL: the lack of configure / make
>>  / make install familiar with *nix packages that usually works with
>>  MinGW+MSYS and the forced usage of perl to build OpenSSL :-P
>>
>>  I''ve been exploring the Thor recipes for building OpenSSL:
>>
>>  https://svn.torproject.org/svn/torbrowser/trunk/build-scripts/INSTALL
>>
>>  Which, so far, produced good results, excep for being static linked
>>  libraries instead of shared ones.
>>
>>  When I turn on the shared ones, it fails (need to review what is
wrong).
>>
>
> I think there is no problem with static libraries (as long as they can
> be used to build the extension). The library is going to be used only
> for a single extension so there is no sharing anyway. Actually you
> might save some space by linking statically.
>
Thank you for your input Michal.

Yeah, I''ve seen no problem with the static builds, but I''m
worried
about the interface between Ruby and Postgres, which bundles as shared
library latest OpenSSL.

Dunno if sometimes there will be some conflict at execution time that
can be bad in the long run.

Also, if developers require to build other Ruby C extensions that
depends on OpenSSL (dunno which one yet, but just in case), we will
require to have a bundle of those modifications as a downloadable zip
package.

But please, people, drop me the negatives comments so that forces me
to work on better alternatives ;-)
> Thanks
>
Thanks to you for your comments and following the list!

-- 
Luis Lavena
AREA 17
-
Human beings, who are almost unique in having the ability to learn from
the experience of others, are also remarkable for their apparent
disinclination to do so.
Douglas Adams