[Win32utils-devel] win32utils with ruby installer

James Tucker
Thu, 31 Dec 2009 13:46:55 -0000

On 30 Dec 2009, at 20:01, Charley Baker wrote:

> Does anyone else care to weigh in? Responses inline.
>
> Charley Baker
> Lead Developer, Watir, http://watir.com
>
>
> On Tue, Dec 29, 2009 at 4:09 PM, James Tucker <jftucker at gmail.com>
wrote:
>
> On 29 Dec 2009, at 18:58, Charley Baker wrote:
>
>> Hi all,
>>
>>   I''ve been spending a little time delving into the latest
Ruby installer and win32utils, several of which are needed by the  project
I''m working on - Watir. We have requirements for some of the process
libs which need the base apis, etc. It appears currently that we need to do one
of two things - either require the platform (mswin32) or install the devkit to
successfully install and use Watir gems in the current Ruby installer setup. For
development that''s fine, but that''s also the current case for
the enduser.
>>
>>  For this project are you planning on releasing mingw gems or fat
binaries, I''m trying to gauge what the impact to our users will be.
Like I say, I''ve just started looking at this and would be happy to
help with anything that''s needed, so my questions may be a bit naive as
I dive into this.
>
> There are some big issues here generally. Any library that uses SEH cannot
be compiled with gcc (read: won''t compile under the new ruby installer
builds). AFAIK this directly affects win32-api, and iirc, win32-process,
possibly win32-service too.
>
>
> Don''t know what SEH means. I''m sure I''m missing
an obvious TLA :P, but I don''t understand that.

Structured Error Handling:
http://msdn.microsoft.com/en-us/library/ms680657(VS.85).aspx

This is actually implemented as compiler extensions (contrary to the C/C++
specs), and as such, gcc cannot correctly compile applications or libraries that
use it. Some of the Windows APIs require the use of SEH, and as such *must* be
compiled with a Microsoft compiler.

Typically, the symptom you will see manifest in these cases is an undefined
symbol error on compile, for __try.

Other gory details can be found here:

http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh
http://www.programmingunlimited.net/siteexec/content.cgi?page=libseh     (this
one is new, and might actually be a solution! (Luis - some input here if you
can?))

Old threads:

http://lists-archives.org/mingw-users/04725-structured-exception-handling.html

I''ve not done any more research on this in a long time, as
I''ve not had to support any significant ruby stuff on windows for the
best part of the last year - so some fresh research would be recommended!

> You can install the mswin32-60 builds of these, via:
>
> gem install --platform=x86-mswin32-60 win32-api
>
> Obviously this is somewhat of a hacky solution, but one we can''t
really avoid.
>
> I realize that, and mentioned as much. It''s kind of a crummy step
to involve less technically savvy users, who simply want to install a gem that
works regardless. Is this the ideal plan when the new ruby installer rolls out?

Well, unless the new libseh thing above can actually solve the problem, then no,
the only way to solve this is for the relevant projects that must use SEH in
order to work, release msvc6 compiled binary versions of their gems, with a
falsified platform of "mingw".

> As there are no plans globally to make gcc build SEH, and the hacky
solutions don''t tend to work correctly, I would advise that these
projects take the following approach:

The above may now be misinformation, please disregard it, and take a look at
libseh.

>
> 1. Build all libs that can be built for mingw, under mingw, using the
devkit.
> 2. Libs that require an MS compiler for SEH, should be built with those,
and binary gems should be released for the mingw platform, using these builds
(as this is ABI compatible, and produces valid code).
> 3. Where possible, wrap up the above processes via rake-compiler.
>
>
> Which projects are you referring to when you say "these
projects"? I''m just looking at dependencies, and win32utils is a
big one. It''s not up to me to recompile all of our dependent libs.
Still confused, is there a short, medium and long term answer?

Any projects which use SEH. I can understand how none of that would have made
sense until one looked up SEH.

> I am sure that there are others that might want to weigh in on this, Luis
in particular, but this is the only valid option I know of at this time.
>
>>
>>  This also seems to be cross cutting between this project and then the
rubyinstaller in general which should cause a bit of chaos which I''ll
also try to help out with.

Best thing to do to help out is to try and get these things building under the
mingw devkit, and help Luis complete / enhance the devkit too. Inclusion of
libseh, pending some successful tests, would be one such important enhancement
to get you on your way to smooth sailing for your users. Luis valiantly puts a
lot of time into this stuff, and I''d encourage anyone to help out when
+ where they can.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/win32utils-devel/attachments/20091231/2d6e797c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3679 bytes
Desc: not available
URL:
<http://rubyforge.org/pipermail/win32utils-devel/attachments/20091231/2d6e797c/attachment-0001.bin>