This is the mail archive of the newlib@sourceware.org mailing list for the newlib 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]

[patch] dirent.h problem with include_next


This turned up while I was trying to get libmudflap to compile for a
mips-elf target.  libmudflap uses dirent.h, and has a configure test for
it.  The configure test worked the first time, i.e. showed that dirent.h
was not supported, but then suddenly started failing after I did an
install, i.e. claimed that dirent.h was supported.

The problem is easy to show with a simple testcase.  I've attached a
typescript showing the problem.  mips-elf does not have dirent.h
support.  I get an error when I try to compile a testcase that uses
dirent.h in the build tree.  But then, after an install, the testcase
works instead of failing, making it look like I have dirent.h support
when I don't.

The problem here is that we are including the build tree dirent.h, which
includes the build tree sys/dirent.h, which does an include_next which
finds the installed dirent.h.  Since dirent.h is protected against
multiple inclusion, the install tree dirent.h does nothing.  So the
testcase works instead of failing as expected.

One way to resolve this problem is to modify sys/dirent.h to undefine
the macro defined in dirent.h.  This way, if we accidentally include the
newlib dirent.h a second time, then we end up with an infinite include
loop.  This is a little gross, but at least we get an error as desired,
and libmudflap configure works as expected.  I've attached a file
showing a trimmed down copy of the result.

An alternative solution here would be to replace the #include_next with
a #error.  If someone does have an alternative dirent.h file, then I see
no reason why we can't force them to install it in the proper place, and
thus avoid the need for the #include_next here.  I note that there is
only one other newlib header that uses #include_next, and that is
limits.h.  However, in this case we are practically guaranteed to find
gcc's version of limits.h, so this does not have the problem of the
dirent.h usage.

The attached patch has been tested with a full mips-elf toolchain build
and make check.  There were no regressions.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Attachment: dirent-testcase
Description: Text document

Attachment: testcase-with-patch
Description: Text document

Attachment: patch.dirent.undef
Description: Text document


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