[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121011232858.GA254@brightrain.aerifal.cx>
Date: Thu, 11 Oct 2012 19:28:58 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: feature request: flag to disable math library build
On Thu, Oct 11, 2012 at 09:37:38PM +0200, Szabolcs Nagy wrote:
> * Szabolcs Nagy <nsz@...t70.net> [2012-10-11 20:17:09 +0200]:
> > if you don't like such hacks then you can add
> >
> > SRCS:=$(filter-out src/complex/%,$(SRCS))
> > SRCS:=$(filter-out src/math/%,$(SRCS))
> >
> > to your config.mak
> >
> > i'm not sure how safe is this: libc uses some math
> > functions (at least stdio uses frexpl for printf)
>
> these are the math functions used by other parts
> of libc (mostly float scan and print):
>
> M = \
> __fpclassifyl \
> copysign \
> copysignl \
> fabs \
> fmod \
> fmodl \
> frexp \
> frexpl \
> scalbn \
> scalbnl \
>
> so you need
>
> SRCS := $(SRCS) $(M:%=src/math/%.c)
>
> (not tested)
Note that this breaks if any of the above functions ever depend on
other math functions or internal math modules, not to mention if the
set of math functions used by the other part of the library ever
changes. I'm generally opposed to this kind of feature switching
because it has huge maintenance cost keeping track of all possible
configurations and ensuring none of them are broken.
I think the problem of extreme slowness building on emulated or
low-end hardware could be better addressed by using distcc, cross
compiling, or other approaches that leverage a more-powerful cpu
instead of omitting parts of libc. (Anyway, isn't musl only a tiny
percentage of the total build time?)
Rich
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.
