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-sehhttp://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>