From: Mike Frysinger <vapier@gentoo.org>
To: newlib@sourceware.org
Subject: Re: [PATCH v2] newlib: libm: merge build up a directory
Date: Mon, 21 Feb 2022 13:28:31 -0500 [thread overview]
Message-ID: <YhPZz3V120PVM3iw@vapier> (raw)
In-Reply-To: <YhPTO6OPxvhavVhQ@vapier>
[-- Attachment #1: Type: text/plain, Size: 5510 bytes --]
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) $@
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-02-21 18:28 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-12 20:34 [PATCH] " Mike Frysinger
2022-02-16 8:50 ` [HEADSUP] " Corinna Vinschen
2022-02-16 9:40 ` Sebastian Huber
2022-02-16 10:48 ` Corinna Vinschen
2022-02-17 4:38 ` Mike Frysinger
2022-02-17 4:42 ` [PATCH v2] " Mike Frysinger
2022-02-17 12:08 ` Corinna Vinschen
2022-02-21 11:20 ` Corinna Vinschen
2022-02-21 18:00 ` Mike Frysinger
2022-02-21 18:04 ` Jon Turney
2022-02-21 18:30 ` Mike Frysinger
2022-02-21 19:12 ` Jon Turney
2022-02-21 19:24 ` Corinna Vinschen
2022-02-21 20:30 ` Mike Frysinger
2022-02-21 20:31 ` Mike Frysinger
2022-02-21 18:28 ` Mike Frysinger [this message]
2022-02-21 20:43 ` [PATCH] newlib: libm: workaround ar duplicate member behavior Mike Frysinger
2022-02-21 20:51 ` Joel Sherrill
2022-02-21 22:12 ` Mike Frysinger
2022-02-21 22:14 ` Joel Sherrill
2022-02-22 0:21 ` [PATCH v2] " Mike Frysinger
2022-02-22 11:31 ` Corinna Vinschen
2022-02-22 12:34 ` Jon Turney
2022-02-22 17:17 ` Mike Frysinger
2022-02-23 8:56 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YhPZz3V120PVM3iw@vapier \
--to=vapier@gentoo.org \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).