Libraries installed on windows do not have expected symbols

[brson]

From ssylvan:

Consider this a very preliminary bug report, I only gave it about two
minutes because I have to run, so I could probably track this down
further with some process monitor logging. In case this is useful as
is I'll just tell you here.

On 64-bit Windows 8 RTM I get this in a message box when running the
executable produced by compiling the example on rust-lang.org.

---------------------------
helloworld.exe - Entry Point Not Found
---------------------------
The procedure entry point
_ZN4rand14__extensions__10meth_1235514gen_uint_range17_be256aac3933fdb73_04E
could not be located in the dynamic link library
D:\Programming\rust\helloworld.exe.

[ssylvan]

I do have the rust bin directory on my path. Here's the procmon log file from running helloworld.exe. It contains stack traces for each event, but not sure how to resolve the symbols for rust binaries (I did resolve the windows ones though). http://sdrv.ms/O95Jji
Message box show up right before the "thread exit" event at 19:17:06.3715866.

This doesn't tell me much, but should at least give you an idea what dlls are loaded etc.

[bilalhusain]

The size of core-c3ca5d77d81b46c1-0.4.dll is different in bin\ and bin\rustc\i686-pc-mingw32\bin.

As mentioned, compiling works find, but running the executable requires the library at the later path, i.e., one of the ways to solve is to copy the dll at the later path to the current directory or add the later path to the environment variable PATH before the path of rustc.exe

(64-bit Windows 7 machine here)

[ssylvan]

I can confirm that manually adding the latter path before the former does fix it. Kind of annoying to need two entries in the PATH.

[brson]

Oh, that's interesting and unfortunate. I can see how that might happen, as those two directories are built by different rustc's during different stages of compilation. The exact reasoning is complicated, but we count on these two binaries being identical but there's a chance that they aren't because of bootstrapping problems. If we built all the way through stage3 it probably wouldn't be a problem, but I believe we stop at stage2 these days.

I've rolled a new installer that uses a more recent snapshot and tested it here on Win7 and I don't see the problem with core having different sizes. Sadly I overwrote the one that was exhibiting this issue before testing it myself.

http://dl.rust-lang.org/dist/rust-0.4-install.exe

[brson]

Now when I try it with the current exe I get this procedure entry point error on win 7.

[brson]

I think the short term solution is to make sure we do the release after a snapshot and test that this works.

[graydon]

For a given release, we will test this doesn't occur; in 0.6 or 0.7 (whenever the driver is rewritten) we should try hard to ensure this does not resurface.

[ghost]

If you're setting your PATH through the "System Properties" dialog, you will want to add it to the system variables not the user variables. When I put it the 2nd directory in the user PATH, it wouldn't pick up the .dll. (I'm on Windows 8, for what it's worth.)

[catamorphism]

This is critical for 0.6. We need to test this once we have a snapshot.

[catamorphism]

@brson Do you know if this is still an issue?

[emberian]

This is still an issue.

[metajack]

Triage bump.

[vadimcn]

I would guess that the wrong directory was on the PATH - i.e. %rust%\bin, instead of %rust%\bin\rustc\i686-pc-mingw32\bin. Back then stage1- and stage2-compiled libraries were not binary-compatible. This should not be a problem anymore.

[ScatteredRay]

Any word on this issue so far?

[emberian]

@Arelius are you hitting this?

[ScatteredRay]

Sorry, false alarm, My issue was actually unrelated.

[steveklabnik]

It's been almost a year, and "this shouldn't be an issue anymore." If anyone is still seeing this, please let me know, closing until we know this is true.