linker could not read symbols: Malformed archive

1
votes

I am trying to build a C++ software with debug symbols enabled (-g). The problem is that the additional debug symbols make the included library that large that the final linking step fails with

../../lib/libutil.a: could not read symbols: Malformed archive

(at least I think it's failing because of it's size, which is slightly over 6 GB on disk)

I looked around and found hints that there might be maximum size for static libraries of 4 GB. Not sure if this applies to my system which is a 64 bit CentOS:

$ uname -a Linux host 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I am using the g++ (GCC) 4.8.2 compiler and the binutils version is GNU ld version 2.20.51.0.2-5.36.el6.

If there is indeed a maximum limit of 4GB that the archive tool or linker can handle what are my options without tempering too much with the interna of the build system (which is autotools by the way)?

1
c++linuxgcclinker

1 Answers

1
votes

It looks like the maximum size of an archive is, indeed four gigabytes.

Wikipedia has a nice write-up of archive file format. The limit that you appear to be hitting is:

  1. A set of 32-bit big endian integers. One for each symbol, recording the position within the archive of the header for the file containing this symbol.

The way I parse this, is that all individual files in the .a file must start before the 4 gigabyte cutoff. Would be nice to get a more meaningful error message in this situation, though.

No easy way around this. Your only realistic option is to chop up your source code so that it gets linked into multiple .a archives, with each one under 4 gigs in size.

I do see a hard way around this. The limit in question is part of the symbol table, which I believe gets created by ranlib. If you hack your Makefile so that a symbol table does not get generated (perhaps by setting RANLIB=/bin/true), no symbol file would get generated, so you won't hit this limit. Your link time would suffer greatly, thought, and this would only allow you to create archives up to 9,999,999,999 bytes (not much more than what you already are creating), due to the 10 character limit of the file size in the ar header itself.

Just create multiple .a files.