Re: Library tripled in size with GCC 4.2
Re: Library tripled in size with GCC 4.2
- Subject: Re: Library tripled in size with GCC 4.2
- From: Eric Gorr <email@hidden>
- Date: Wed, 15 Oct 2008 17:46:56 -0400
On Oct 15, 2008, at 5:26 PM, Sean McBride wrote:
On 10/15/08 5:15 PM, Lyndsey Ferguson said:
/Developer/usr/bin/libtool: can't vm_allocate() buffer for output
file: libCore.a of size 1206037468 ((os/kern) no space available)
/usr/bin $ld -v
@(#)PROGRAM:ld PROJECT:ld64-85.2.1
/usr/bin $libtool -V
Apple Computer, Inc. version cctools-698.1
I thought that the ld64 was supposed to handle larger memory
requirements?
The error is with libtool, which is 32bit:
$ lipo -info /Developer/usr/bin/libtool
Architectures in the fat file: /Developer/usr/bin/libtool are: i386
ppc7400
Failing to allocate 1.2 gig in the 32bit process is not surprising.
Any idea on when (or even if) libtool would be updated to handle
larger libraries?
So, is there some flag I can set to get the size of the library down?
The flags I found were:
-feliminate-dwarf2-dups
However, this flag generated a bunch of the following errors:
{standard input}:50796:Expected comma after segment-name
{standard input}:50796:Rest of line ignored. 1st junk character valued
32 ( ).
-feliminate-unused-debug-types
This flag didn't seem to affect the size of the library at all.
-glevel
I cannot go down to level 1 because of the information that would not
be included.
I cannot go up to level 3 because that would appear to just make the
library bigger.
Is splitting the library into two smaller chunks my only option?
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden