[Win32utils-devel] win32utils with ruby installer
charley.baker at gmail.com
Thu Dec 31 16:07:47 EST 2009
Thanks for the explanation. Comments inline.
On Thu, Dec 31, 2009 at 6:46 AM, James Tucker <jftucker at gmail.com> wrote:
> 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
>> 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:
> 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:
> (this one is new, and might actually be a solution! (Luis - some input here
> if you can?))
> Old threads:
> 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!
Very cool, thanks for the references. It's been a long time since I did a
lot of Windows programming, and though I used C/C++ never delved into SEH. I
do now remember seeing at the time though.
> 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
>> 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
> 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".
Ok, now that I get it, I haven't checked out the win32utils source that
we're using, but it sounds like the code is using SEH for some of the api
calls? From some of the threads I've been reading, since the msvc6 libs and
the mingw libs should both be compiled against the same version of the c
runtime - msvcrt.dll, then that should theoretically cause problems?
Falsifying the platform sounds a bit dodgy, but will make install easier for
newbs avoiding the platform flag.
Ideally I still want to say 'gem install watir' will work without any
machinations, hedging or confusion, that's the use case. Anything trickier
starts to pile up an already large backlog of user questions and support.
> 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.
Warning on the site that's it potentially alpha grade and there are some
differences. However, it does look generally promising if that's what's
required to compile the libs.
>> 1. Build all libs that can be built for mingw, under mingw, using the
>> 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.
Luis is amazing and a non stop force in making Windows a less than 3rd class
citizen on Ruby, Daniel for that matter as well. :) Given that Watir started
out with Windows and IE as the primary target (still is in many respects
with our user base), it's been an uphill battle. I'm happy to help out in
any way possible. It's been a while since Windows programming was my primary
job, but I'm diving into this a bit and hope to help.
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the win32utils-devel