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

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

# only-linux

all:
	$(RUSTC) foo.rs
	$(CC) foo.c -lfoo -L $(TMPDIR) -Wl,--gc-sections -lpthread -ldl -o $(TMPDIR)/foo
	$(call RUN,foo)
	$(CC) foo.c -lfoo -L $(TMPDIR) -Wl,--gc-sections -lpthread -ldl -pie -fPIC -o $(TMPDIR)/foo
	$(call RUN,foo)
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`
std: Fix thread_local! in non-PIE binaries One of the parameters to the magical "register a thread-local destructor" function is called `__dso_handle` and largely just passed along (this seems to be what other implementations do). Currently we pass the value of this symbol, but apparently the correct piece of information to pass is the address of the symbol. In a PIE binary the symbol actually contains an address to itself which is why we've gotten away with what we're doing as long as we have. In a non-PIE binary the symbol contains the address `NULL`, causing a segfault in the runtime library if it keeps going. Closes #24445 2015-04-15 01:26:42 -05:00
use ignore directives for run-make tests This makes the tests easier to read, and makes it possible to tell which tests aren't being run on the host platform. Fixes #56704. 2019-01-06 15:27:57 -06:00			`# only-linux`

std: Fix thread_local! in non-PIE binaries One of the parameters to the magical "register a thread-local destructor" function is called `__dso_handle` and largely just passed along (this seems to be what other implementations do). Currently we pass the value of this symbol, but apparently the correct piece of information to pass is the address of the symbol. In a PIE binary the symbol actually contains an address to itself which is why we've gotten away with what we're doing as long as we have. In a non-PIE binary the symbol contains the address `NULL`, causing a segfault in the runtime library if it keeps going. Closes #24445 2015-04-15 01:26:42 -05:00			`all:`
			`$(RUSTC) foo.rs`
Add a reference to the dl library to the Makefile of the test issue-24445. It prevents the test to fail on ppc64el at least. Part of #39015 2017-03-01 05:17:27 -06:00			`$(CC) foo.c -lfoo -L $(TMPDIR) -Wl,--gc-sections -lpthread -ldl -o $(TMPDIR)/foo`
std: Fix thread_local! in non-PIE binaries One of the parameters to the magical "register a thread-local destructor" function is called `__dso_handle` and largely just passed along (this seems to be what other implementations do). Currently we pass the value of this symbol, but apparently the correct piece of information to pass is the address of the symbol. In a PIE binary the symbol actually contains an address to itself which is why we've gotten away with what we're doing as long as we have. In a non-PIE binary the symbol contains the address `NULL`, causing a segfault in the runtime library if it keeps going. Closes #24445 2015-04-15 01:26:42 -05:00			`$(call RUN,foo)`
Add a reference to the dl library to the Makefile of the test issue-24445. It prevents the test to fail on ppc64el at least. Part of #39015 2017-03-01 05:17:27 -06:00			`$(CC) foo.c -lfoo -L $(TMPDIR) -Wl,--gc-sections -lpthread -ldl -pie -fPIC -o $(TMPDIR)/foo`
std: Fix thread_local! in non-PIE binaries One of the parameters to the magical "register a thread-local destructor" function is called `__dso_handle` and largely just passed along (this seems to be what other implementations do). Currently we pass the value of this symbol, but apparently the correct piece of information to pass is the address of the symbol. In a PIE binary the symbol actually contains an address to itself which is why we've gotten away with what we're doing as long as we have. In a non-PIE binary the symbol contains the address `NULL`, causing a segfault in the runtime library if it keeps going. Closes #24445 2015-04-15 01:26:42 -05:00			`$(call RUN,foo)`