ctor does not work on a cdylib when the "associated" executable is called from the second parent directory

[DasStone]

Platform Information (x86-64)

• The bug occurs on Windows (Tested on Windows 11 Pro 22H2)
• The bug does not occur on Linux (Tested on Ubuntu 22.04 running in WSL)
• Information on other Platforms not available

Bug Description

I currently have a rust library (crate-type = ["cdylib"]). Let's say, for sake of argument, that I have an executable foo.exe that relies on some of the libraries functions.

Our hypothetical foo.exe resides in this example location: game\build\windows\foo.exe (The Library is in the same directory).

The [ctor] Function will not be called, when foo.exe is invoked from the "parent parent" (i.e. game) Directory.

Running .\build\windows\foo.exe from within the game Directory does not work. It works however from every other location (afaik).

The [ctor] is basically doing nothing:

#[ctor]
fn entry() {
    println!("ctor");
}

[mmastrac]

Interesting -- would the same binaries behave differently depending on the relative locations from which they are invoked? ie: if you provided a parameter to foo.exe to DllOpen the cdylib from different dirs, does it work in one location and not another?

[mmastrac]

I found some interesting discussion that might be related: https://devblogs.microsoft.com/cppblog/new-compiler-warnings-for-dynamic-initialization/

[mmastrac]

I made a small change in 0.2.4 which might help here -- see if that works for you

[DasStone]

Thank you for the replies!

Interesting -- would the same binaries behave differently depending on the relative locations from which they are invoked? ie: if you provided a parameter to foo.exe to DllOpen the cdylib from different dirs, does it work in one location and not another?

I will write a followup comment when I find the time to test this.

I made a small change in 0.2.4 which might help here -- see if that works for you

Sadly the problem still persists.

[DasStone]

Hello again,

I have found the Problem myself. Luckily it has nothing to do with the ctor crate (Sorry for creating this issue, but I thought it would be better just in case if this was a crate issue).

What caused the Problem

I have a rather big build directory for a game I'm currently working on. Some of the game code is written in Rust and packed within a library. This library has some pretty big differences between debug and release (due to various reasons). The ctor function should handle some release specific code, hence the contents of the ctor function aren't available in debug builds.

Windows seems to not know where the .dll is supposed to be, when the program is started. It appears that then a search (originating from the current path) is started in order to find a matching library (the debug and release versions are ABI compatible). When I was inside the parent parent directory of the game build, the windows search seemed to always find a debug version first. This was something I did not anticipate. This of course resulted in the ctor seemingly not working correctly (because it was from a different build). Why Windows was able to find a correct version of the .dll when running the program from the parent parent parent Directory is absolutely beyond me (nothing related to this project is in this directory or in any of it's other sub-directories).

This does not happen on linux, seemingly due to a much more robust handling of .so files.

The Problem seems rather obvious in Hindsight... (but Hindsight is always 20/20)

Thank you again @mmastrac for your time!