up vote 3 down vote favorite
1

I'm using the 32-bit version of Rust 1.6 on Windows 10 to compile rustlab. When I run cargo build to build it, it says to

link against the following native artifacts when linking against this static library

I would like to do exactly that. Is there a way to get the full paths for the libraries that were used?

PS C:\rs\rustlab> cargo build -v
   Compiling libc v0.2.7
     Running `rustc C:\Users\cameron\.cargo\registry\src\github.com-48ad6e4054423464\libc-0.2.7\src\lib.rs --crate-name libc --crate-typ
e lib -g --cfg "feature=\"default\"" -C metadata=0c94fdfb80c4b805 -C extra-filename=-0c94fdfb80c4b805 --out-dir C:\rs\rustlab\target\deb
ug\deps --emit=dep-info,link -L dependency=C:\rs\rustlab\target\debug\deps -L dependency=C:\rs\rustlab\target\debug\deps --cap-lints all
ow`
   Compiling rustlab v0.1.0 (file:///C:/rs/rustlab)
     Running `rustc src\lib.rs --crate-name rustlab --crate-type staticlib --crate-type dylib -g --out-dir C:\rs\rustlab\target\debug --
emit=dep-info,link -L dependency=C:\rs\rustlab\target\debug -L dependency=C:\rs\rustlab\target\debug\deps --extern libc=C:\rs\rustlab\ta
rget\debug\deps\liblibc-0c94fdfb80c4b805.rlib`
note: link against the following native artifacts when linking against this static library
note: the order and any duplication can be significant on some platforms, and so may need to be preserved
note: library: gcc_eh
note: library: gcc_eh
note: library: ws2_32
note: library: userenv
note: library: shell32
note: library: advapi32

For example, I have three x86 versions of WS2_32.lib. Which one was used?

C:\Program Files (x86)\Windows Kits\8.1\Lib\winv6.3\um\x86\WS2_32.Lib
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10240.0\um\x86\WS2_32.Lib
C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10586.0\um\x86\WS2_32.Lib
share|improve this question
up vote 2 down vote accepted

There are two ABI options for Rust on Windows: MSVC and GNU (GCC). You say you're using the 32-bit version of Rust 1.6; there's no 32-bit version using the MSVC ABI for Rust 1.6 (it's only available starting with Rust 1.8), so I assume you're using the GNU ABI version.

If you are indeed using the GNU ABI version, then you need to link against GNU ABI static libraries. These libraries have names like libXXXX.a, instead of XXXX.lib for MSVC.

If you don't have a file named libws2_32.a anywhere on your system, then you need to install MinGW, which is a port of GCC for Windows that also includes static libraries for the most commonly used Windows DLLs. There are multiple active "forks" of MinGW: mingw-w64 and TDM-GCC have more recent versions of GCC than the original MinGW project, which appears to be dormant.

Is there a way to get the full paths for the libraries that were used?

Normally, you don't specify the full path when linking. For GCC, you pass an option like -lws2_32 and the linker will find the library for you. If the linker doesn't find it, you can add an -L <path> option to add a directory in the linker's search path for static libraries.

Cargo has some documentation on how to write a build script that can add these options automatically when you run cargo build.

share|improve this answer
    
You guessed right. I am using the GNU 32-bit version of Rust in order to build libraries for GNU Octave. I see that Rust has a libws2_32.a and so does Octave. How do I know if they are compatible? Can I have Rust use the one from Octave? The locations are C:\Program Files (x86)\Rust stable GNU 1.6\lib\rustlib\i686-pc-windows-gnu\lib\libws2_32.a and C:\Octave\Octave-4.0.0\lib\libws2_32.a. If I created a build script that outputed rustc-link-search to the Octave path, would it use libws2_32.a from there instead? – Cameron Taggart Feb 12 '16 at 2:49
1  
How do I know if they are compatible? Try them both! Seriously, I think they should both work, as long as they define the symbols your application and its dependencies need. If linking with Octave's libws2_32.a doesn't work, you'll have trouble linking with Octave's other libraries! ... would it use libws2_32.a from there instead? I think so. One way to be sure is to use Process Monitor to watch for events on files with that name. – Francis Gagné Feb 12 '16 at 13:06

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.