From: Mike R. <mik...@gm...> - 2007-08-23 02:38:49
|
Forwarded Conversation Subject: Sooc on Win32 ------------------------ From: Dan Reinish <de...@cm...> To: mik...@gm... Date: Wed, Aug 22, 2007 at 1:12 AM Let me preface this e-mail by pointing out that I was bored. Now, that being said, I decided to look into the perils of the Win32 platform, since this is something we discussed once before. Yes, I could have done something practical like writing documentation or (gasp!) actual code. But no....I was far more intrigued by this... Anyway, I installed MingW and jumped through hoops to get automake 1.8 and autoconf 2.59 on the system (automake 1.9 was available; however, "aclocal" would not produce any output at all). This configuration worked just fine once I instructed sooc to use the older version. After this, I needed to get the win32 version of pthreads and a regex implementation that was available directly from the MingW repository. With these necessary libraries on hand, I attempted to compile Sooc. Now, keep it mind that I have skipped over many dreary details about what happened in between all these *successful* steps. In any case, the long and the short of it is that with the necessary versions of autotools and those two libraries installed on top of the basic MingW stuff, Sooc appeared to compile to some extent. Specifically, I ended up with libsooc.a and libsooc.la. There was no shared library/dll produced, however, and I'm not 100% sure how one causes that to happen (or if its absence is even an error). Library confusion aside, what this does show, I think, is that if the config files were changed to make sooc intentionally produce a static library, we would have something that could be directly linked to windows software for use of sooc-style programming. Not that I want to do that. i'm just relaying the news... -------- From: Mike Richman <mik...@gm...> To: Dan Reinish <de...@cm...> Date: Wed, Aug 22, 2007 at 2:09 AM I'm glad you've had this much success with Sooc + win32. In fact, I have been down that road as well. I'm not really sure how static libraries work on win32, but I know that dynamic libraries have very specific and (to me) confusing demands about object and function definitions at link time. I don't know what your tools generated, but I received clear errors to the effect that a .dll could not be built due to undefined symbols. Of course, it's not at all obvious which symbols were undefined. I read lots of information online, but none of the advice helped me ensure that all the symbols were defined. If we could do a static library, that would definitely be a great start. I also want to try building Sooc with Dev-C++... I have no idea what this would involve. If it works, though, then I would recommend adding the Dev-C++ files to svn and maintaining them so Sooc can be built as natively as possible on both platforms. Do you mind if I forward this message to soo...@li... ? -Mike [Quoted text hidden] -------- From: Dan Reinish <de...@cm...> To: Mike Richman <mik...@gm...> Date: Wed, Aug 22, 2007 at 5:55 PM You can forward it to sooc-devel. I should add, and you may want to include this, that there was actually a warning printed to the terminal in the middle of all the linking and archiving. It was not an error however, just a warning. By examining the output of a "normal" OS X compilation, I was able to deduce that this warning message occurred exactly where the process that produces the .dylib takes place. So, it is still possible that "make" attempted to produce the DLL but could not because, as you alluded to, no attempt was made to do all the proper declarations required for DLLs to work (and maybe this had something to do with the undefined symbols). [Quoted text hidden] -------- |