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]
--------
|
