Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Dependency problems in rust 0.2 package for Windows #2129

Closed
jmansion opened this issue Apr 4, 2012 · 1 comment
Closed

Dependency problems in rust 0.2 package for Windows #2129

jmansion opened this issue Apr 4, 2012 · 1 comment

Comments

@jmansion
Copy link

jmansion commented Apr 4, 2012

After installation, on a Win7 64 bit system, rustc fails immediately with:

The program can't start because libgcc_s_dw2-1.dll is missing from your computer. Try reinstalling the program to fix this problem.

dependency walker thinks its a direct requirement of RUSTRT.DLL and RUSTLLVM.DLL, The other dependencies suggest that these were build with mingw, I suspect - why not with clang or msdev?

IESHIMS.DLL is also missing on my system, but its delay-load.
.
Anyway - I think you need to ship mingw runtime components. And that probably means license pain too, even if its just to reference the licenses and indicate where to get the sources.
@graydon
Copy link
Contributor

graydon commented Apr 4, 2012

mingw is a prerequisite for using rust on windows at the moment. This is a dupe of some combination of #1768, #2084, and #1603. Closing.

@graydon graydon closed this as completed Apr 4, 2012
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
@celinval
Perform reachability analysis on a per-harness basis (rust-lang#2439)
2a09d79 
Kani compiler used to generate one `goto-program` for all harnesses in one crate. In some cases, this actually had a negative impact on the harness verification time. This was first reported in rust-lang#1659

The main changes were done in the compiler's module `compiler_interface` and the module `project` from the driver. The compiler will now gather all the harnesses beforehand and it will perform reachability + codegen steps for each harness. All files related to a harness `goto-program` will follow the naming convention bellow:
```
<BASE_NAME>_<MANGLED_NAME>.<EXTENSION>
```
This applies to symtab / goto / type_map / restriction files.

The metadata file is still generated once per target crate, and its name is still the same (`<BASE_NAME>.kani-metadata.json`).

On the driver side, the way we process the artifacts have changed. The driver will now read the metadata for each crate, and collect all artifacts based on the symtab goto file that is recorded in the metadata of each harness.

These changes do not apply for `--function`. We still keep all artifacts based on the crate's `<BASE_NAME>` and we have a separate logic to handle that. Fixing this is captured by rust-lang#2129.
jaisnan pushed a commit to jaisnan/rust-dev that referenced this issue Jul 29, 2024
@celinval
Remove support for the unstable argument --function (rust-lang#3278)
0d8675d 
This is a legacy argument that we have very limited support to. We kept
it around for bookrunner tests, which has been removed already.

Resolves rust-lang#2129
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@graydon @jmansion