Re: arm-eabi fails in libc/sys/arm/: No rule to make target 'lib_a-trap.o', needed by 'lib.a'.

[Mike Frysinger <vapier@gentoo.org>]

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

On 03 Feb 2022 16:49, Richard Earnshaw wrote:
> On 01/02/2022 04:49, Mike Frysinger wrote:
> > this is because i think newlib was relying on automake behavior that is
> > undocumented or unintended.  that said, i'm not sure why this Makefile.am
> > is written the way it is.  it'd be a lot simpler like:
> > 
> > --- a/newlib/libc/sys/arm/Makefile.am
> > +++ b/newlib/libc/sys/arm/Makefile.am
> > @@ -6,16 +6,10 @@ AM_CCASFLAGS = $(AM_CPPFLAGS)
> >   
> >   noinst_LIBRARIES = lib.a
> >   
> > +lib_a_SOURCES = access.c aeabi_atexit.c
> >   if MAY_SUPPLY_SYSCALLS
> > -extra_objs = $(lpfx)libcfunc.o $(lpfx)trap.o $(lpfx)syscalls.o
> > -else
> > -extra_objs =
> > +lib_a_SOURCES += libcfunc.c trap.S syscalls.c
> >   endif
> > -
> > -lib_a_SOURCES = access.c aeabi_atexit.c
> > -lib_a_LIBADD = $(extra_objs)
> > -EXTRA_lib_a_SOURCES = trap.S syscalls.c libcfunc.c
> > -lib_a_DEPENDENCIES = $(extra_objs)
> >   lib_a_CFLAGS = $(AM_CFLAGS)
> >   
> >   if MAY_SUPPLY_SYSCALLS
> 
> This seems to work although one small difference is that instead of 
> building libc_a-trap.o it now builds trap.o.  I'm not sure if that 
> really matters, though.

right, the .S files don't have the prefix on the filename anymore.  i noticed
that and looked through the tree and couldn't see why it would be a problem.
there is one or two places where the exact object file name is used (the
MATHOBJS_IN_LIBC which pulls a small number of libm objects out to copy into
libc.a).

i'm going to push the fix now and we can revisit if someone points out a
problem with it.
-mike

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