I fail to load the shared library created in a specific situation, but I do not know the cause.

---- a.d
import b.d
----

---- b.d
static this() {}
----

for above 2 files, I created shared library by following command.

dmd a.d -shared -of=a.so

And I ran below code, but the library is not loaded.

--- main.d
void main() {
    import core.runtime;
    auto lib = Runtime.loadLibrary(a.so)
    assert(lib !is null);
}
---

Please tell me why. Thanks.

On Friday, 22 March 2019 at 10:51:58 UTC, Sobaya wrote:
> I fail to load the shared library created in a specific situation, but I do not know the cause.
>
> ---- a.d
> import b.d
> ----
>
> ---- b.d
> static this() {}
> ----
>
> for above 2 files, I created shared library by following command.
>
> dmd a.d -shared -of=a.so
>
> And I ran below code, but the library is not loaded.
>
> --- main.d
> void main() {
>     import core.runtime;
>     auto lib = Runtime.loadLibrary(a.so)
>     assert(lib !is null);
> }
> ---
>
> Please tell me why. Thanks.

As far as I know different to windows, linus will not search current working directory for a.so. if this is the issue here, you have different possibilities. You could determine the current working directory and use std.path: buildPath to create an absolute path to a.so.
This path you can then use for Runtime.loadLibrary.

Or you can set the environment variable LD_LIBRARY_PATH.

I do not know what is the correct way on linux.

Kind regards
Andre

On Friday, 22 March 2019 at 11:00:32 UTC, Andre Pany wrote:
> On Friday, 22 March 2019 at 10:51:58 UTC, Sobaya wrote:
>> [...]
>
> As far as I know different to windows, linus will not search current working directory for a.so. if this is the issue here, you have different possibilities. You could determine the current working directory and use std.path: buildPath to create an absolute path to a.so.
> This path you can then use for Runtime.loadLibrary.
>
> Or you can set the environment variable LD_LIBRARY_PATH.
>
> I do not know what is the correct way on linux.
>
> Kind regards
> Andre

This is not a problem of path, I think.

Because when I do not write static constructor in b.d, that code works.

This problem occurs only when static constructor is used.

On Friday, 22 March 2019 at 17:52:34 UTC, Sobaya wrote:
> On Friday, 22 March 2019 at 11:00:32 UTC, Andre Pany wrote:
>> On Friday, 22 March 2019 at 10:51:58 UTC, Sobaya wrote:
>>> [...]
>>
>> As far as I know different to windows, linus will not search current working directory for a.so. if this is the issue here, you have different possibilities. You could determine the current working directory and use std.path: buildPath to create an absolute path to a.so.
>> This path you can then use for Runtime.loadLibrary.
>>
>> Or you can set the environment variable LD_LIBRARY_PATH.
>>
>> I do not know what is the correct way on linux.
>>
>> Kind regards
>> Andre
>
> This is not a problem of path, I think.
>
> Because when I do not write static constructor in b.d, that code works.
>
> This problem occurs only when static constructor is used.

Did you noticed this thread?
https://forum.dlang.org/post/eumnxgxtjrvvkhxpwjug@forum.dlang.org

The author has an example for shared static this and it seems it works for him although he has some other issues with gc.

Kind regards
Andre

On Saturday, 23 March 2019 at 09:37:16 UTC, Andre Pany wrote:
> On Friday, 22 March 2019 at 17:52:34 UTC, Sobaya wrote:
>> On Friday, 22 March 2019 at 11:00:32 UTC, Andre Pany wrote:
>>> On Friday, 22 March 2019 at 10:51:58 UTC, Sobaya wrote:
>>>> [...]
>>>
>>> As far as I know different to windows, linus will not search current working directory for a.so. if this is the issue here, you have different possibilities. You could determine the current working directory and use std.path: buildPath to create an absolute path to a.so.
>>> This path you can then use for Runtime.loadLibrary.
>>>
>>> Or you can set the environment variable LD_LIBRARY_PATH.
>>>
>>> I do not know what is the correct way on linux.
>>>
>>> Kind regards
>>> Andre
>>
>> This is not a problem of path, I think.
>>
>> Because when I do not write static constructor in b.d, that code works.
>>
>> This problem occurs only when static constructor is used.
>
> Did you noticed this thread?
> https://forum.dlang.org/post/eumnxgxtjrvvkhxpwjug@forum.dlang.org
>
> The author has an example for shared static this and it seems it works for him although he has some other issues with gc.
>
> Kind regards
> Andre

I read his code(https://github.com/tchaloupka/dlangsharedlib).

But in his code the static constructor is written directly in worker.d.
Such code works just fine with me.

What I am saying is that it can not be read when a code importing (a.d) a code including the static constructor (b.d)  is compiled into shared library.

On Saturday, 23 March 2019 at 15:58:07 UTC, Sobaya wrote:
> What I am saying is that it can not be read when a code importing (a.d) a code including the static constructor (b.d)  is compiled into shared library.

Hi. I've tried to add your case to the repository and at it seems to be working for me.
At least with dmd-2.085.0.

When run with `make dynamicd`:

```
main shared static this
+main()
utils shared static this
worker shared static this
libworker.so is loaded
entry_point1() function is found
entry_point2() function is found
...
-main()
unloading libworker.so
worker shared static ~this
utils shared static ~this
main shared static ~this
```

On Saturday, 23 March 2019 at 16:56:28 UTC, tchaloupka wrote:
> On Saturday, 23 March 2019 at 15:58:07 UTC, Sobaya wrote:
>> What I am saying is that it can not be read when a code importing (a.d) a code including the static constructor (b.d)  is compiled into shared library.
>
> Hi. I've tried to add your case to the repository and at it seems to be working for me.
> At least with dmd-2.085.0.
>
> When run with `make dynamicd`:
>
> ```
> main shared static this
> +main()
> utils shared static this
> worker shared static this
> libworker.so is loaded
> entry_point1() function is found
> entry_point2() function is found
> ...
> -main()
> unloading libworker.so
> worker shared static ~this
> utils shared static ~this
> main shared static ~this
> ```

I understand the cause.
Solved by passing b.d to dmd.
Sorry for the stupid question.