[
https://issues.apache.org/jira/browse/TS-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399726#comment-13399726
]
Arno Toell commented on TS-1314:
--------------------------------
After lots of debugging and great help by some people who are much smarter to
debug ELF objects than I am, this is a description of your problem:
First, {{relocation truncated to fit: R_X86_64_PC32 against symbol ...}} means
some of your linked objects try to use an address space larger than 2 GiB in
its symbol table. Thus, at some point GNU ld fails to link code within the
first 2 GiB of the {{.bss}} address space which is literally exhausted.
This implies, you really _need_ more than 2 GiB {{.bss}} which sounds entirely
crazy already. Passing {{-mcmodel=medium}} to g++'s {{CPPFLAGS}} works around
the problem but that's not really a solution I think.
Further looking at the offending symbol table, you end up finding this:
{code}
$ nm -S --size-sort proxy/Main.o
...
0000000000000000 0000000000001de4 T main
0000000000006aff 4000000000000000 B http_accept_port_descriptor
{code}
That sounds like a really, really large {{http_accept_port_descriptor}} object.
Looking at proxy/Main.cc reveals:
{code}
char http_accept_port_descriptor[TS_ARG_MAX + 1];
{code}
with {{TS_ARG_MAX}} being {{ARG_MAX}} unless a command line override was given
at the compile time (see TS-1230). However, this really means you do:
{code}
char http_accept_port_descriptor[3458764513820540925 + 1]
{code}
because of {{./configure}} telling:
{code}
checking the maximum length of command line arguments... 3458764513820540925
{code}
So, you end up to declare a *huge* static array which is most likely way too
large. Thus, from TS-1230 I could use {{--with-arg-max}} with a reasonable
default as another workaround, but what's the purpose to declare a platform
dependent variable length array of size {{ARG_MAX}}? Why not pick a more
reasonable, predictable default size for {{http_accept_port_descriptor}}?
> ATS 3.2 fails to build from source
> ----------------------------------
>
> Key: TS-1314
> URL: https://issues.apache.org/jira/browse/TS-1314
> Project: Traffic Server
> Issue Type: Bug
> Affects Versions: 3.2.0
> Reporter: Arno Toell
> Fix For: 3.2.1
>
> Attachments: trafficserver_3.2.0-1_amd64.build,
> trafficserver_3.2.0-1_amd64.i386-build,
> trafficserver_3.2.0-1_amd64.verbose-build
>
>
> Building Apache Traffic Server 3.2 on Debian AMD64 (x86_64) using the default
> tool chain (gcc 4.7, binutils 2.22) fails to build from source. However, it's
> not the compiler which fails, but the linker (no, really):
> I'm afraid, but it's far beyond my knowledge where this problem comes from as
> my ELF skills are somewhat limited. This is what I get upon linking:
> {code}
> IPAllow.o: In function `ClassAllocator<Event>::alloc()':
> /«PKGBUILDDIR»/proxy/../lib/ts/Allocator.h:115:(.text+0x70): relocation
> truncated to fit: R_X86_64_32 against symbol `eventAllocator' defined in .bss
> section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> IPAllow.o: In function `memcpy':
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0x96): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xa2): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xad): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xb8): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xc3): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xce): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xd9): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xe4): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xef): relocation
> truncated to fit: R_X86_64_PC32 against symbol `eventAllocator' defined in
> .bss section in ../iocore/eventsystem/libinkevent.a(UnixEvent.o)
> /usr/include/x86_64-linux-gnu/bits/string3.h:52:(.text+0xfa): additional
> relocation overflows omitted from the output
> collect2: error: ld returned 1 exit status
> {code}
> Full build log used in a clean build chroot attached. The very same build
> environment built 3.0.5 just fine less than a week ago.
> And yes, sorry, I know I should have tested when zwoop asked for votes before
> releasing 3.2 :/
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
