You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by snowdosker <sn...@academ.org> on 2006/02/18 14:31:07 UTC
Re: Classpath on Cygwin: failed to open native library error
Hi, Enrico.
Just figured out the roots of the problem. It comes from dlopen()
function on cygwin.
*JCHEVM* use the following code for loading native shared libraries
in \cygwin\home\ivan\jchevm\libjc\native_lib.c line:330
else if ((handle = dlopen(dlname, RTLD_NOW)) == NULL) {
_JC_EX_STORE(env, UnsatisfiedLinkError,
"failed to open native library `%s': %s", name, dlerror());
goto fail;
}
Exactly what we see in error output....
So I just wrote simple test
if ((handle =
dlopen("/usr/local/classpath/lib/classpath/*libjavanio.dll.a*",
RTLD_NOW)) == NULL) {
printf("fail %s", dlerror());
}
else {
printf("loaded");
}
And it's failed
Well, then I tried to
if ((handle =
dlopen("/usr/local/classpath/lib/classpath/*cygjavanio-0.dll*",
RTLD_NOW)) == NULL) {
printf("fail %s", dlerror());
}
else {
printf("loaded");
}
And got success ...!
----------------------
I also had found some interesting articles related to libtool , dlopen
and LoadLibrary API function
and thier behaviours under cygwin..
Probably this will help to solve problem soon.....
Well, if you will be more lucky in finding solution , just let me know
Ivan
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Thanks, Archie
That's exactly what I figured out yesterday...
Now HelloWord prints "HelloWorld"
But I have another problem .. After this VM do not exit.
Also simple thread with counter value print hangs after printing five values
If I put sleep in thread it hangs after printing first value...
No errors, no output, just stops without exiting...
It's probably related to my incorrect definition of
extern inline const void * _jc_jmpbuf_sp(const sigjmp_buf buf)
in file \jchevm\libjc\arch\i386\i386_libjc.h which I added few days
ago as cygwin specific branch.
If anybody have ideas about how this function must be difined correctly,
please, let me know.
Ivan
Archie Cobbs wrote:
> snowdosker wrote:
>
>>> Please share the link you've found :-)
>>
>>
>> Here is similar problem in postgress and some explanations
>> http://archives.postgresql.org/pgsql-cygwin/2003-11/msg00024.php
>
>
> I don't have Cygwin but it appears that something like the attached
> patch should work. If so let me know and I'll commit it.
>
> -Archie
>
> __________________________________________________________________________
>
> Archie Cobbs * CTO, Awarix *
> http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by Archie Cobbs <ar...@dellroad.org>.
snowdosker wrote:
>> Please share the link you've found :-)
>
> Here is similar problem in postgress and some explanations
> http://archives.postgresql.org/pgsql-cygwin/2003-11/msg00024.php
I don't have Cygwin but it appears that something like the attached
patch should work. If so let me know and I'll commit it.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by Archie Cobbs <ar...@dellroad.org>.
snowdosker wrote:
> Well one more question. In file jchevm\libjc\arch\i386\i386_libjc.h
> there wasn't branch for cygwin.... as result compilation failed with
> "Unsupported O/S for i386 machine context functions" message..
> Someway I defined this inline function _jc_jmpbuf_sp(const sigjmp_buf
> buf) but guess I did it wrong way.
> Do you know how to do it correctly?
You just have to figure out where the stack pointer is saved
in a sigjmp_buf and pull it out.
But in any case this function is only used for garbage collection.
If you avoid GC then it doesn't matter what this function
returns (except for the assertion in stack.c, which you can
disable).
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Hello, Enrico.
> great! I'll try it tomorrow on my PC.
> I think there are still quite a few things to fix on Cygwin,
> because, for example, if we enable the assertions, JCHEVM exits.
> The results we've got are encouraging though :-)
Unfortunately some things to fix remains.
For the moment I just checked very few basic things with JCHEVM
What I found is that simple thread print counter test do not work....
Well it starts and prints out 0,1,2,3,4 and then hang...
Hmmm... and VM do not exits after just very basic "hello word" test
also... Just "hang"
waiting for something..
Well one more question. In file jchevm\libjc\arch\i386\i386_libjc.h
there wasn't branch for cygwin.... as result compilation failed with
"Unsupported O/S for i386 machine context functions" message..
Someway I defined this inline function _jc_jmpbuf_sp(const sigjmp_buf
buf) but guess I did it wrong way.
Do you know how to do it correctly?
Ivan
Re: [jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
>>The cygwin.dll acts as an emulation layer for all those POSIX functions
>>that
>>Windows doesn't have. If a program doesn't call any of the functions
>>provided
>>by cygwin.dll, then, this library is not needed and, I guess, it's not
>>even loaded.
>>
>>GCC, when used on Cygwin, produces always a native executable file for
>>Windows, and
>>the extension is .exe.
>>
>>
>
>Actually you have a choice now. Cygwin gcc can build for cygwin.dll
>or, with "gcc -mno-cygwin", for the native msvcrt.dll. The latter
>does not require cygwin.dll.
>
>Regards,
> Mark.
>
>
Hi Mark,
thanks for pointing that out. I'll try to build JCHEVM with that option
enabled.
I figure that if I try to build a program that makes use of POSIX
functions,
with "gcc -mno-cygwin", there are two options:
1. Those functions will be embedded in the executable file (.exe)
2. GCC refuses to build
Enrico
Re: [jchevm] APR issues
Posted by Mark Hindess <ma...@googlemail.com>.
On 27/02/06, Enrico Migliore <en...@fatti.com> wrote:
> Hi,
>
> >> So what we'd need now is a mechanism to override
> >> the automatic choice of "platform". I wouldn't be too surprised if
> >> someone decided to create "platforms" for the other two (?) choices of
> >> windows implementation - cygwin native and cygwin w/o cygwin.dll.
> >>
> >>
> > ??? native windoze and cygwin, or do I miss something?
>
> The cygwin.dll acts as an emulation layer for all those POSIX functions
> that
> Windows doesn't have. If a program doesn't call any of the functions
> provided
> by cygwin.dll, then, this library is not needed and, I guess, it's not
> even loaded.
>
> GCC, when used on Cygwin, produces always a native executable file for
> Windows, and
> the extension is .exe.
Actually you have a choice now. Cygwin gcc can build for cygwin.dll
or, with "gcc -mno-cygwin", for the native msvcrt.dll. The latter
does not require cygwin.dll.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
Hi,
>> So what we'd need now is a mechanism to override
>> the automatic choice of "platform". I wouldn't be too surprised if
>> someone decided to create "platforms" for the other two (?) choices of
>> windows implementation - cygwin native and cygwin w/o cygwin.dll.
>>
>>
> ??? native windoze and cygwin, or do I miss something?
The cygwin.dll acts as an emulation layer for all those POSIX functions
that
Windows doesn't have. If a program doesn't call any of the functions
provided
by cygwin.dll, then, this library is not needed and, I guess, it's not
even loaded.
GCC, when used on Cygwin, produces always a native executable file for
Windows, and
the extension is .exe.
Enrico
Re: [jchevm] APR issues
Posted by Mark Hindess <ma...@googlemail.com>.
On 27/02/06, Jean-frederic Clere <jf...@gmail.com> wrote:
> Mark Hindess wrote:
>
> >On 27/02/06, Jean-frederic Clere <jf...@gmail.com> wrote:
> >
> >
> >>Geir Magnusson Jr wrote:
> >>
> >>
> >>>But that's way different than APR for the class lib portlib.
> >>>
> >>>
> >>So you have to create a apr.IA32 class lib, don't you?
> >>
> >>
> >
> >Well, that's what I was thinking - though I'm not so sure that $arch
> >should be something that specific.
> >
> >Initially at least I don't think we should be making a choice between
> >using apr.IA32 and writing platform specific natives. I think we
> >should continue with what we have until such a time that apr becomes
> >the better choice.
> >
> I am not sure that is the best idea.
> Apr prevents losing time writing code twice (or #defining everywhere)
> and that is a lot of work to APRized a project in late state.
> Starting with apr asap probably will break everything for some time but
> will spare a lot of time in future...
> The biggest problem is to have a graphical library that works with apr
> or that is written using apr.
I wasn't saying don't start an apr.$arch platform just don't make that
the only option. It should be developed in parallel. I don't see why
it should be any more difficult than developing the win.IA32 and
linux.IA32 in parallel has been?
> > So what we'd need now is a mechanism to override
> >the automatic choice of "platform". I wouldn't be too surprised if
> >someone decided to create "platforms" for the other two (?) choices of
> >windows implementation - cygwin native and cygwin w/o cygwin.dll.
> >
> ??? native windoze and cygwin, or do I miss something?
That should be sufficient, but I was making the additional distinction between
windows native built with nmake/MSVC (as we have today) and windows
native built with cygwin ("gmake/gcc -mno-cygwin"). These are
sufficiently different that if anyone wanted them today they'd
probably treat them as separate platforms until we get the natives in
a better state.
> >It might be useful to develop some tests to prove the natives for
> >platforms that don't yet have VM support.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [jchevm] APR issues
Posted by Jean-frederic Clere <jf...@gmail.com>.
Mark Hindess wrote:
>On 27/02/06, Jean-frederic Clere <jf...@gmail.com> wrote:
>
>
>>Geir Magnusson Jr wrote:
>>
>>
>>>But that's way different than APR for the class lib portlib.
>>>
>>>
>>So you have to create a apr.IA32 class lib, don't you?
>>
>>
>
>Well, that's what I was thinking - though I'm not so sure that $arch
>should be something that specific.
>
>Initially at least I don't think we should be making a choice between
>using apr.IA32 and writing platform specific natives. I think we
>should continue with what we have until such a time that apr becomes
>the better choice.
>
I am not sure that is the best idea.
Apr prevents losing time writing code twice (or #defining everywhere)
and that is a lot of work to APRized a project in late state.
Starting with apr asap probably will break everything for some time but
will spare a lot of time in future...
The biggest problem is to have a graphical library that works with apr
or that is written using apr.
> So what we'd need now is a mechanism to override
>the automatic choice of "platform". I wouldn't be too surprised if
>someone decided to create "platforms" for the other two (?) choices of
>windows implementation - cygwin native and cygwin w/o cygwin.dll.
>
>
??? native windoze and cygwin, or do I miss something?
>It might be useful to develop some tests to prove the natives for
>platforms that don't yet have VM support.
>
>Regards,
> Mark.
>
>--
>Mark Hindess <ma...@googlemail.com>
>IBM Java Technology Centre, UK.
>
>
>
Re: [jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
Hi,
>Initially at least I don't think we should be making a choice between
>using apr.IA32 and writing platform specific natives. I think we
>should continue with what we have until such a time that apr becomes
>the better choice.
>
I agree with you.
>So what we'd need now is a mechanism to override
>the automatic choice of "platform". I wouldn't be too surprised if
>someone decided to create "platforms" for the other two (?) choices of
>windows implementation - cygwin native and cygwin w/o cygwin.dll.
>
>It might be useful to develop some tests to prove the natives for
>platforms that don't yet have VM support.
>
>Regards,
> Mark.
>
>--
>Mark Hindess <ma...@googlemail.com>
>IBM Java Technology Centre, UK.
>
>
>
Enrico
Re: [jchevm] APR issues
Posted by Mark Hindess <ma...@googlemail.com>.
On 27/02/06, Jean-frederic Clere <jf...@gmail.com> wrote:
> Geir Magnusson Jr wrote:
> >
> > But that's way different than APR for the class lib portlib.
>
> So you have to create a apr.IA32 class lib, don't you?
Well, that's what I was thinking - though I'm not so sure that $arch
should be something that specific.
Initially at least I don't think we should be making a choice between
using apr.IA32 and writing platform specific natives. I think we
should continue with what we have until such a time that apr becomes
the better choice. So what we'd need now is a mechanism to override
the automatic choice of "platform". I wouldn't be too surprised if
someone decided to create "platforms" for the other two (?) choices of
windows implementation - cygwin native and cygwin w/o cygwin.dll.
It might be useful to develop some tests to prove the natives for
platforms that don't yet have VM support.
Regards,
Mark.
--
Mark Hindess <ma...@googlemail.com>
IBM Java Technology Centre, UK.
Re: [jchevm] Cygwin issues
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> > Archie Cobbs wrote:
> > Today I've made changes to eliminate the requirement that
> _JC_FULL_ALIGNMENT
> > be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
>
> hope that doesn't sacrifice any of the features of jchevm
Nope.. it's all gain and no pain :-)
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] Cygwin issues
Posted by snowdosker <sn...@academ.org>.
Hello Enrico,
I built JCHEVM with enabling assertions and merged latest Archie's fixes.
And now working on assertion
jc: assertion failure: _r == 0
jc: location: file `thread.c' line 1023
This assertion is the reason for simple thread test crash after few
itterations
Do you have any ideas how to fix this problem.
Thanks, Ivan.
Re: [jchevm] Cygwin issues
Posted by Enrico Migliore <en...@fatti.com>.
snowdosker wrote:
> Hello, Enrico
>
> 2) in order to proceed, let's "align" our development environment in
> terms
>
>> of source code modifications. In fact, to build jchevm, just like
>> you, I had
>> to add some declarations in some header files, and modify the pread()
>> call into a read(). My proposal is the following:
>> let's install the new versions of Cygwin, Classpath, and jchevm,
>> build them from scratch, produce a written document with all the steps
>> and modifications, and post it this mailing list.
>> Afterwards, we will be able to write and debug some test cases.
>>
>> what do you think?
>>
>
> I think that I already did this since started.. Just recorded all (or
> I hope all) I did
> Below is copy of my records....
>
>
> Install Cygwin (
> http://developer.classpath.org/mediation/ClasspathOnCygwin )
> + gcc-core
> + gcc-g++
> + gcc-java
> + make
> + zip
> + GTK
> + pkgconfig
> + autocofig
> + automake
> + libtool
> (not sure that I recorded all optional packages I installed)
>
>
> Download jikes from
> http://prdownloads.sourceforge.net/jikes/jikes-1.22.tar.bz2?download
>
> Apply this patch
> http://sourceforge.net/tracker/index.php?func=detail&aid=1202863&group_id=128803&atid=712760
>
>
>
> build jikes ( cygwin version )
> -----------------
> $ tar -xjf jikes-1.22.tar.bz2
> $ cd jikes-1.22
> $ ./configure
> $ make && make install
>
>
>
> Build Classpth-0.20
> -----------------
> $ ./configure --with-jikes --enable-gtk-peer --enable-jni
> $ make
> $install
>
>
> Build JCHEVM
> -----------------
> $ ./configure --with-classpath=/usr/local/classpath
> Add cache clean to autogen.sh before each call automake or autoconfig
> --
> rm -rf autom4te*.cache
> echo "running automake"
> ....
> rm -rf autom4te*.cache
> echo "running autoconf"
> ---
>
>
> libjc/definitions.h ADD
> --------------------
> #if defined (__CYGWIN__)
> #define PTHREAD_STACK_MIN 1024
> #endif
>
>
> libjc/properties.c ADD
> --------------------
> #if defined(__CYGWIN__)
> if (_jc_set_property(env,
> "user.timezone", _tzname[0]) != JNI_OK)
> return JNI_ERR;
> #else
>
> if (_jc_set_property(env,
> "user.timezone", localtime(&now)->tm_zone) != JNI_OK)
> return JNI_ERR;
> #endif
>
>
> libjc/os_functions.c ADD
> --------------------
> /************************************************************************
> * CYGWIN *
> ************************************************************************/
>
> #elif defined(__CYGWIN__)
>
> #include <unistd.h>
>
> int
> _jc_num_cpus(_jc_env *env)
> {
>
> return (int)sysconf(_SC_NPROCESSORS_ONLN);
> }
>
>
>
> in libjc/zip.c replace
> ---------------------------------
> pread(3) with lseek,read
>
>
> libjc/arch/arch_definitions.h
> -----------------------------------
> Remove:
> #define _JC_LIBRARY_FMT "lib%s.so"
>
> Add:
> #define _JC_LIBRARY_FMT "lib%s.dll.a"
>
>
>
> libjc/arch/i386/i386_libjc.h ( not sure for this is correct! )
> -------------------
> #elif defined(__CYGWIN__)
> extern inline const void *
> _jc_jmpbuf_sp(const sigjmp_buf buf)
> {
> return (const void *)buf[7];
> }
>
>
>
>
> libjc\native\java_lang_VMThread.c ADD
> --------------------------------------------
> /* Cygwin pthread_create() with supplied attributes is completely
> broken! */
> #ifdef __CYGWIN__
> #define _JC_NO_THREAD_ATTRIBUTES 1
> #endif
>
>
>
> libjc\jc_invoke.c
> ---------------------------------------------
> in "static const struct poptOption jc_popt_options[] = {" remove
> POPT_AUTOHELP
>
>
> in libjc\arch\arch_definitions.h
> redefine dll name format for cygwin
> --------------------------------
> #if defined(__CYGWIN__)
> #define _JC_LIBRARY_FMT "cyg%s-0.dll"
> #elif
> #define _JC_LIBRARY_FMT "lib%s.dll.a"
> #endif
Hi Ivan,
ok, in order to double check these guidelines, I'll do the whole
build from scratch and see if they lead me to the point where you are now.
I'll have the time to do it tomorrow or wednsday, though.
In the mean time, could you try to: apply the latest Archie's patch,
enable the assertions,
and see where jchevm exits?
Enrico
Re: [jchevm] APR issues
Posted by Jean-frederic Clere <jf...@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> Jean-frederic Clere wrote:
>
>> Geir Magnusson Jr wrote:
>>
>>>
>>>
>>> Tim Ellison wrote:
>>
>
>>>> No we didn't agree to do that Enrico, for the reasons I described
>>>> above.
>>>
>>>
>>>
>>> Just to reinforce... no, we didn't agree to that.
>>>
>>> I think that the notion leveraging APR for implementing the
>>> portability layer for the VM was what we didn't disagree on. ( I
>>> won't claim agreement...)
>>>
>>> But that's way different than APR for the class lib portlib.
>>
>>
>> So you have to create a apr.IA32 class lib, don't you?
>
>
> I think I don't understand the question.
>
> Yes, we can do an implementation using APR, but what I thought was
> driving this discussion was the idea that we could abandon portlib and
> tie everything directly to the APR API.
Ok, I understand better the idea: no apr portlib but everything in the
jchecvm.
>
> Using APR to implement the porting layer for the VM/classlib is just
> peachy - it saves us oodles of work.
>
> geir
>
>>
>> Cheers
>>
>> Jean-Frederic
>>
>>>
>>>
>>> geir
>>>
>>>>
>>>> Regards,
>>>> Tim
>>>>
>>>
>>
>>
>
>
Re: [jchevm] APR issues
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Jean-frederic Clere wrote:
> Geir Magnusson Jr wrote:
>
>>
>>
>> Tim Ellison wrote:
>>> No we didn't agree to do that Enrico, for the reasons I described above.
>>
>>
>> Just to reinforce... no, we didn't agree to that.
>>
>> I think that the notion leveraging APR for implementing the
>> portability layer for the VM was what we didn't disagree on. ( I
>> won't claim agreement...)
>>
>> But that's way different than APR for the class lib portlib.
>
> So you have to create a apr.IA32 class lib, don't you?
I think I don't understand the question.
Yes, we can do an implementation using APR, but what I thought was
driving this discussion was the idea that we could abandon portlib and
tie everything directly to the APR API.
Using APR to implement the porting layer for the VM/classlib is just
peachy - it saves us oodles of work.
geir
>
> Cheers
>
> Jean-Frederic
>
>>
>>
>> geir
>>
>>>
>>> Regards,
>>> Tim
>>>
>>
>
>
Re: [jchevm] APR issues
Posted by Jean-frederic Clere <jf...@gmail.com>.
Geir Magnusson Jr wrote:
>
>
> Tim Ellison wrote:
>
>> Enrico Migliore wrote:
>>
>>> Hi Tim,
>>>
>>>> Enrico Migliore wrote:
>>>>
>>>>
>>>>> Archie, Geir and Stefano,
>>>>>
>>>>> could you please take a look at the following assertion and
>>>>> correct it
>>>>> if it's wrong:
>>>>>
>>>>> It's worth to remember, that the goal of porting JCHEVM to
>>>>> Cygwin/Windows,
>>>>> is to enable us, and the people interested, to have a development
>>>>> environment on Windows,
>>>>> in order to start working on the APR.
>>>>>
>>>>
>>>> I'm not sure what you mean by 'in order to start working on the APR'?
>>>>
>>>>
>>>>
>>> I meant, modifying JCHEVM in order to call, where applicable, the APR
>>> functions.
>>>
>>>>> In principle, after adapting jchevm to the APR, jchevm will be
>>>>> buildable
>>>>> with:
>>>>>
>>>>> 1. GCC native - build on Linux an executable for Linux
>>>>> 2. GCC cross native - build on Linux an executable for Windows
>>>>> (without Cygwin)
>>>>> 3. MSVC native - build on Windows an executable for Windows
>>>>>
>>>>> The same thing applies to the Harmony Classlib
>>>>>
>>>>
>>>> The class library native code uses the Harmony portlib to access
>>>> much of
>>>> the OS-specific code covered in APR. Rather than rewrite those
>>>> natives,
>>>> and loose the additional characteristics of the portlib, it would make
>>>> more sense to implement the portlib on APR if that were desirable.
>>>>
>>>>
>>> I think I'm missing something: last week, we all agreed on "adopting"
>>> the APR library for the native
>>> stuff, except for the windowing subsystem. That means to me that all
>>> the
>>> functions of JCHEVM and the Harmony,
>>> that need to access an OS/platform service (filesystem, network, etc.)
>>> should call the APR library.
>>
>>
>> No we didn't agree to do that Enrico, for the reasons I described above.
>
>
> Just to reinforce... no, we didn't agree to that.
>
> I think that the notion leveraging APR for implementing the
> portability layer for the VM was what we didn't disagree on. ( I
> won't claim agreement...)
>
> But that's way different than APR for the class lib portlib.
So you have to create a apr.IA32 class lib, don't you?
Cheers
Jean-Frederic
>
>
> geir
>
>>
>> Regards,
>> Tim
>>
>
Re: [jchevm] APR issues
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Enrico Migliore wrote:
>> Hi Tim,
>>
>>> Enrico Migliore wrote:
>>>
>>>
>>>> Archie, Geir and Stefano,
>>>>
>>>> could you please take a look at the following assertion and correct it
>>>> if it's wrong:
>>>>
>>>> It's worth to remember, that the goal of porting JCHEVM to
>>>> Cygwin/Windows,
>>>> is to enable us, and the people interested, to have a development
>>>> environment on Windows,
>>>> in order to start working on the APR.
>>>>
>>> I'm not sure what you mean by 'in order to start working on the APR'?
>>>
>>>
>>>
>> I meant, modifying JCHEVM in order to call, where applicable, the APR
>> functions.
>>
>>>> In principle, after adapting jchevm to the APR, jchevm will be buildable
>>>> with:
>>>>
>>>> 1. GCC native - build on Linux an executable for Linux
>>>> 2. GCC cross native - build on Linux an executable for Windows
>>>> (without Cygwin)
>>>> 3. MSVC native - build on Windows an executable for Windows
>>>>
>>>> The same thing applies to the Harmony Classlib
>>>>
>>> The class library native code uses the Harmony portlib to access much of
>>> the OS-specific code covered in APR. Rather than rewrite those natives,
>>> and loose the additional characteristics of the portlib, it would make
>>> more sense to implement the portlib on APR if that were desirable.
>>>
>>>
>> I think I'm missing something: last week, we all agreed on "adopting"
>> the APR library for the native
>> stuff, except for the windowing subsystem. That means to me that all the
>> functions of JCHEVM and the Harmony,
>> that need to access an OS/platform service (filesystem, network, etc.)
>> should call the APR library.
>
> No we didn't agree to do that Enrico, for the reasons I described above.
Just to reinforce... no, we didn't agree to that.
I think that the notion leveraging APR for implementing the portability
layer for the VM was what we didn't disagree on. ( I won't claim
agreement...)
But that's way different than APR for the class lib portlib.
geir
>
> Regards,
> Tim
>
Re: [jchevm] APR issues
Posted by Tim Ellison <t....@gmail.com>.
Enrico Migliore wrote:
> Hi Tim,
>
>> Enrico Migliore wrote:
>>
>>
>>> Archie, Geir and Stefano,
>>>
>>> could you please take a look at the following assertion and correct it
>>> if it's wrong:
>>>
>>> It's worth to remember, that the goal of porting JCHEVM to
>>> Cygwin/Windows,
>>> is to enable us, and the people interested, to have a development
>>> environment on Windows,
>>> in order to start working on the APR.
>>>
>>
>> I'm not sure what you mean by 'in order to start working on the APR'?
>>
>>
>>
> I meant, modifying JCHEVM in order to call, where applicable, the APR
> functions.
>
>>> In principle, after adapting jchevm to the APR, jchevm will be buildable
>>> with:
>>>
>>> 1. GCC native - build on Linux an executable for Linux
>>> 2. GCC cross native - build on Linux an executable for Windows
>>> (without Cygwin)
>>> 3. MSVC native - build on Windows an executable for Windows
>>>
>>> The same thing applies to the Harmony Classlib
>>>
>>
>> The class library native code uses the Harmony portlib to access much of
>> the OS-specific code covered in APR. Rather than rewrite those natives,
>> and loose the additional characteristics of the portlib, it would make
>> more sense to implement the portlib on APR if that were desirable.
>>
>>
> I think I'm missing something: last week, we all agreed on "adopting"
> the APR library for the native
> stuff, except for the windowing subsystem. That means to me that all the
> functions of JCHEVM and the Harmony,
> that need to access an OS/platform service (filesystem, network, etc.)
> should call the APR library.
No we didn't agree to do that Enrico, for the reasons I described above.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jchevm] APR issues
Posted by Tim Ellison <t....@gmail.com>.
Archie Cobbs wrote:
> Enrico Migliore wrote:
>>> The class library native code uses the Harmony portlib to access much of
>>> the OS-specific code covered in APR. Rather than rewrite those natives,
>>> and loose the additional characteristics of the portlib, it would make
>>> more sense to implement the portlib on APR if that were desirable.
>>>
>> I think I'm missing something: last week, we all agreed on "adopting"
>> the APR library for the native
>> stuff, except for the windowing subsystem. That means to me that all
>> the functions of JCHEVM and the Harmony,
>> that need to access an OS/platform service (filesystem, network, etc.)
>> should call the APR library.
>
> I think you two are in heated agreement. There are two different
> things: jchevm and classlib. For jchevm, it makes sense to port it
> to APR directly. For classlib (i.e., classlib's native code), it makes
> sense to port classlib's "portlib" layer to APR, rather than discarding
> portlib.
I'd hope that jchevm would consider using the portlib too; I have good
reason to believe that the portlib is well suited to the needs of a VM
implementation ;-)
It will be interesting to see how Artem's experiments with APR work-out.
Regards,
Tim
--
Tim Ellison (t.p.ellison@gmail.com)
IBM Java technology centre, UK.
Re: [jchevm] APR issues
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
>> The class library native code uses the Harmony portlib to access much of
>> the OS-specific code covered in APR. Rather than rewrite those natives,
>> and loose the additional characteristics of the portlib, it would make
>> more sense to implement the portlib on APR if that were desirable.
>>
> I think I'm missing something: last week, we all agreed on "adopting"
> the APR library for the native
> stuff, except for the windowing subsystem. That means to me that all the
> functions of JCHEVM and the Harmony,
> that need to access an OS/platform service (filesystem, network, etc.)
> should call the APR library.
I think you two are in heated agreement. There are two different
things: jchevm and classlib. For jchevm, it makes sense to port it
to APR directly. For classlib (i.e., classlib's native code), it makes
sense to port classlib's "portlib" layer to APR, rather than discarding
portlib.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: [jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
Hi Tim,
>Enrico Migliore wrote:
>
>
>>Archie, Geir and Stefano,
>>
>> could you please take a look at the following assertion and correct it
>>if it's wrong:
>>
>>It's worth to remember, that the goal of porting JCHEVM to Cygwin/Windows,
>>is to enable us, and the people interested, to have a development
>>environment on Windows,
>>in order to start working on the APR.
>>
>>
>
>I'm not sure what you mean by 'in order to start working on the APR'?
>
>
>
I meant, modifying JCHEVM in order to call, where applicable, the APR
functions.
>>In principle, after adapting jchevm to the APR, jchevm will be buildable
>>with:
>>
>> 1. GCC native - build on Linux an executable for Linux
>> 2. GCC cross native - build on Linux an executable for Windows
>>(without Cygwin)
>> 3. MSVC native - build on Windows an executable for Windows
>>
>>The same thing applies to the Harmony Classlib
>>
>>
>
>The class library native code uses the Harmony portlib to access much of
>the OS-specific code covered in APR. Rather than rewrite those natives,
>and loose the additional characteristics of the portlib, it would make
>more sense to implement the portlib on APR if that were desirable.
>
>
I think I'm missing something: last week, we all agreed on "adopting"
the APR library for the native
stuff, except for the windowing subsystem. That means to me that all the
functions of JCHEVM and the Harmony,
that need to access an OS/platform service (filesystem, network, etc.)
should call the APR library.
>Regards,
>Tim
>
>
Enrico
Re: [jchevm] APR issues
Posted by Geir Magnusson Jr <ge...@pobox.com>.
Tim Ellison wrote:
> Enrico Migliore wrote:
>> Archie, Geir and Stefano,
>>
>> could you please take a look at the following assertion and correct it
>> if it's wrong:
>>
>> It's worth to remember, that the goal of porting JCHEVM to Cygwin/Windows,
>> is to enable us, and the people interested, to have a development
>> environment on Windows,
>> in order to start working on the APR.
>
> I'm not sure what you mean by 'in order to start working on the APR'?
I think I understand - right now, he can't compile.
Cygwin/WIndows will be good, as will the toolchain we are currently
using for the classlibrary, known as WTHWOTM "Whatever The Heck Was On
Tim's Machine"
>
>> In principle, after adapting jchevm to the APR, jchevm will be buildable
>> with:
>>
>> 1. GCC native - build on Linux an executable for Linux
>> 2. GCC cross native - build on Linux an executable for Windows
>> (without Cygwin)
>> 3. MSVC native - build on Windows an executable for Windows
>>
>> The same thing applies to the Harmony Classlib
>
> The class library native code uses the Harmony portlib to access much of
> the OS-specific code covered in APR. Rather than rewrite those natives,
> and loose the additional characteristics of the portlib, it would make
> more sense to implement the portlib on APR if that were desirable.
I can't begin to express how strongly I support this.
Use APR as a portability assist - we have the portlib interface that
serves the needs of the VM, and you can implement it quickly
(hopefully?) using APR. If not, then we have a good opportunity to
offer enhancements to APR.
geir
Re: [jchevm] APR issues
Posted by Tim Ellison <te...@apache.org>.
Enrico Migliore wrote:
> Archie, Geir and Stefano,
>
> could you please take a look at the following assertion and correct it
> if it's wrong:
>
> It's worth to remember, that the goal of porting JCHEVM to Cygwin/Windows,
> is to enable us, and the people interested, to have a development
> environment on Windows,
> in order to start working on the APR.
I'm not sure what you mean by 'in order to start working on the APR'?
> In principle, after adapting jchevm to the APR, jchevm will be buildable
> with:
>
> 1. GCC native - build on Linux an executable for Linux
> 2. GCC cross native - build on Linux an executable for Windows
> (without Cygwin)
> 3. MSVC native - build on Windows an executable for Windows
>
> The same thing applies to the Harmony Classlib
The class library native code uses the Harmony portlib to access much of
the OS-specific code covered in APR. Rather than rewrite those natives,
and loose the additional characteristics of the portlib, it would make
more sense to implement the portlib on APR if that were desirable.
Regards,
Tim
--
Tim Ellison (tellison@apache.org)
IBM Java technology centre, UK.
[jchevm] APR issues
Posted by Enrico Migliore <en...@fatti.com>.
Archie, Geir and Stefano,
could you please take a look at the following assertion and correct it
if it's wrong:
It's worth to remember, that the goal of porting JCHEVM to Cygwin/Windows,
is to enable us, and the people interested, to have a development
environment on Windows,
in order to start working on the APR.
In principle, after adapting jchevm to the APR, jchevm will be buildable
with:
1. GCC native - build on Linux an executable for Linux
2. GCC cross native - build on Linux an executable for Windows
(without Cygwin)
3. MSVC native - build on Windows an executable for Windows
The same thing applies to the Harmony Classlib
Enrico
Re: [jchevm] Cygwin issues
Posted by snowdosker <sn...@academ.org>.
Hello, Enrico
2) in order to proceed, let's "align" our development environment in terms
> of source code modifications. In fact, to build jchevm, just like you,
> I had
> to add some declarations in some header files, and modify the pread()
> call into a read(). My proposal is the following:
> let's install the new versions of Cygwin, Classpath, and jchevm,
> build them from scratch, produce a written document with all the steps
> and modifications, and post it this mailing list.
> Afterwards, we will be able to write and debug some test cases.
>
> what do you think?
>
I think that I already did this since started.. Just recorded all (or I
hope all) I did
Below is copy of my records....
Install Cygwin (
http://developer.classpath.org/mediation/ClasspathOnCygwin )
+ gcc-core
+ gcc-g++
+ gcc-java
+ make
+ zip
+ GTK
+ pkgconfig
+ autocofig
+ automake
+ libtool
(not sure that I recorded all optional packages I installed)
Download jikes from
http://prdownloads.sourceforge.net/jikes/jikes-1.22.tar.bz2?download
Apply this patch
http://sourceforge.net/tracker/index.php?func=detail&aid=1202863&group_id=128803&atid=712760
build jikes ( cygwin version )
-----------------
$ tar -xjf jikes-1.22.tar.bz2
$ cd jikes-1.22
$ ./configure
$ make && make install
Build Classpth-0.20
-----------------
$ ./configure --with-jikes --enable-gtk-peer --enable-jni
$ make
$install
Build JCHEVM
-----------------
$ ./configure --with-classpath=/usr/local/classpath
Add cache clean to autogen.sh before each call automake or autoconfig
--
rm -rf autom4te*.cache
echo "running automake"
....
rm -rf autom4te*.cache
echo "running autoconf"
---
libjc/definitions.h ADD
--------------------
#if defined (__CYGWIN__)
#define PTHREAD_STACK_MIN 1024
#endif
libjc/properties.c ADD
--------------------
#if defined(__CYGWIN__)
if (_jc_set_property(env,
"user.timezone", _tzname[0]) != JNI_OK)
return JNI_ERR;
#else
if (_jc_set_property(env,
"user.timezone", localtime(&now)->tm_zone) != JNI_OK)
return JNI_ERR;
#endif
libjc/os_functions.c ADD
--------------------
/************************************************************************
* CYGWIN *
************************************************************************/
#elif defined(__CYGWIN__)
#include <unistd.h>
int
_jc_num_cpus(_jc_env *env)
{
return (int)sysconf(_SC_NPROCESSORS_ONLN);
}
in libjc/zip.c replace
---------------------------------
pread(3) with lseek,read
libjc/arch/arch_definitions.h
-----------------------------------
Remove:
#define _JC_LIBRARY_FMT "lib%s.so"
Add:
#define _JC_LIBRARY_FMT "lib%s.dll.a"
libjc/arch/i386/i386_libjc.h ( not sure for this is correct! )
-------------------
#elif defined(__CYGWIN__)
extern inline const void *
_jc_jmpbuf_sp(const sigjmp_buf buf)
{
return (const void *)buf[7];
}
libjc\native\java_lang_VMThread.c ADD
--------------------------------------------
/* Cygwin pthread_create() with supplied attributes is completely broken! */
#ifdef __CYGWIN__
#define _JC_NO_THREAD_ATTRIBUTES 1
#endif
libjc\jc_invoke.c
---------------------------------------------
in "static const struct poptOption jc_popt_options[] = {" remove
POPT_AUTOHELP
in libjc\arch\arch_definitions.h
redefine dll name format for cygwin
--------------------------------
#if defined(__CYGWIN__)
#define _JC_LIBRARY_FMT "cyg%s-0.dll"
#elif
#define _JC_LIBRARY_FMT "lib%s.dll.a"
#endif
[jchevm] Cygwin issues
Posted by Enrico Migliore <en...@fatti.com>.
Hi Archie and Ivan,
> Archie Cobbs wrote:
> Today I've made changes to eliminate the requirement that
_JC_FULL_ALIGNMENT
> be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
hope that doesn't sacrifice any of the features of jchevm
> As for the failure to exit properly, this is probably related to the
> assertion on line 1023 of thread.c (which you said was failing in a
> previous email on Cygwin).
> This will take some further debugging.. there may be a bug in the
> handing of the "vm_destruction" condition variable but since I don't
> see the assertion it may be easier for you guys to debug it. I'll
> try a visual inspection though.
> -Archie
ok
> Ivan wrote:
> It's probably related to my incorrect definition of
>extern inline const void * _jc_jmpbuf_sp(const sigjmp_buf buf)
>in file \jchevm\libjc\arch\i386\i386_libjc.h which I added few days
>ago as cygwin specific branch.
>in order to proceed
Ivan,
1) I'd suggest you to set up the DDD visual debugger in order
to run step by step jchevm and use breakpoints. DDD works perfectly
on Cygwin: all you need to do is to install the X libraries, and from
a shell, run $startx and then, from the windows that appears, $ddd
2) in order to proceed, let's "align" our development environment in terms
of source code modifications. In fact, to build jchevm, just like you,
I had
to add some declarations in some header files, and modify the pread()
call into a read(). My proposal is the following:
let's install the new versions of Cygwin, Classpath, and jchevm,
build them from scratch, produce a written document with all the steps
and modifications, and post it this mailing list.
Afterwards, we will be able to write and debug some test cases.
what do you think?
Enrico
Re: [jchevm] runtime performance
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> I read an article that said that the performance of the SableVM, in
> terms of speed, was quite impressive.
> What's the difference between JCHEVM and the SableVM?
JCHEVM should be roughly the same speed as SableVM's "direct
intepreter" mode.. SableVM's "threaded interpreter" mode will
be somewhat faster, as it eliminates some of the "goto" overhead
assocated with each instruction.
All of the above is theoretical, the best answer of course is
to do some real benchmarking tests.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
[jchevm] runtime performance
Posted by Enrico Migliore <en...@fatti.com>.
Hi Ivan and Archie,
> After applying your fix it no more crashes.
> Just tested this with QuickSort algorithm. It's running OK. (but a
bit slow under cygwin in comparison to SUN's JVM under Win)
Great job!
>> JCHEVM will definitely be slower right now because there's no JIT
yet, i.e., it always operates in interpreter mode.
It would be interestesting to run the same test on Sun's JVM, configured
not to use the JIT (interpeted mode)
Archie:
I read an article that said that the performance of the SableVM, in
terms of speed, was quite impressive.
What's the difference between JCHEVM and the SableVM?
Enrico
Re: Classpath on Cygwin: failed to open native library error
Posted by Archie Cobbs <ar...@dellroad.org>.
snowdosker wrote:
> After applaing your fix it no more crashes.
Cool.
> Just tested this with QuickSort algorithm. It's running OK. (but a bit
> slow under cygwin in comparison to SUN's JVM under Win)
JCHEVM will definitely be slower right now because there's no JIT yet,
i.e., it always operates in interpreter mode.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Thanks, Archie.
After applaing your fix it no more crashes.
Just tested this with QuickSort algorithm. It's running OK. (but a bit
slow under cygwin in comparison to SUN's JVM under Win)
I will try some more sophisticated tests later.
Thanks again,
Ivan
Re: Classpath on Cygwin: failed to open native library error
Posted by Archie Cobbs <ar...@dellroad.org>.
snowdosker wrote:
>> This one is mysterious and will take some debugging by someone on
>> a Cygwin platform. I'd start by checking what "r" is (i.e., what's
>> the return value). Then try to come up with a simple test case
>> of a condition variable, etc.
>
> As I can check
> _r = 22 and vm->vm_destruction = 0
>
> According to docs 22 is EINVAL and |pthread_cond_signal returns when
> |
>
> [EINVAL] The value /cond/ does not refer to an initialised condition
> variable.
D'oh! This one is easy, we weren't initializing the condition variable.
Fixed in r381407.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Hello, Archie
> This one is mysterious and will take some debugging by someone on
> a Cygwin platform. I'd start by checking what "r" is (i.e., what's
> the return value). Then try to come up with a simple test case
> of a condition variable, etc.
As I can check
_r = 22 and vm->vm_destruction = 0
According to docs 22 is EINVAL and |pthread_cond_signal returns when
|
[EINVAL] The value /cond/ does not refer to an initialised condition
variable.
> Note condition variables are also used during garbage collection.
> What happens when you run a program that invokes System.gc() ?
Nothing new. Crashed at the same line of thread.c
> The other fixes you mention I've committed in r380969,
> except as noted below...
Thanks.
Ivan
Re: Classpath on Cygwin: failed to open native library error
Posted by Archie Cobbs <ar...@dellroad.org>.
snowdosker wrote:
> Still havn't solved problem with
> jc: assertion failure: _r == 0
> jc: location: file `thread.c' line 1023
> This one is the reason for simple thread test crash after few itterations
This one is mysterious and will take some debugging by someone on
a Cygwin platform. I'd start by checking what "r" is (i.e., what's
the return value). Then try to come up with a simple test case
of a condition variable, etc.
Note condition variables are also used during garbage collection.
What happens when you run a program that invokes System.gc() ?
The other fixes you mention I've committed in r380969,
except as noted below...
> 8. in libjc\zip.c pread(..) replaced with lseek + read calls
This "fix" is really a workaround that introduces a new race
condition (when two threads are reading from the same ZIP file
at the same time). More work is required, e.g., adding a mutex.
I'll add this to my list, or if you have a candidate patch email
it to me.
Cheers,
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Hello, Archie.
Thank you. Succesfully merged your changes and now everything looks better..
Still havn't solved problem with
jc: assertion failure: _r == 0
jc: location: file `thread.c' line 1023
This one is the reason for simple thread test crash after few itterations
Well after merging just compared differences of my local copy against
repository'
Just for your interest. This difference includes changes proposed by
you and Enrico.
1. in \libjc\arch\i386\i386_definitions.h this format differs.
#define _JC_LIBRARY_FMT "cyg%s-0.dll"
Probably because classpath while build in my case generates dll names
with major version number in name
2. in \libjc\arch\i386\i386_libjc.h I added this cygwin specific branch
#elif defined(__CYGWIN__)
extern inline const void *
_jc_jmpbuf_sp(const sigjmp_buf buf)
{
return (const void *)buf[7];
}
3. in \libjc\definitions.h added
#if defined (__CYGWIN__)
#define PTHREAD_STACK_MIN 1024
#endif
4. in \libjc\jc_invoke.c
in struct poptOption jc_popt_options[] = { .... }
commented out POPT_AUTOHELP
5. in \libjc\native\java_lang_VMThread.c added
/* Cygwin pthread_create() with supplied attributes is completely broken! */
#ifdef __CYGWIN__
#define _JC_NO_THREAD_ATTRIBUTES 1
#endif
6. in libjc\os_functions.c cygwin specific branch added
/************************************************************************
* CYGWIN *
************************************************************************/
#elif defined(__CYGWIN__)
#include <unistd.h>
int
_jc_num_cpus(_jc_env *env)
{
return (int)sysconf(_SC_NPROCESSORS_ONLN);
}
7. in libjc/properties.c cygwin specific branch added so Set user
timezone block now looks as :
/* Set user timezone */
now = time(NULL);
#if defined(__CYGWIN__)
if (_jc_set_property(env,
"user.timezone", _tzname[0]) != JNI_OK)
return JNI_ERR;
#else
if (_jc_set_property(env,
"user.timezone", localtime(&now)->tm_zone) != JNI_OK)
return JNI_ERR;
#endif
8. in libjc\zip.c pread(..) replaced with lseek + read calls
Thanks
Ivan
Re: Classpath on Cygwin: failed to open native library error
Posted by Archie Cobbs <ar...@dellroad.org>.
snowdosker wrote:
>>>> Today I've made changes to eliminate the requirement that
>>>> _JC_FULL_ALIGNMENT
>>>> be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
>>>
>>> Just compared my local version with svn repository at Harmony project..
>>> Don't see any changes.
>>> Do you commit this changes in JCVM repository ?
>>
>> Yes, r378953.
>
> Sorry for bothering you. This number is something not very clear for me.
> I'm not guru in CVS but I just checkouted latest JCVM from
> sourceforge ...latest modifications dates are
> 21.01.2006 How and where can I get diff for this changes to apply it for
> my local JCHEVM installation ?
You seem to be checking out JCVM, which is not the same as JCHEVM.
You need to use Subversion (not CVS) for JCHEVM and point it at
https://svn.apache.org/repos/asf/incubator/harmony/enhanced/jchevm
> Also.. today started working on assertions..
> This one in vm.c under cygwin
> JC_ASSERT(vm->threads.prio_min <= vm->threads.prio_max);
> caused by a bit strange implementation of * *sched.cc on cygwin
> (source can be found here:
> http://www.koders.com/cpp/fidFCD804607170E62E066B115DCE4FCB2BEA405E30.aspx
> )
> All functions operates (accept as params and returns) with unix-like
> thread priorities, mapping it to reverse windows style priorities.
> But for some strange reason sched_get_priority_max (int policy) and
> sched_get_priority_min (int policy) return windows style
> reverse priorities from 15(min) to -14(max)
> Just defined wrapping functions in i386_libjc.h and used these
> functions instead of original ones.
Can you report this bug back to the Cygwin developers?
I checked in a version of your fix as r379838.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Hello, Archie
> snowdosker wrote:
>
>>> Today I've made changes to eliminate the requirement that
>>> _JC_FULL_ALIGNMENT
>>> be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
>>
>>
>> Just compared my local version with svn repository at Harmony project..
>> Don't see any changes.
>> Do you commit this changes in JCVM repository ?
>
>
> Yes, r378953.
Sorry for bothering you. This number is something not very clear for me.
I'm not guru in CVS but I just checkouted latest JCVM from
sourceforge ...latest modifications dates are
21.01.2006
How and where can I get diff for this changes to apply it for my local
JCHEVM installation ?
Also.. today started working on assertions..
This one in vm.c under cygwin
JC_ASSERT(vm->threads.prio_min <= vm->threads.prio_max);
caused by a bit strange implementation of * *sched.cc on cygwin
(source can be found here:
http://www.koders.com/cpp/fidFCD804607170E62E066B115DCE4FCB2BEA405E30.aspx )
All functions operates (accept as params and returns) with unix-like
thread priorities, mapping it to reverse windows style priorities.
But for some strange reason sched_get_priority_max (int policy) and
sched_get_priority_min (int policy) return windows style
reverse priorities from 15(min) to -14(max)
Just defined wrapping functions in i386_libjc.h and used these
functions instead of original ones.
This helps.
------------------------------------------------
#if defined(__CYGWIN__)
extern inline int _jc_sched_get_priority_max(int policy){
if (policy < 1 || policy > 3) {
set_errno (EINVAL);
return -1;
}
return 15;
}
extern inline int _jc_sched_get_priority_min(int policy){
if (policy < 1 || policy > 3) {
set_errno (EINVAL);
return -1;
}
return 1;
}
#else
extern inline int _jc_sched_get_priority_max(int policy){
return sched_get_priority_max(policy);
}
extern inline int _jc_sched_get_priority_min(int policy){
return sched_get_priority_min(policy);
}
#endif
------------------------------------------------
The next assertion which stopped me is one in heap.c
_JC_ASSERT(bs->hint == NULL || (((_jc_word)bs->hint &
(_JC_PAGE_SIZE - 1)) % bs->size) == _JC_HEAP_BLOCK_OFFSET);
Guess the one you was talking about...
Anyway some info which may be someway helpful with this assertion. I
just printout values
(_jc_word)bs->hint = 0
(_JC_PAGE_SIZE - 1) = 4095
bs->size = 24
_JC_HEAP_BLOCK_OFFSET = 8
Thank you, Ivan
Re: Classpath on Cygwin: failed to open native library error
Posted by Archie Cobbs <ar...@dellroad.org>.
snowdosker wrote:
>> Today I've made changes to eliminate the requirement that
>> _JC_FULL_ALIGNMENT
>> be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
>
> Just compared my local version with svn repository at Harmony project..
> Don't see any changes.
> Do you commit this changes in JCVM repository ?
Yes, r378953.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Hello, Archie
> Today I've made changes to eliminate the requirement that
> _JC_FULL_ALIGNMENT
> be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
Just compared my local version with svn repository at Harmony project..
Don't see any changes.
Do you commit this changes in JCVM repository ?
Thanks. Ivan
Re: Classpath on Cygwin: failed to open native library error
Posted by Archie Cobbs <ar...@dellroad.org>.
Enrico Migliore wrote:
> great! I'll try it tomorrow on my PC.
> I think there are still quite a few things to fix on Cygwin,
> because, for example, if we enable the assertions, JCHEVM exits.
> The results we've got are encouraging though :-)
>
> Archie: what are we supposed to do now?
Today I've made changes to eliminate the requirement that _JC_FULL_ALIGNMENT
be at most sizeof(_jc_word), so this will fix the assertion in heap.c.
As for the failure to exit properly, this is probably related to the
assertion on line 1023 of thread.c (which you said was failing in a
previous email on Cygwin).
This will take some further debugging.. there may be a bug in the
handing of the "vm_destruction" condition variable but since I don't
see the assertion it may be easier for you guys to debug it. I'll
try a visual inspection though.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
Re: Classpath on Cygwin: failed to open native library error
Posted by Enrico Migliore <en...@fatti.com>.
snowdosker wrote:
> Hi, Enrico
>
> Finally HelloWorld is working!
>
> in libjc\arch\arch_definitions.h
> redefine dll name format for cygwin
> --------------------------------
> #if defined(__CYGWIN__)
> #define _JC_LIBRARY_FMT "cyg%s-0.dll"
> #elif
> #define _JC_LIBRARY_FMT "lib%s.dll.a"
> #endif
>
> Hmm but jc do not exit after executing....
> I do not call System.exit in my test class, but Sun's java exit
> without it ok.
Hello Ivan,
great! I'll try it tomorrow on my PC.
I think there are still quite a few things to fix on Cygwin,
because, for example, if we enable the assertions, JCHEVM exits.
The results we've got are encouraging though :-)
Archie: what are we supposed to do now?
Two weeks ago, we spoke about using the APR for the
C code of Classlib and JHHEVM
Enrico
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Hi, Enrico
Finally HelloWorld is working!
in libjc\arch\arch_definitions.h
redefine dll name format for cygwin
--------------------------------
#if defined(__CYGWIN__)
#define _JC_LIBRARY_FMT "cyg%s-0.dll"
#elif
#define _JC_LIBRARY_FMT "lib%s.dll.a"
#endif
Hmm but jc do not exit after executing....
I do not call System.exit in my test class, but Sun's java exit without
it ok.
Re: Classpath on Cygwin: failed to open native library error
Posted by snowdosker <sn...@academ.org>.
Hi, Enrico
> Please share the link you've found :-)
Here is similar problem in postgress and some explanations
http://archives.postgresql.org/pgsql-cygwin/2003-11/msg00024.php
Also from reply adressed to you (?)
http://permalink.gmane.org/gmane.comp.java.classpath.devel/7260
See last paragraph.
And set of links on th same problem with dlopen on cygwin from Felix
which may be usefull
http://pnkfif.blogspot.com/2005/05/dlopen-on-win32.html
Re: Classpath on Cygwin: failed to open native library error
Posted by Enrico Migliore <en...@fatti.com>.
snowdosker wrote:
> Hi, Enrico.
>
> Just figured out the roots of the problem. It comes from dlopen()
> function on cygwin.
> *JCHEVM* use the following code for loading native shared libraries
> in \cygwin\home\ivan\jchevm\libjc\native_lib.c line:330
>
> else if ((handle = dlopen(dlname, RTLD_NOW)) == NULL) {
> _JC_EX_STORE(env, UnsatisfiedLinkError,
> "failed to open native library `%s': %s", name, dlerror());
> goto fail;
> }
>
> Exactly what we see in error output....
> So I just wrote simple test
>
> if ((handle =
> dlopen("/usr/local/classpath/lib/classpath/*libjavanio.dll.a*",
> RTLD_NOW)) == NULL) {
> printf("fail %s", dlerror()); }
> else {
> printf("loaded");
> }
>
> And it's failed
> Well, then I tried to
>
> if ((handle =
> dlopen("/usr/local/classpath/lib/classpath/*cygjavanio-0.dll*",
> RTLD_NOW)) == NULL) {
> printf("fail %s", dlerror()); }
> else {
> printf("loaded");
> }
>
> And got success ...!
> ----------------------
>
> I also had found some interesting articles related to libtool , dlopen
> and LoadLibrary API function
> and thier behaviours under cygwin..
> Probably this will help to solve problem soon.....
> Well, if you will be more lucky in finding solution , just let me know
>
> Ivan
Hi Ivan,
good boy!
Let's browse the Cygwin documentation and see how dlopen() works.
Please share the link you've found :-)
dlopen() is a POSIX function.
Enrico