[Solved] Cant "install" letsencrypt (gcc)


Hello Community of Lets Encrypt,

I successfully installed letsencrypt on an OpenVZ V-Server, but because i have multiple servers i tried to “install” letsencrypt on a second KVM based Root-Server.

I followed the Instructions given on this Page: https://letsencrypt.org/getting-started/.

The command ./letsencrypt-auto --help results in this:

building ‘_cffi_backend’ extension

creating build/temp.linux-x86_64-2.7

creating build/temp.linux-x86_64-2.7/c

gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -DUSE__THREAD -I/usr/include/python2.7 -c c/_cffi_backend.c -o build/temp.linux-x86_64-2.7/c/_cffi_backend.o

gcc -pthread -shared -Wl,-O1 -Wl,-Bsymbolic-functions -Wl,-z,relro build/temp.linux-x86_64-2.7/c/_cffi_backend.o -lffi -o build/lib.linux-x86_64-2.7/_cffi_backend.so

/usr/bin/ld: BFD (GNU Binutils for Debian) 2.22 internal error, aborting at …/…/bfd/reloc.c line 443 in bfd_get_reloc_size

/usr/bin/ld: Please report this bug.

collect2: error: ld returned 1 exit status

error: command ‘gcc’ failed with exit status 1

Command /root/.local/share/letsencrypt/bin/python -c “import setuptools;file=’/tmp/pip-niFqhW-build/setup.py’;exec(compile(open(file).read().replace(’
’, ‘
’), file, ‘exec’))” install --single-version-externally-managed --record /tmp/pip-7cZlEm-record/install-record.txt --install-headers /root/.local/share/letsencrypt/include/site/python2.7 failed with error code 1 in /tmp/pip-niFqhW-build

I even reinstalled python, but i cant fix this issue, i really appreciate an answer and solution.
Thank You :slight_smile:



Are you doing this on a low-memory VM by any chance? The client tends to fail while compiling cffi on systems like that:

Adding a swapfile might help.


Does the environment that you’re trying to build in have a particularly limited amount of RAM? Some people have experienced problems related to trying to install in memory-limited environments.

If not, this might be a binutils bug that maybe can be reported to the binutils project.


First of all, thank you for the answers. I expected waiting times about 1 week or something :slight_smile:

Running low on memory isnt the fault i guess, because both VMs running on the same amount of memory.
I add the meminfo, just in case, i fail to see some important informations.

MemTotal: 8200100 kB
MemFree: 1111644 kB
Buffers: 194416 kB
Cached: 3166260 kB
SwapCached: 0 kB
Active: 5052680 kB
Inactive: 1781136 kB
Active(anon): 3473732 kB
Inactive(anon): 384 kB
Active(file): 1578948 kB
Inactive(file): 1780752 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 16774140 kB
SwapFree: 16774140 kB
Dirty: 1428 kB
Writeback: 0 kB
AnonPages: 3473100 kB
Mapped: 95284 kB
Shmem: 980 kB
Slab: 195320 kB
SReclaimable: 177588 kB
SUnreclaim: 17732 kB
KernelStack: 2520 kB
PageTables: 18888 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 20874188 kB
Committed_AS: 4236312 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 28200 kB
VmallocChunk: 34359710071 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 49024 kB
DirectMap2M: 8339456 kB

I dont know much about “binutils”, is there a chance to get an other version to solve the problem?



The current binutils is 2.26:

The latest release of GNU binutils is 2.26


But it might not be packaged for your operating system and it might be more risk or trouble than it’s worth to try to compile and install it yourself without the cooperation of your operating system package manager.


I looked at the source code for GNU binutils and that function has changed between 2.22 and 2.26 with the addition of another case as an alternative to aborting. So it’s actually possible that this problem has been fixed. Maybe you can try to get your operating system to give you a newer binutils package, or as an extreme case compile a newer one for yourself.


I suggest you try my client:

Pure bash, simple, lightweight, smart and powerful.


Thank you guys for all your suggests.

The “binutils” seemed a bit to risky for me, but thank you @schoen for your suggests.
@Neilpang your client works pretty well, after i fixed some special issues by myself (le issue apache)

It works right now, with the best way it can work i guess.



@ReptoxX, I’m glad the other client is working well for you.

If you ever happen to try again with something that has a newer OS image and you get the same error, it would probably be useful to let the binutils developers know, because that could be a sign of a new binutils bug that they don’t know about yet.


This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.