rust/tests/run-make/issue-15460/Makefile

# ignore-cross-compile
include ../tools.mk

all: $(call NATIVE_STATICLIB,foo)
	$(RUSTC) foo.rs -C extra-filename=-383hf8 -C prefer-dynamic
	$(RUSTC) bar.rs
	$(call RUN,bar)
ignore failing cross-compiled run-make tests `run-make-fulldeps` is never cross-compiled, so a lot of these tests never accounted for --target. Ignore them when cross-compiling for now. 2023-03-30 08:46:31 -05:00			`# ignore-cross-compile`
Diagnose missing includes in run-make tests 2022-08-22 19:00:00 -05:00			`include ../tools.mk`
rustc: Link entire archives of native libraries As discovered in #15460, a particular #[link(kind = "static", ...)] line is not actually guaranteed to link the library at all. The reason for this is that if the external library doesn't have any referenced symbols in the object generated by rustc, the entire library is dropped by the linker. For dynamic native libraries, this is solved by passing -lfoo for all downstream compilations unconditionally. For static libraries in rlibs this is solved because the entire archive is bundled in the rlib. The only situation in which this was a problem was when a static native library was linked to a rust dynamic library. This commit brings the behavior of dylibs in line with rlibs by passing the --whole-archive flag to the linker when linking native libraries. On OSX, this uses the -force_load flag. This flag ensures that the entire archive is considered candidate for being linked into the final dynamic library. This is a breaking change because if any static library is included twice in the same compilation unit then the linker will start emitting errors about duplicate definitions now. The fix for this would involve only statically linking to a library once. Closes #15460 [breaking-change] 2014-07-30 09:44:20 -05:00
rmake: Get all tests passing on MSVC 2015-08-26 18:57:56 -05:00			`all: $(call NATIVE_STATICLIB,foo)`
rustc: Default to static linking dylibs If a dylib is being produced, the compiler will now first check to see if it can be created entirely statically before falling back to dynamic dependencies. This behavior can be overridden with `-C prefer-dynamic`. Due to the alteration in behavior, this is a breaking change. Any previous users relying on dylibs implicitly maximizing dynamic dependencies should start passing `-C prefer-dynamic` to compilations. Closes #18499 [breaking-change] 2014-11-03 01:02:53 -06:00			`$(RUSTC) foo.rs -C extra-filename=-383hf8 -C prefer-dynamic`
rustc: Link entire archives of native libraries As discovered in #15460, a particular #[link(kind = "static", ...)] line is not actually guaranteed to link the library at all. The reason for this is that if the external library doesn't have any referenced symbols in the object generated by rustc, the entire library is dropped by the linker. For dynamic native libraries, this is solved by passing -lfoo for all downstream compilations unconditionally. For static libraries in rlibs this is solved because the entire archive is bundled in the rlib. The only situation in which this was a problem was when a static native library was linked to a rust dynamic library. This commit brings the behavior of dylibs in line with rlibs by passing the --whole-archive flag to the linker when linking native libraries. On OSX, this uses the -force_load flag. This flag ensures that the entire archive is considered candidate for being linked into the final dynamic library. This is a breaking change because if any static library is included twice in the same compilation unit then the linker will start emitting errors about duplicate definitions now. The fix for this would involve only statically linking to a library once. Closes #15460 [breaking-change] 2014-07-30 09:44:20 -05:00			`$(RUSTC) bar.rs`
			`$(call RUN,bar)`