Date: Mon, 8 Apr 2013 11:31:43 +0300 From: Timerlan Moldobaev <moldobaev@...il.com> To: musl@...ts.openwall.com Subject: Re: Building libc separately from libm,librt,libpthread and others Well, the intention is to use musl package with possible source code modifications and platform specific optimizations as a an implementation for standard c library. These sources will be visible to 3rd party developers wishing to use libc services. This is the opportunity to make sure that MIT license allows to do that. As the developers have the freedom to use any compiler /linker they want, can I assume that only the required parts of the libc.a objects will be included in the resulting executable ? On Mon, Apr 8, 2013 at 6:32 AM, Rich Felker <dalias@...ifal.cx> wrote: > On Sun, Apr 07, 2013 at 05:43:11PM +0300, Timerlan Moldobaev wrote: > > Hi, > > > > Can you please help with reducing the size of statically linked libc.a > > library ? > > Whereas the comparison table located in > > http://www.etalabs.net/compare_libcs.html > > claims the size of complete .a set as 333k, I got around 2M while > building > > the library on x86_64 with gcc version 4.1.1. > > I suppose that might be caused by including in libc.a object files that > > belong to libm, librt, libpthread and others. > > Am I right ? > > Is there any way to compile libc.a solely ? > > What is your goal in getting it smaller? With static linking, only the > object files needed by a program end up in the resulting binary, so > compiling less will not make your binaries any smaller. The only > benefits I can think of are (1) reducing time to compile musl, and (2) > storing the development files on an extremely small storage device. If > you tell us what you're trying to do, we can offer better advice on > how to meet your needs. > > Rich > Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.