Re: [classlib] porting to other platforms

?rev=release-3-4-1#HowToBuildSupported [3] http://dev.icu-project.org/cgi-bin/viewcvs.cgi/icu4jni/readme.html?rev=release-3-4 Marina Goldburt wrote: The other problem to port classllib to 64-bit platforms is that the classlib depends on the icu* binaries. We have the binaries only for ia32

Re: [classlib] porting to other platforms

The link to the patch: http://issues.apache.org/jira/browse/HARMONY-1005 Thanks, Marina On 7/31/06, Marina Goldburt [EMAIL PROTECTED] wrote: Hi, I've prepared a patch, that allows the classlib to be compiled and run under Linux/x86_64 platform. Please, review and comment it. Marina On 7

Re: portlib functionality

On 7/25/06, Tim Ellison [EMAIL PROTECTED] wrote: If you honour the existing table layout then you don't need to break compatibility. In addition, VMs are not required to use the class library portlib if they choose not to. I don't know the way IBM VME uses the portlibrary, but concerning the

[classlib] porting to other platforms

Hi, I'm interested in the task of porting classlib to the 64bit platform (em64t/amd64). At this moment, classlib's source structure and build system doesn't support the diversity of platforms. Let's discuss what changes have to be made to support other platforms. One way is to move

Re: [classlib] porting to other platforms

On 7/25/06, Paulex Yang [EMAIL PROTECTED] wrote:mm... Do you mean VM or classlib? I'm not familiar with current VM(DRL, JCHEVM, BootJVM...)'s structure, but for classlib, IIRC we have discussed these issue before, and seems the agreement is to layout them into directories, For example, the

Re: [classlib] porting to other platforms

, Dmitry. 2006/7/25, Marina Goldburt [EMAIL PROTECTED]: Hi, I'm interested in the task of porting classlib to the 64bit platform (em64t/amd64). At this moment, classlib's source structure and build system doesn't support the diversity of platforms. Let's discuss what changes have to be made

Re: portlib functionality

Hi, Paulex, On 7/7/06, Paulex Yang [EMAIL PROTECTED] wrote: Yes, I'm working on the FileChannel completion, and my thought is to write platform dependent codes for mmap at first(I thought it is easier to be accepted, so that things can be moved forward), then propose a mmap related extension

Re: portlib functionality

Tim, Paulex, Will look at the file locking later...And I'm sure there are other things worthing evaluation to be portlib extension. And what is the way to extend the portlib functionality? If we add all the missing functions to the HyPortLibrary structure, the structure will grow awfully.

Re: portlib functionality

And the short answer is yes. The additional file system functionality such as file locking and memory mapping required by the (newly authored within this project) NIO code should be put into the port library. And what about hythread platform-dependent code? Have the thread and process

Re: [classlib]Using APR for Harmony's native link to the OS

and can switch the portlib implementation to APR (if it have the appropriate memory model by the moment). Marina. On 7/4/06, Mark Hindess [EMAIL PROTECTED] wrote: On 4 July 2006 at 13:13, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Marina Goldburt wrote: Hi, To support the idea

[classlib]Using APR for Harmony's native link to the OS

Hi, To support the idea mentioned in the letter http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED], I've tried to implement the file I/O part of the Harmony portlib using APR. The JIRA issue with the patch is

Re: [classlib]hythreads implementation

Hi, On 6/23/06, Tim Ellison [EMAIL PROTECTED] wrote: The IBM VME doesn't use Harmony's thread library (there is a remarkably similar library in the VM subdir called j9thr23). And,of course, if other VM's want to use their own thread library they are free to do so. And if the both VM use

[drlvm] build fails on Windows os

Hi, I've caught the following error when tried to build the drlvm today on Windows OS: [cc] 0 total files to be compiled. [cc] Starting link [cc]Creating library vmcore.lib and object vmcore.exp [cc] aprutil-1.lib(apr_xml.obj) : error LNK2019: unresolved

Re: [drlvm] build fails on Windows os

On 6/27/06, Geir Magnusson Jr [EMAIL PROTECTED] wrote: Odd. It was broken for me too. What changed? I applied the patch - thanks. geir I think, the problem is in the log4cxx revision - the old log4cxx didn't use the aprutil xml API. Marina Marina Goldburt wrote: Hi, I've caught

[classlib]hythreads implementation

Hi, I've noticed such a strange thing when examined drlvm building process. The drlvm replaces hythreads shared library with its own simple implementation based on APR. The drlvm hythreads library exports less than 1/2 functions comparing with the original hythr.dll. I thought the rest of

Re: [drlvm] linking question

Hi, The problem is in the order of the linked libs. the order is important for gcc. Change components/vm/vmi, the order must be: libset libs=hyzip dir=${external.dep.CLASSLIB.libdir} / libset libs=hypool dir=${external.dep.CLASSLIB.libdir} / libset libs=hyprt

Re: [general] milestones and roadmap

11) em64t/ipf platform support On 6/20/06, Mikhail Loenko [EMAIL PROTECTED] wrote: 2006/6/20, Geir Magnusson Jr [EMAIL PROTECTED]: I'd like to start assembling a high-level roadmap of the milestones we'd like to achieve in the next 12 months. I volunteer to track and organize, but this