Re: [general] How to deal with global/static variables in a static library while linking?

[Mark Hindess <ma...@googlemail.com>]

In message <10...@mail.gmail.com>,
"Ligang Wang" writes:
> 
> This problem has been solved. I found that java.exe depends on
> hythr.dll and hythr.dll depends on the new DLL. The cause of
> the problem is that hythr.dll has specified to be copied into
> ${deploy}\jdk\jre\bin while the new DLL has not. So I just modified
> the configuration file to copy the new DLL.

This is still a problem.  VM-specific files should be stored in a subdirectory
of jre/bin to avoid conflicts if multiple VMs are installed.

-Mark.

Re: [general] How to deal with global/static variables in a static library while linking?

[Mark Hindess <ma...@googlemail.com>]

In message <10...@mail.gmail.com>,
"Ligang Wang" writes:
>
> Mark, thanks for your reminder. It seems there is still a problem here
> as you said. Do you know how hythr.dll deals with this problem? I saw
> there are also some global variables like group_list in its code. Will
> it be shared among multiple VMs? I guess it is not, but I have to
> figure it out.

I'm not sure considering hythr.dll is the right way to solve it.
There are outstanding issues with the hythr library.  Early in
the project the thread library was part of classlib (and still is
by default although drlvm doesn't use that version).  Experience
taught us that this was really not the right place for it.  A
clean API similar to the classlib portlib api was produced in
https://issues.apache.org/jira/browse/HARMONY-3090

When the -Dhy.no.thr=true option is supplied to the classlib build
a stub hythr dll is built that is replaced by the vm (in the vm
subdirectory of jre/bin) and the launcher is modified to find and load
it.

I think that modifying the drlvm hythr to support this api would be the
cleanest solution.

-Mark.

Re: [general] How to deal with global/static variables in a static library while linking?

[Ligang Wang <wa...@gmail.com>]

Mark, thanks for your reminder. It seems there is still a problem here as
you said. Do you know how hythr.dll deals with this problem? I saw there are
also some global variables like group_list in its code. Will it be shared
among multiple VMs? I guess it is not, but I have to figure it out.

Thanks,
Ligang


On 9/3/08, Mark Hindess <ma...@googlemail.com> wrote:
>
>
> In message <10...@mail.gmail.com>,
> "Ligang Wang" writes:
> >
> > This problem has been solved. I found that java.exe depends on
> > hythr.dll and hythr.dll depends on the new DLL. The cause of
> > the problem is that hythr.dll has specified to be copied into
> > ${deploy}\jdk\jre\bin while the new DLL has not. So I just modified
> > the configuration file to copy the new DLL.
>
> This is still a problem.  VM-specific files should be stored in a
> subdirectory
> of jre/bin to avoid conflicts if multiple VMs are installed.
>
> -Mark.
>
>
>