This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 06/19] Define IN_MODULE for translation units that define NOT_IN_libc
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Siddhesh Poyarekar <siddhesh at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 5 Sep 2014 11:54:43 -0700 (PDT)
- Subject: Re: [PATCH 06/19] Define IN_MODULE for translation units that define NOT_IN_libc
- Authentication-results: sourceware.org; auth=none
- References: <1408618663-2281-1-git-send-email-siddhesh at redhat dot com> <1408618663-2281-7-git-send-email-siddhesh at redhat dot com> <20140822182825 dot 04B6A2C398C at topped-with-meat dot com> <20140822185445 dot GO16835 at spoyarek dot pnq dot redhat dot com> <20140901171944 dot GK4395 at spoyarek dot pnq dot redhat dot com>
> On Sat, Aug 23, 2014 at 12:24:45AM +0530, Siddhesh Poyarekar wrote:
> > On Fri, Aug 22, 2014 at 11:28:24AM -0700, Roland McGrath wrote:
> > > interp.c is in fact in libc. I don't see why libof-interp should be set at
> > > all.
> >
> > I remember the build breaking when I made it libc. I'll check again,
> > but I remember concluding that it couldn't be libc.
>
> I just checked again. The compilation always includes libc-symbols.h,
> which adds symbol hacks for memcpy, memset and memmove, that become
> internal references when IS_IN(libc).
I can't tell if you're saying this is an actual problem. I don't see why
symbol-hacks.h would be a problem for interp.c.