This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: sablevm + windows


On Thu, 2004-10-07 at 18:45, Peter Lovell wrote:
> I was not able to check out Mélanie's sandbox in the way you suggested
> ($ svn co svn+ssh://svn.sablevm.org/public/developers/mlord 
> sablevm-mlord) probably because I don't have an ssh account. However
> I was able to  fetch svn.sablevm.org/developers/mlord/sandbox
> which hopefully is the same (disabuse me of that notion if appropriate).

Yes, it's the same.

> The porting document there was very helpful and for our use I've 
> translated it into English. It's in the same format and not wiki-ized, 
> but even so it may be useful to have on sablevm.org -- just let me know 
> where.

Could you please put it up on a web page somewhere and provie an URL?

> It seems that many of the changes mentioned there have been made to 
> subsequent versions of sablevm and classpath, so I should probably add 
> a caveat to that effect.

Yes, most of the changes are no longer necessary as they're part of
standard sablevm/sablevm-classpath.  Altough there still exist practical
issues how to build SableVM and Classpath effectively.

> I'm still having a problem getting a proper version of libffi built, 
> and will attack that further tomorrow. Part of the problem is that I'm 
> not very familiar with auto* tools (but learning rather quickly).

If you take a look at thread that started here:

http://sablevm.org/lists/sablevm-devel/2004-September/000064.html

Gerrit (from Cygwin project) suggested:

"You can link against static archives when using 'pass_all' instead of
 'file_magic ^x86 archive import|^x86 DLL' to recognise dependent
 libraries in libtool (change in libtool.m4)."

*IF* this change was able to save you from building .dlls of all libs
sablevm or sablevm-classlib links to - it'd save *a lot* of effort.

I did that change and the compilation went smoothly, but the produced
sablevm.exe dind't work.  It was causing Windows to show message box

"Application could not be initialized correctly (0xc0000005)
 Click OK to terminate the application"

This thread seems to explain further that kind of problems:
http://www.newsarch.com/archive/mailinglist/cygwin/msg11772.html

At this point I am not sure if there's anything else we can do
to avoid building cygffi.dll and link with static library, or
we should request cygwin gcc maintainer to build cygffi.dll
right away?

If SableVM was to become part of applications available for Cygwin
(which I hope will happend) we'd want it to be "mostly/easily buildable"
with tools and libraries Cygwin provides (like it takes place in Debian
or Gentoo).

> There is a libffi change to support darwin and I'm not sure if that has 
> made it into the official gnu release. However it works well on Mac OS 
> X (I'm a Mac developer from way back), and sablevm+classpath are 
> running there nicely (OS X 10.3).

Nice to hear that. 

Cheers,

			Grzegorz B. Prokopski

PS: I Cc:ed cygwin ML.  If you reply to this message please make
sure you include both: sablevm-devel@sablevm.org and cygwin@cygwin.com
addresses in your reply.

-- 
Grzegorz B. Prokopski      <gadek@debian.org>
Debian GNU/Linux           http://www.debian.org
SableVM - LGPL'ed Java VM  http://www.sablevm.org
Why SableVM ?!?            http://sablevm.org/wiki/Features



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]