Re: [PATCH] Fix multilib build

[Sebastian Huber <sebastian dot huber at embedded-brains dot de>]

On 12/12/16 21:57, Jeff Johnston wrote:
> See comments below.
>
> ----- Original Message -----
> > >
> > >Jeff?  Can you take a look please?
> > >
> > >
> > >Thanks,
> > >Corinna
> > >
> > >
> > >On Dec  8 09:54, Sebastian Huber wrote:
> > > > >This is an attempt to fix the problem described here:
> > > > >
> > > > >https://sourceware.org/ml/newlib/2016/msg01139.html
> > > > >https://gcc.gnu.org/ml/gcc/2016-12/msg00010.html
> > > > >
> > > > >There is no change if libtool is used.
> > > > >
> > > > >Some run-time support libraries provided by GCC (e.g. libgomp) use
> > > > >configure checks to detect certain features, e.g. availability of
> > > > >thread-local storage.  The configure script generates a test program and
> > > > >tries to compile and link it.  It should use target libraries and
> > > > >startfiles of the build tree if available and not random ones from the
> > > > >installation prefix for this procedure.  The search directories
> > > > >specified by -B are a bit special, see for_each_path() in gcc.c of the
> > > > >GCC sources.  First a search is performed on all search paths with the
> > > > >multilib directories appended (if desired), then a second search is
> > > > >performed on demand with the base directory only.  For each multilib
> > > > >there is a "newlib" subdirectory.  This directory is specified by a -B
> > > > >option for the support libraries.  In order to find the newlib artifacts
> > > > >(ctr0.o, libc.a libg.a and libm.a) there must be additional multilib
> > > > >subdirectories.
> > > > >
> I don't understand why the logic isn't put into gcc.  It can figure out that
> newlib is being built.  The directory structure of newlib is in keeping with
> config-ml.in so it should be able to calculate where crt0.0, libc.a, and libm.a
> are located for a multi subdir.

The way GCC finds a certain library seems to be fixed:

https://gcc.gnu.org/ml/gcc/2016-12/msg00013.html

It seems that the build directory of run-time libraries is 
$target/$multisubdir/$library-package/ inside the GCC build tree. For 
example

find -name libatomic.a | sort
./arm-rtems4.12/eb/thumb/armv7-r/libatomic/.libs/libatomic.a
./arm-rtems4.12/eb/thumb/armv7-r/vfpv3-d16/hard/libatomic/.libs/libatomic.a
./arm-rtems4.12/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/armv6-m/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/armv7-a/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/armv7-a/neon/hard/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/armv7-m/fpv4-sp-d16/hard/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/armv7-m/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/armv7-r/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/armv7-r/vfpv3-d16/hard/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/cortex-m7/fpv5-d16/hard/libatomic/.libs/libatomic.a
./arm-rtems4.12/thumb/libatomic/.libs/libatomic.a
./arm-rtems4.12/vfp/hard/libatomic/.libs/libatomic.a

The libgcc seems to be a bit special, since the libgcc.a is also present 
relative to a gcc directory:

find -name libgcc.a | sort
./arm-rtems4.12/eb/thumb/armv7-r/libgcc/libgcc.a
./arm-rtems4.12/eb/thumb/armv7-r/vfpv3-d16/hard/libgcc/libgcc.a
./arm-rtems4.12/libgcc/libgcc.a
./arm-rtems4.12/thumb/armv6-m/libgcc/libgcc.a
./arm-rtems4.12/thumb/armv7-a/libgcc/libgcc.a
./arm-rtems4.12/thumb/armv7-a/neon/hard/libgcc/libgcc.a
./arm-rtems4.12/thumb/armv7-m/fpv4-sp-d16/hard/libgcc/libgcc.a
./arm-rtems4.12/thumb/armv7-m/libgcc/libgcc.a
./arm-rtems4.12/thumb/armv7-r/libgcc/libgcc.a
./arm-rtems4.12/thumb/armv7-r/vfpv3-d16/hard/libgcc/libgcc.a
./arm-rtems4.12/thumb/cortex-m7/fpv5-d16/hard/libgcc/libgcc.a
./arm-rtems4.12/thumb/libgcc/libgcc.a
./arm-rtems4.12/vfp/hard/libgcc/libgcc.a
./gcc/eb/thumb/armv7-r/libgcc.a
./gcc/eb/thumb/armv7-r/vfpv3-d16/hard/libgcc.a
./gcc/libgcc.a
./gcc/thumb/armv6-m/libgcc.a
./gcc/thumb/armv7-a/libgcc.a
./gcc/thumb/armv7-a/neon/hard/libgcc.a
./gcc/thumb/armv7-m/fpv4-sp-d16/hard/libgcc.a
./gcc/thumb/armv7-m/libgcc.a
./gcc/thumb/armv7-r/libgcc.a
./gcc/thumb/armv7-r/vfpv3-d16/hard/libgcc.a
./gcc/thumb/cortex-m7/fpv5-d16/hard/libgcc.a
./gcc/thumb/libgcc.a
./gcc/vfp/hard/libgcc.a

Only libgcc files reside in the gcc directory:

find ./gcc/thumb/cortex-m7/fpv5-d16/hard
./gcc/thumb/cortex-m7/fpv5-d16/hard
./gcc/thumb/cortex-m7/fpv5-d16/hard/crti.o
./gcc/thumb/cortex-m7/fpv5-d16/hard/crtbegin.o
./gcc/thumb/cortex-m7/fpv5-d16/hard/libgcov.a
./gcc/thumb/cortex-m7/fpv5-d16/hard/crtend.o
./gcc/thumb/cortex-m7/fpv5-d16/hard/crtn.o
./gcc/thumb/cortex-m7/fpv5-d16/hard/crtfastmath.o
./gcc/thumb/cortex-m7/fpv5-d16/hard/libgcc.a

So, one option would be to do this copy step also for newlib and maybe 
the other run-time libraries as well. See for example libgcc/Makefile.in:

[...]
# Build extra startfiles in the libgcc directory.
.PHONY: libgcc-extra-parts
libgcc-extra-parts: $(EXTRA_PARTS)

    # Early copyback; see "all" above for the rationale.  The
    # early copy is necessary so that the gcc -B options find
    # the right startup files when linking shared libgcc.
    $(mkinstalldirs) $(gcc_objdir)$(MULTISUBDIR)
    parts="$(EXTRA_PARTS)";                    \
    for file in $$parts; do                    \
      rm -f $(gcc_objdir)$(MULTISUBDIR)/$$file;        \
      $(INSTALL_DATA) $$file $(gcc_objdir)$(MULTISUBDIR)/;    \
      case $$file in                     \
        *.a)                        \
          $(RANLIB) $(gcc_objdir)$(MULTISUBDIR)/$$file ;;    \
      esac;                            \
    done
[...]

This uses GCC-specific $(gcc_objdir) etc. I am not sure if this is all 
accessible to the Newlib build system.

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.