| Summary: | "Unsupported relocation type 11 in non-PLT relocations" when running compiled binary | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Gleb Popov <arrowd> |
| Component: | bin | Assignee: | freebsd-toolchain (Nobody) <toolchain> |
| Status: | Closed Unable to Reproduce | ||
| Severity: | Affects Some People | CC: | emaste, julien, koobs |
| Priority: | --- | Keywords: | needs-qa, toolchain |
| Version: | CURRENT | Flags: | koobs:
mfc-stable12?
|
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Gleb Popov
2018-06-19 12:40:30 UTC
I presume this is amd64?
#define R_X86_64_32S 11 /* Add 32 bit sign extended symbol value */
/*
* missing:
* R_X86_64_GOTPCREL, R_X86_64_32, R_X86_64_32S, R_X86_64_16,
* R_X86_64_PC16, R_X86_64_8, R_X86_64_PC8
*/
default:
_rtld_error("%s: Unsupported relocation type %u"
" in non-PLT relocations\n", obj->path,
(unsigned int)ELF_R_TYPE(rela->r_info));
goto done;
The missing R_X86_64_32S comment comes from r115280:
Initial pass at supporting shared libraries on amd64. There are still
a few missing relocation types in amd64/reloc.c, but I have not found
any of them in use yet. :-)
(In reply to Ed Maste from comment #1) Yep, amd64. This comment looks like a cause. Can anything be done with this? I'd like to continue TensorFlow porting effort. Although not related to TensorFlow, I have the same problem when I try to compile an old Ruby interpreter (1.9.3): this is the command I used: CC=clang CXX=clang++ CPP=clang-cpp RUBY_CONFIGURE_OPTS="--enable-shared" MAKE="make" MAKE_OPTS="-j1" LDFLAGS="-Wl,-z,notext" RBENV_ROOT=/home/jcigar/rbenv rbenv install 1.9.3-p551 which fails as configure with the same "Unsupported relocation type 11 in non-PLT relocations" I've copy/pasted the config.log at https://gist.github.com/silenius/52c0febc48e46d95435eafec9ff15054 this is on: FreeBSD sandbox 12.0-RELEASE FreeBSD 12.0-RELEASE r341666 GENERIC amd64 with: LLD 6.0.1 (FreeBSD 335540-1200005) (compatible with GNU linkers) I don't get this problem anymore whem compiling TensorFlow. Not sure if it is fixed, or just some change on TensorFlow side, though. Should we close this? @Gleb Sure, please re-open if the issue becomes reproducible again |