[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151130013555.GT3818@brightrain.aerifal.cx>
Date: Sun, 29 Nov 2015 20:35:55 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Support for out-of-tree build
On Mon, Nov 30, 2015 at 01:29:06AM +0000, Petr Hosek wrote:
> On Fri, Nov 20, 2015 at 2:21 PM Rich Felker <dalias@...c.org> wrote:
>
> > I think this is failing to replicate the current behavior where a .sub
> > file in src/*/$(ARCH)$(ASMSUBARCH) replaces the .s file in
> > src/*/$(ARCH). In cases where both exist we'll end up with duplicate
> > symbol errors linking libc.so and both present (with the wrong one
> > likely getting used) in libc.a.
> >
>
> I tried various combinations of ARCH and SUBARCH and the behavior seems to
> be the same as in current implementation. Do you have any examples?
With ARCH=sh and SUBARCH=-nofpu and ASMSUBARCH=-nofpu, it looks to
me like both src/setjmp/sh/setjmp.o and src/setjmp/sh-nofpu/setjmp.s
will get included, rather than the latter replacing the former.
> > This problem will of course disappear when we get rid of .sub files,
> > but that doesn't help unless we remove .sub files first.
> >
> > I suppose all that's needed for now is to add more EXCLUDE_OBJS using
> > the same input but with:
> >
> > $(subst /$(ARCH)$(ASMSUBARCH)/,/$(ARCH)/,...
> >
> > instead of:
> >
> > $(subst /$(ARCH)$(ASMSUBARCH)/,/,...
> >
> > Does this sound right?
> >
>
> When I tried this change, I started getting duplicate symbol errors when
> linking libc.so, but with the original it seems to be working fine (this
> particular case was when ARCH=arm SUBARCH=hf ASMSUBARCH=ebhf).
I didn't mean to get rid of the existing subst, but to introduce a
second one, so that src/whatever/$(ARCH)@(ASMSUBARCH)/foo.o
excludes/replaces both src/whatever/$(ARCH)/foo.o and
src/whatever/foo.o.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
