Open shepmaster opened 8 years ago
This is what the staticlib
was intended for, where each staticlib
contains all Rust dependencies so you don't have to go find all the extra rlibs. Would that work for this use case?
Would that work for this use case?
Hmm, I'm not sure. I really do need a foo.o
file at the end here because I need to call out by hand to a different linker (through avr-gcc
in this case) to link together some hand-written assembly and the Rust code. If I try to build a staticlib
, I get
error: could not find native static library `compiler-rt`
As you can see, everything is at a very early stage of "working".
It's entirely possible that this isn't a case that Cargo wants to be able to handle, and that would be fine. It's just that I can substitute obj
for link
in the verbose output of cargo build
and it works, so I figured I'd post here. :-)
Ah if all you need to do is call out to an external linker creating a staticlib should in theory take care of everything you need. If you're using a custom target spec you should be able to disable the compiler-rt
requirement I believe.
It seems not unreasonable to do some rudimentary detection with cargo rustc
though to not stomp over the flags too too much.
Ah if all you need to do is call out to an external linker creating a staticlib should in theory take care of everything you need. If you're using a custom target spec you should be able to disable the compiler-rt requirement I believe.
This was a very useful set of pointers in the right direction, thank you. I went ahead and created a target specification with a custom linker and left my code as an executable. This produces a file that is suitable for consumption by the rest of the pipeline. Would you like to leave this issue open for the potential clobber of --emit
?
Yeah that seems reasonable to leave this open for now.
@alexcrichton Yeah, I second this issue. In my particular case, the environment already includes compiler-rt
, and it is onerous and unnecessary to cross-build it through Cargo.
+1
Would you like to leave this issue open for the potential clobber of
--emit
?
For (my) clarity, does this mean changing cargo rustc [..] -- --emit=obj
so that it runs rustc [..] --emit=dep-info,obj
, dropping the link
?
I'd like this issue to be resolved, too, and I think I have a pretty important use case. Better support for --emit=llvm-bc
would allow me get the Rust artefact and perform a manual linking step to get everything ready for WebAssembly. I currently really need that functionality in order to eventually get Filament to play nice with Rust in the browser. Is there any way I can help? I messed a bit with the code base, but I'm not too sure what exactly is the right way to tackle this issue.
I found this issue while I was googling how to disable link
.
I just wanted to generate LLVM bitcode using cargo rustc
command but resulting executable is not needed.
This workaround is enough to me.
$ cargo rustc --bin <NAME> -- --emit=llvm-bc -C linker=/usr/bin/true
I just added linker
codegen.
While trying the work-in-progress of AVR-enabled Rust, I am currently unable to actually link programs. Instead, I have to stop at an object and do things by hand from there.
I'd still like to be able to use Cargo to handle all the dependency work, but there's no way to disable the existing
--emit=dep-info,link
argument. I can add additionalemit
options though:Of note is that two options are supplied:
--emit=obj [...] --emit=dep-info,link
.I assume that
dep-info
is needed for other workings, but it's be nice to be able to disable thelink
.