On 23/10/15 18:39, Doug Evans wrote:
On Fri, Oct 23, 2015 at 10:08 AM, Bernd Schmidt <bschm...@redhat.com> wrote:
On 10/21/2015 09:00 PM, Doug Evans wrote:
I happened to notice local prefixes not working with musl.
Fixes thusly.
Index: config/linux.h
===================================================================
--- config/linux.h (revision 229130)
+++ config/linux.h (working copy)
@@ -174,6 +174,7 @@
#define INCLUDE_DEFAULTS \
{ \
INCLUDE_DEFAULTS_MUSL_GPP \
+ INCLUDE_DEFAULTS_MUSL_LOCAL \
INCLUDE_DEFAULTS_MUSL_PREFIX \
INCLUDE_DEFAULTS_MUSL_CROSS \
INCLUDE_DEFAULTS_MUSL_TOOL \
Looks pretty obvious given that the macro isn't otherwise used AFAICT. However,
I have no idea whether the order is right, since the purpose of all this code
here is apparently only to provide a different order than the default.
So, someone who worked on the original musl patches should comment. I would
also like to know precisely which ordering change over the default is required,
and that it be documented. Ideally we'd come up with a solution that makes us
not duplicate all this stuff in linux.h.
Bernd
Crap, sorry for the resend. Grrrr gmail ...
The only significant different AFAICT is that GCC_INCLUDE_DIR is moved
to later (last).
Why this is is briefly described in the intro comment:
config/linux.h:
/* musl avoids problematic includes by rearranging the include
directories.
* Unfortunately, this is mostly duplicated from cppdefault.c */
I've put LOCAL in the same place as the default (as defined by cppdefault.c),
so one could separate the issues here ...
1) Where does LOCAL go for musl?
LOCAL should go the same place as in cppdefault.c
so the patch is ok.
2) More clarification as to why musl doesn't use the default.
... and thus not block this patch on a more global musl rethink.
OTOH I'm in no rush. :-)
musl moves gcc includes after libc includes, that's
the only change.
i think bsd libcs do the same, compiler headers interfering
with libc headers is problematic (e.g. FLT_ROUNDS is wrong
in gcc float.h, applications shouldn't see that), i'm not sure
why glibc wants the current default order, but i do see some
include_next magic dance between glibc and gcc headers..
i think that should be fixed but most likely there is some
reason for it...
