Libraries installed on windows do not have expected symbols #3660

Closed
brson opened this Issue Oct 4, 2012 · 17 comments

Comments

Projects
None yet
Contributor

brson commented Oct 4, 2012

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 commented Oct 5, 2012

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.

Contributor

bilalhusain commented Oct 5, 2012

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 commented Oct 5, 2012

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.

Contributor

brson commented Oct 5, 2012

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

Contributor

brson commented Oct 8, 2012

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

Contributor

brson commented Oct 8, 2012

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

Contributor

graydon commented Dec 18, 2012

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.

xrisjc commented Feb 5, 2013

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.)

Contributor

catamorphism commented Mar 21, 2013

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

Contributor

catamorphism commented May 24, 2013

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

Contributor

cmr commented Jun 1, 2013

This is still an issue.

Contributor

metajack commented Jan 13, 2014

Triage bump.

Contributor

vadimcn commented Feb 26, 2014

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.

Any word on this issue so far?

Contributor

cmr commented Aug 1, 2014

@Arelius are you hitting this?

Sorry, false alarm, My issue was actually unrelated.

Contributor

steveklabnik commented Feb 11, 2015

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment