This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: [PATCH] Fix multilib build
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.