[
https://issues.apache.org/jira/browse/TS-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13399994#comment-13399994
]
Arno Toell commented on TS-1314:
--------------------------------
Indeed. No need to discuss why your distro would be better than mine or vice
versa.
So, why don't you just allocate
{code}
$ python
>>> length = 0
>>> for i in range(1,65536):
... length += len(str(i))+1
...
>>> length
382104
{code}
382104 * sizeof(char) = 382104 Bytes of data for that port and everyone's
happy?
> 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
