[PATCH v2] newlib: libm: merge build up a directory
Corinna Vinschen
vinschen@redhat.com
Mon Feb 21 11:20:45 GMT 2022
Hi Mike,
On Feb 16 23:42, Mike Frysinger wrote:
> Convert all the libm/ subdir makes into the top-level Makefile. This
> allows us to build all of libm from the top Makefile without using any
> recursive make calls. This is faster and avoids the funky lib.a logic
> where we unpack subdir archives to repack into a single libm.a. The
> machine override logic is maintained though by way of Makefile include
> ordering, and source file accumulation in libm_a_SOURCES.
>
> One thing to note is that this will require GNU Make because of:
> libm_a_CFLAGS = ... $(libm_a_CFLAGS_$(subst /,_,$(@D)))
> This was the only way I could find to supporting per-dir compiler
> settings, and I couldn't find a POSIX compatible way of transforming
> the variable content. I don't think this is a big deal as other
> Makefiles in the tree are using GNU Make-specific syntax, but I call
> this out as it's the only one so far in the new automake code that
> I've been writing.
>
> Automake doesn't provide precise control over the output object names
> (by design). This is fine by default as we get consistent names in all
> the subdirs: libm_a-<source>.o. But this relies on using the same set
> of compiler flags for all objects. We currently compile libm/common/
> with different optimizations than the rest.
>
> If we want to compile objects differently, we can create an intermediate
> archive with the subset of objects with unique flags, and then add those
> objects to the main archive. But Automake will use a different prefix
> for the objects, and thus we can't rely on ordering to override.
>
> But if we leverage $@, we can turn Automake's CFLAGS into a multiplex
> on a per-dir (and even per-file if we wanted) basis. Unfortunately,
> since $@ contains /, Automake complains it's an invalid name. While
> GNU Make supports this, it's a POSIX extension, so Automake flags it.
> Using $(subst) avoids the Automake warning to get a POSIX compliant
> name, albeit with a GNU Make extension.
> ---
> v2
> - rebased onto latest tree
> - fixed a parallel build issue with generated newlib headers & libm objects
This patch breaks Cygwin. Unfortunately I didn't try to build myself,
but only inspected the patch, so I didn't realize the problem.
First of all, Cygwin takes libm.a from newlib/libm/, not from newlib.
This is easily fixable.
However, even after fixing this, we get a link stage error for *all*
fenv functions:
ld: x86_64-pc-cygwin/newlib/libm.a(libm_a-fenv.o): in function `fegetenv':
newlib/libm/machine/x86_64/../shared_x86/fenv.c:160:
multiple definition of `fegetenv';
x86_64-pc-cygwin/newlib/libm.a(libm_a-fegetenv.o):
newlib/libm/fenv/fegetenv.c:65:
first defined here
For some reason, libm.a contains both definitions of the fenv functions,
the x86_64 definitions from newlib/libm/machine/shared_x86, as well as
the fallback definitions from newlib/libm/fenv.
Can you please take a look?
Thanks,
Corinna
More information about the Newlib
mailing list