Re: [PATCH v2] newlib: libm: merge build up a directory

On 21/02/2022 18:00, Mike Frysinger wrote:
> On 21 Feb 2022 12:20, Corinna Vinschen wrote:
>> 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?
> 
> how do you build cygwin ?  i've just been doing w/newlib-cygwin git checkout:
> $ ./configure --target=i686-pc-cygwin && make
> $ ./configure --target=x86_64-pc-cygwin && make
> these are passing for me

You'll need to apply this patch:

https://cygwin.com/pipermail/cygwin-patches/2022q1/011766.html

Otherwise, you are linking with a stale libm.a left in your builddir 
from before these changes.