This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc 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: Use more defines and makefile variables in $(native-compile)


On Wed, Apr 25, 2012 at 6:42 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> In <http://sourceware.org/ml/libc-alpha/2012-03/msg00358.html>, there
> were various requests for particular makefile variables and
> preprocessor defines to be used for cross-rpcgen.
>
> I propose this patch as an intermediate step moving the existing
> $(native-compile) closer to what's wanted for cross-rpcgen, so that as
> much as possible can end up in shared makefile variables.
> $(native-compile) is made to use $(BUILD_LDFLAGS).
> $(ALL_BUILD_CFLAGS) has $(BUILD_CPPFLAGS) added, along with
> -D_GNU_SOURCE (used for everything built with or as a part of the new
> libc via libc-symbols.h; desirable also for build-system programs to
> get all the expected definitions from the build-system headers[*]) and
> -DIS_IN_build (a generic define for build-system programs proposed in
> the above referenced message). ?Tested x86_64.
>
> [*] Ideally build-system programs might also work when the build
> system has a non-GNU libc; occasionally someone tries cross-compiling
> glibc from such a non-GNU system. ?But that's certainly not a
> priority; defining _GNU_SOURCE helps on some build systems (at least,
> those with older glibc where _GNU_SOURCE is required to get stpcpy
> declared - rpcgen uses stpcpy) and is unlikely to hurt anywhere.
> People cross-compiling from non-GNU systems are of course welcome to
> send patches for portability issues found.
>
> 2012-04-25 ?Joseph Myers ?<joseph@codesourcery.com>
>
> ? ? ? ?* Makerules (native-compile): Use $(BUILD_LDFLAGS).
> ? ? ? ?(ALL_BUILD_CFLAGS): Use $(BUILD_CPPFLAGS) -D_GNU_SOURCE
> ? ? ? ?-DIS_IN_build.

This looks good to me.

However, I find it hard to see the forest from the trees.

Would you post an email with a rough outline of the final design?

Such an email would give the reviewers the ability to judge your
patches against the framework of changes you proposed in the design.

Cheers,
Carlos.


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