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

Mike Frysinger <[email protected]>
Newsgroups gmane.comp.lib.newlib
Message-ID <YhPZz3V120PVM3iw@vapier>
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 $@ [email protected] && mkdir [email protected]
+	$(AM_V_AR)for o in $(libm_a_OBJECTS); do cp $$o [email protected]/ || exit $$?; done; \
+	   $(AR) $(ARFLAGS) $@ [email protected]/*.o
+	$(AM_V_at)rm -rf [email protected]
+	$(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 $@ [email protected] && mkdir [email protected]
+	$(AM_V_AR)for o in $(libm_a_OBJECTS); do cp $$o [email protected]/ || exit $$?; done; \
+	   $(AR) $(ARFLAGS) $@ [email protected]/*.o
+	$(AM_V_at)rm -rf [email protected]
+	$(AM_V_at)$(RANLIB) $@
+
 @HAVE_MULTISUBDIR_TRUE@$(BUILD_MULTISUBDIR):
 @HAVE_MULTISUBDIR_TRUE@	$(MKDIR_P) $@
signature.asc (application/pgp-signature, 833 B)
-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEuQK1JxMl+JKsJRrUQWM7n+g39YEFAmIT2c4ACgkQQWM7n+g3
9YG3kA/9H/NDJwIQhRRtFNzL5urBQGNrVfk7BO+6RmQDx0/jWdQnId/JcHs/xMKK
EJH2kjnMKg/nKg0MoaCSSj9RA1qpaszViS6c4rPisUltbXOzETYFfbaDcRMqcPWF
xELyCsp753cj5xVWffONF99MSsKT/rknckfUboUL74xw8ehlOsB6TD8KgwogDH7f
QAjtT/NpdIFLLZzLdoZg6GOTBCiuAWC3NJJk2vpa7e4fr/6MJV3gYn58LKrqqLXH
ivLEmsclZteJ8N8+8BSNrwnLauNqdi1Y7ANMmwkKCOZ/ZEywuQjTlizKW+aR/6Mz
aIZsSFZmoSnUmN0cbt1/T7VQydeppH63pTVtzLvCLHcZEtcAIsgFVEKhwXVSJZYo
YFMMabq/NNw2kvvvPWQungpJxidAHDyX/E9QvLAG16RPvhy9Lg4SXAgkEUI+ZibF
6wsotB8Z3BNlRxEDejvuyKssSWb7zqJVR/q6v/QFR9zUH6NSHJMq5YAvgFc1tS9y
nAgxoPto6cHAdzKSdpySObT97i5uamNhelxhyXmDvkNbKOGLPKz0XjlFPZPVRySC
iyPXWJfX0BoDQguhxoKnVcFws5EeSAEYXEEMZnmnvRMnZeBBfM8B4AaKtXPkPzWN
bGL9y98PErG5KZjF2HBrB6eEamLqbFaA6Gt/HuzHBEjhNIKJE7k=
=KyX/
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.