public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Jeff Law <jeffreyalaw@gmail.com>
Cc: newlib@sourceware.org
Subject: Re: libgloss multilib installs broken [was nds broken by recent patches]
Date: Fri, 4 Feb 2022 00:45:22 -0500	[thread overview]
Message-ID: <Yfy9cjPARL/E8vmA@vapier> (raw)
In-Reply-To: <e98f60d2-9d9d-1721-7f65-5bfe98e66b96@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3996 bytes --]

On 03 Feb 2022 09:11, Jeff Law wrote:
> I must have tested the wrong thing as bfin-elf isn't working yet.  It 
> doesn't help that I'm only looking at this for a few minutes before my 
> workday starts...    At least now I  know what's going on.
> 
> The *build* is fine, things go south at *install* time.
> 
> bfin has a wide variety of multilibs and we're installing them into the 
> wrong directories.

well that's annoying.  i was actually testing this code path recently as part
of migrating libgloss to automake, and the install logic worked there, so i
guess i fixed this bug and didn't realize it.

> So I'm sitting in my build directory...
> 
> > [jlaw@dl360p newlib]$ find . -name libsim.a
> > ./bfin-elf/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/mid-shared-library/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/msep-data/libgloss/bfin/libsim.a
> > ./bfin-elf/bf532-none/mfdpic/libgloss/bfin/libsim.a
> > ./bfin-elf/mid-shared-library/libgloss/bfin/libsim.a
> > ./bfin-elf/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a
> > ./bfin-elf/msep-data/libgloss/bfin/libsim.a
> > ./bfin-elf/mfdpic/libgloss/bfin/libsim.a
> 
> As expected.  Now if I go into my install directory:
> 
> > find . -name libsim.a
> > ./bfin-elf/lib/libsim.a
> 
> Egad.  It looks like they all got installed on top of each other in the 
> wrong directory, effectively ignoring the multilib subdirectories.  A 
> checksum quickly shows the version in the install directory is actually 
> this one from the build directory:
> > ./bfin-elf/bf532-none/mid-shared-library/mleaf-id-shared-library/libgloss/bfin/libsim.a
> 
> 
> If I go look at the Makefile in the terminal directory it has this:
> 
> 
> > # Multilib support variables.
> > # TOP is used instead of MULTI{BUILD,SRC}TOP.
> > MULTIDIRS =
> > MULTISUBDIR =
> [ ... ]
> 
> > install-sim:
> >         ${mkinstalldirs} ${DESTDIR}${tooldir}/lib${MULTISUBDIR}
> >         for x in ${SIM_CRT0} ${SIM_BSP} ${SIM_SCRIPTS}; do \
> >          ${INSTALL_DATA} $$x 
> > $(DESTDIR)${tooldir}/lib${MULTISUBDIR}/$$x || exit $$?; \
> >         done
> 
> So, yea, no surprise that it installed into the wrong directory. I think 
> this is the culprit patch:
> 
> > commit 754f8def0dfeeb43afa5a96ad1971fd0ef02c419
> > Author: Mike Frysinger <vapier@gentoo.org>
> > Date:   Sun Jan 23 01:10:33 2022 -0500
> >
> >     libgloss: merge stub arch configure scripts up a level
> >
> >     For about half the ports, we don't need a subdir configure script.
> >     They're using the config/default.m[ht] rules, and they aren't doing
> >     any unique configure tests, so they exist just to pass top-level
> >     settings down to create the arch Makefile.  We can just as easily
> >     do that from the top-level Mkaefile directly and skip configure.
> >
> >     Most of the remaining configure scripts could be migrated up to
> >     the top-level too, but that would require care in each subdir.
> >     So let's be lazy and put that off to another day.

yeah, the config-ml.in logic only rewrites the MULTI* settings in the Makefile
that lives alongside the configure script.  when i removed those stub scripts,
it lost that rewrite logic since they were no longer the main Makefile.  it's
a bit easy to make work, albeit slightly hacky.  on the flip side, the code is
not needed when using non-recursive automake :).

afaict, this is only needed for libgloss because the MULTISUBDIR setting is
used only when installing things.  newlib doesn't install files directly out
of its subdirs ... only out of the top libc/libm dirs.  but i'll update my
local build & test logic to compare the full install tree to be sure.

thanks for tracking this down
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2022-02-04  5:45 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <171dc9cb-6b2c-ead3-1c55-27fadb33220f@gmail.com>
2022-01-28 10:23 ` [PATCH 1/2] newlib: fix preprocessor checks Mike Frysinger
2022-01-28 10:23   ` [PATCH 2/2] newlib: add AC_CACHE_CHECK sugar around " Mike Frysinger
2022-01-31 14:20     ` Corinna Vinschen
2022-01-31 14:18   ` [PATCH 1/2] newlib: fix " Corinna Vinschen
     [not found] ` <YfPDA/LVL745V+02@vapier>
2022-01-28 16:36   ` nds broken by recent patches Jeff Law
2022-01-28 21:54     ` Jeff Law
2022-01-28 23:32       ` Stafford Horne
2022-01-29  0:58         ` Jeff Law
2022-01-29  2:12           ` Stafford Horne
2022-01-29  3:28             ` Jeff Law
2022-01-29  5:15       ` Mike Frysinger
2022-01-29  5:12     ` [PATCH/committed] libgloss: update Makefile regen rules for merged arches Mike Frysinger
2022-01-29  5:13     ` nds broken by recent patches Mike Frysinger
2022-01-31 14:34       ` R. Diez
2022-02-01 17:25       ` Jeff Law
2022-02-02 10:23         ` Mike Frysinger
2022-02-02 20:59           ` Jeff Law
2022-02-03 16:11       ` libgloss multilib installs broken [was nds broken by recent patches] Jeff Law
2022-02-04  5:45         ` Mike Frysinger [this message]
2022-02-07 15:40           ` Jeff Law
2022-02-04  8:55         ` [PATCH] libgloss: restore multilib settings in subdir makefiles Mike Frysinger

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=Yfy9cjPARL/E8vmA@vapier \
    --to=vapier@gentoo.org \
    --cc=jeffreyalaw@gmail.com \
    --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).