On 21 Feb 2022 18:04, Jon Turney wrote:
> 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.

while i often test incremental changes, i `rm -rf` the build dir when running
the full test suite to avoid possible issues like this.  and in this case,
both targets pass from a fresh build.
-mike