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