This is the mail archive of the mailing list for the newlib project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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?
>On Dec  8 09:54, Sebastian Huber wrote:
> >This is an attempt to fix the problem described here:
> >
> >
> >
> >
> >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 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:

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

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

Only libgcc files reside in the gcc directory:

find ./gcc/thumb/cortex-m7/fpv5-d16/hard

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/

# 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;                            \

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  :
PGP     : Public key available on request.

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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]