mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
3088c4b046
rust/tests/run-make/issue-24445/Makefile

12 lines
289 B
Makefile
Raw Normal View History

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)
Reference in New Issue Copy Permalink