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

[Mike Frysinger]

On 21 Feb 2022 13: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

i still want to know how to repro your failure so i can make sure my local
testing is sufficient, but i might have figured it out.  we seem to have hit
a bug in `ar` :(.

this should workaround it.  i'll take it upstream to binutils once we settle
things here.
-mike

--- a/newlib/Makefile.am
+++ b/newlib/Makefile.am
@@ -124,6 +124,13 @@ libm_a_CCASFLAGS = $(AM_CCASFLAGS) $(libm_a_CCASFLAGS_$(subst /,_,$(@D))) $(libm
 libm_a_CPPFLAGS = $(AM_CPPFLAGS) -I$(srcdir)/libm/common $(libm_a_CPPFLAGS_$(subst /,_,$(@D))) $(libm_a_CPPFLAGS_$(subst /,_,$(@D)_$(<F)))
 $(libm_a_OBJECTS): stmp-targ-include

+libm.a: $(libm_a_OBJECTS) $(libm_a_DEPENDENCIES)
+	$(AM_V_at)rm -rf $@ $@.tmp && mkdir $@.tmp
+	$(AM_V_AR)for o in $(libm_a_OBJECTS); do cp $$o $@.tmp/ || exit $$?; done; \
+	   $(AR) $(ARFLAGS) $@ $@.tmp/*.o
+	$(AM_V_at)rm -rf $@.tmp
+	$(AM_V_at)$(RANLIB) $@
+
 if HAVE_MULTISUBDIR
 $(BUILD_MULTISUBDIR):
 	$(MKDIR_P) $@
--- a/newlib/Makefile.in
+++ b/newlib/Makefile.in
@@ -3248,11 +3248,6 @@ libm/machine/x86_64/libm_a-fetestexcept.$(OBJEXT):  \
 libm/machine/x86_64/libm_a-feupdateenv.$(OBJEXT):  \
 	libm/machine/x86_64/$(am__dirstamp)
 
-libm.a: $(libm_a_OBJECTS) $(libm_a_DEPENDENCIES) $(EXTRA_libm_a_DEPENDENCIES) 
-	$(AM_V_at)-rm -f libm.a
-	$(AM_V_AR)$(libm_a_AR) libm.a $(libm_a_OBJECTS) $(libm_a_LIBADD)
-	$(AM_V_at)$(RANLIB) libm.a
-
 mostlyclean-compile:
 	-rm -f *.$(OBJEXT)
 	-rm -f libm/common/*.$(OBJEXT)
@@ -8650,6 +8645,13 @@ libg.a: libc.a
 	$(AM_V_GEN)ln libc.a libg.a >/dev/null 2>/dev/null || cp libc.a libg.a
 $(libm_a_OBJECTS): stmp-targ-include
 
+libm.a: $(libm_a_OBJECTS) $(libm_a_DEPENDENCIES)
+	$(AM_V_at)rm -rf $@ $@.tmp && mkdir $@.tmp
+	$(AM_V_AR)for o in $(libm_a_OBJECTS); do cp $$o $@.tmp/ || exit $$?; done; \
+	   $(AR) $(ARFLAGS) $@ $@.tmp/*.o
+	$(AM_V_at)rm -rf $@.tmp
+	$(AM_V_at)$(RANLIB) $@
+
 @HAVE_MULTISUBDIR_TRUE@$(BUILD_MULTISUBDIR):
 @HAVE_MULTISUBDIR_TRUE@	$(MKDIR_P) $@
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/newlib/attachments/20220221/4cb69281/attachment.sig>