<div dir="ltr"><div>Looks like 2.6.18 kernel is pretty old... Mark, do you actually plan to use sanitizers? We consider dropping support for old kernels to ease the maintenance.</div><div>Seems that with all the recent ioctl hackery we'll need to add support for detecting Linux kernel version and headers availability to our build system...<br>
</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">+samsonov</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <span dir="ltr"><<a href="mailto:codetech@dericnet.com" target="_blank">codetech@dericnet.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">While the following partial patch may not be the best approach, it solves the compiler build failure problem on RHEL 5 in my sandbox (and probably for any Linux 2.x kernel at or before 2.6.18). Ultimately, maybe we should avoid holding a compiler build hostage to incompatible TCP/IP headers in a target/build host's distribution?<br>
<br>
Also, is there an easy way to find out if there's a buildbot slave running RHEL5 w/gcc 4.8.1? I waded through some clicks off of <a href="http://lab.llvm.org:8011/buildslaves" target="_blank">http://lab.llvm.org:8011/buildslaves</a>, but it wasn't obvious and I thought there must be an easier, better way? I could volunteer part of a modest box for that duty since it's dear to my heart.<br>
<br>
Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc<br>
===================================================================<br>
--- lib/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 186236)<br>
+++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc (working copy)<br>
@@ -73,8 +73,11 @@<br>
#include <linux/if_eql.h><br>
#include <linux/if_plip.h><br>
#include <linux/lp.h><br>
+#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro<br>
+#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18<br>
#include <linux/mroute.h><br>
#include <linux/mroute6.h><br>
+#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18<br>
#include <linux/scc.h><br>
#include <linux/serial.h><br>
#endif // SANITIZER_LINUX && !SANITIZER_ANDROID<br>
@@ -279,7 +282,7 @@<br>
unsigned struct_unimapinit_sz = sizeof(struct unimapinit);<br>
#endif<br>
<br>
-#if !SANITIZER_ANDROID<br>
+#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18<br>
unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);<br>
unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);<br>
#endif<br>
@@ -330,7 +333,7 @@<br>
unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;<br>
unsigned IOCTL_TIOCSTI = TIOCSTI;<br>
unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;<br>
-#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC<br>
+#if (SANITIZER_LINUX && !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC<br>
unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;<br>
unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;<br>
#endif<br>
<br>
Needless to say, getting to a good way to set the manifest constant SOMETIME_AFTER_LINUX_KERNEL_2_6_18 is still an open question. I got some encouragement that there might be a good GNU autotools way to do this from <a href="http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html" target="_blank">http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html</a>; but this is well outside my sweet spot.<br>
<br>
Thank you.<br>
<span><font color="#888888"><br>
Mark<br>
</font></span><div><div><br>
<br>
On Sat, 13 Jul 2013 15:15:33 -0700<br>
Mark Deric <<a href="mailto:codetech@dericnet.com" target="_blank">codetech@dericnet.com</a>> wrote:<br>
<br>
> This is the same issue as reported in the "Trouble compiling CLANG on on<br>
> RHEL 3.0" from 18 June. It applies to CentOS/RHEL 5 as well. Afaict, the<br>
> bust was introduced on 7 June in check in "[compiler-rt] r183517 -<br>
> [sanitizer] ioctl interceptor"; though that's from code inspection, not<br>
> from having tried the immediate predecessor. The Clang 3.3 certainly<br>
> builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the distro's<br>
> stock gcc 4.1.2. I did not automate the SVN checkout and build until 24<br>
> June and have been getting this bust since then; here's last night's try:<br>
><br>
> In file included from /mnt/share/RHEL5_local/buildroot/llvm_projects/llvm_svn_wtest_20130712_191043/projects/compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_posix.cc:76:<br>
> In file included from /usr/include/linux/mroute.h:5:<br>
> /usr/include/linux/in.h:26:3: error: redefinition of enumerator 'IPPROTO_IP'<br>
> IPPROTO_IP = 0, /* Dummy protocol for TCP */<br>
> ^<br>
> /usr/include/netinet/in.h:34:21: note: expanded from macro 'IPPROTO_IP'<br>
> #define IPPROTO_IP IPPROTO_IP<br>
> ^<br>
> /usr/include/netinet/in.h:33:5: note: previous definition is here<br>
> IPPROTO_IP = 0, /* Dummy protocol for TCP. */<br>
> ^<br>
><br>
> IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other manifest<br>
> constants/enums collide in later messages. Further, if the build got by<br>
> this issue, I think it would land on the rocks again with the subsequent<br>
> include of <linux/mroute6.h> on the next line of<br>
> sanitizer_platform_limits_posix.cc since that file does not exist in the<br>
> CentOS/RHEL 5 distribution.<br>
><br>
> I did a code check of these headers on Ubuntu 12.04 and the organization<br>
> seems updated and consistent with the compiler-rt sanitizer code. It also<br>
> appears as though there is some effort to do OS/platform detection using<br>
> manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc. But these are<br>
> based on things like "#if defined(__linux__)" and do not appear to be<br>
> granular enough to accomodate the header differences among Linux'es.<br>
><br>
> I'm a newbie to building/using and looking at Clang so I don't know the<br>
> idioms for OS/platform detection or the consumer side of sanitizer; and I<br>
> suspect fixups in those areas are the right way to address this bust.<br>
><br>
> +eugenis following Kostya Serebryany's lead<br>
><br>
> --<br>
> Mark Deric <<a href="mailto:codetech@dericnet.com" target="_blank">codetech@dericnet.com</a>><br>
> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br>
<br>
--<br>
Mark Deric <<a href="mailto:codetech@dericnet.com" target="_blank">codetech@dericnet.com</a>><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>Alexey Samsonov, MSK</div>
</div>