harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ligang Wang" <wanglg9...@gmail.com>
Subject Re: [general] How to deal with global/static variables in a static library while linking?
Date Wed, 03 Sep 2008 06:58:35 GMT
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.

Thanks for your attention.

Regards,
Ligang


On 9/3/08, Ligang Wang <wanglg9711@gmail.com> wrote:
>
> As we expected, the separate DLL way works. Well, there is a subtle problem
> left. The new DLL is copied into ${deploy}\jdk\jre\bin\default directory.
> java.exe couldn't be lanched unless I copy the new DLL into
> ${deploy}\jdk\jre\bin. The prompt shows: "This application has failed to
> start because xx.dll was not found. Re-installing the application may fix
> this problem." It seems the implicit loading of the new DLL failed because
> the loader couldn't find the right path for the new DLL. Did I miss
> something such as specifying the path? Thanks in advance.
>
> Regards,
> Ligang
>
>
>  On 9/1/08, Ilya Berezhniuk <ilya.berezhniuk@gmail.com> wrote:
>>
>> BTW, while implementing 'separate DLL' way on Linux, I observed
>> another difficult problem.
>> HyThr shared library which used this 'single-instance DLL' is loaded
>> twice - by launcher when initializing HyPort; and after fork()
>> performed to set LD_LIBRARY_PATH - by the VM.
>>
>> The problem appeared because this 'single-instance DLL' cannot be
>> found by LD before setting up LD_LIBRARY_PATH, so current ugly
>> solution is the following:
>> - 'single-instance DLL' functions are accessed manually with dlopen/dlsym;
>> - when these functions cannot be resolved (first HyThr instance before
>> forking), all operations requiring these functions are simply omitted.
>>
>>
>> 2008/9/1 Ligang Wang <wanglg9711@gmail.com>:
>> > Pavel and Chunrong, thanks to both of you.
>> >
>> > Making this "var" in a separate DLL should have no problem. I will try
>> this
>> > method.
>> >
>> > Regards,
>> > Ligang
>> >
>> >
>> > On 9/1/08, Pavel Pervov <pmcfirst@gmail.com> wrote:
>> >>
>> >> What Chunrong proposes is implementation specific.
>> >>
>> >> The only correct way is to have this "var" in a separate DLL. That is
>> >> why port_ch was separated from static part of port library - it has
>> >> data shared across different dynamic libraries.
>> >>
>> >> WBR,
>> >>    Pavel.
>> >>
>> >> On Mon, Sep 1, 2008 at 6:06 AM, Ligang Wang <wanglg9711@gmail.com>
>> wrote:
>> >> > Hi, all,
>> >> >
>> >> >
>> >> > I encountered a problem after adding some code into DRLVM. The
>> following
>> >> is
>> >> > a simplified example for the problem:
>> >> >
>> >> > In static library A, there is a header file A.h and a C file A.c.
>> >> >
>> >> >
>> >> > In A.h:
>> >> > extern function1();
>> >> >
>> >> >
>> >> > In A.c:
>> >> >
>> >> > (static) var;   // a static or global variable
>> >> >
>> >> > Function1()
>> >> >
>> >> > {
>> >> >
>> >> > ……
>> >> >
>> >> > Function2();
>> >> >
>> >> > ……
>> >> >
>> >> > }
>> >> >
>> >> > Function2()
>> >> >
>> >> > {
>> >> >
>> >> > Access var;
>> >> >
>> >> > }
>> >> >
>> >> >
>> >> >
>> >> > Several DLLs include A.h and call function1. And the final executable
>> >> uses
>> >> > all these DLLs.
>> >> >
>> >> >
>> >> >
>> >> > The question here is, will each DLL allocate a memory unit for var?
>> And
>> >> what
>> >> > memory address will each DLL reference for var? Is there any
>> difference
>> >> > between the static case and global case for the memory allocation
>> >> problem?
>> >> >
>> >> >
>> >> > Actually in Harmony library A is the port module and those DLLs stand
>> for
>> >> > vmcore, gc_gen, JNI, etc. While debugging I found that a static
>> variable
>> >> I
>> >> > defined in the port module has different addresses when accessed from
>> >> > different DLLs. Changing it to a global variable has no impact on
>> this.
>> >> >
>> >> > Anyone can help me? Thanks in advance.
>> >> >
>> >> > Regards,
>> >> > Ligang
>> >> >
>> >>
>> >
>>
>>
>>
>> --
>> Ilya.
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message