CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Mark Deric
This is the same issue as reported in the "Trouble compiling CLANG on on
RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.  Afaict, the
bust was introduced on 7 June in check in "[compiler-rt] r183517 -
[sanitizer] ioctl interceptor"; though that's from code inspection, not
from having tried the immediate predecessor.  The Clang 3.3 certainly
builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the distro's
stock gcc 4.1.2.  I did not automate the SVN checkout and build until 24
June and have been getting this bust since then; here's last night's try:

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:
In file included from /usr/include/linux/mroute.h:5:
/usr/include/linux/in.h:26:3: error: redefinition of enumerator 'IPPROTO_IP'
  IPPROTO_IP = 0,               /* Dummy protocol for TCP               */
  ^
/usr/include/netinet/in.h:34:21: note: expanded from macro 'IPPROTO_IP'
#define IPPROTO_IP              IPPROTO_IP
                                ^
/usr/include/netinet/in.h:33:5: note: previous definition is here
    IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
    ^

IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other manifest
constants/enums collide in later messages.  Further, if the build got by
this issue, I think it would land on the rocks again with the subsequent
include of <linux/mroute6.h> on the next line of
sanitizer_platform_limits_posix.cc since that file does not exist in the
CentOS/RHEL 5 distribution.

I did a code check of these headers on Ubuntu 12.04 and the organization
seems updated and consistent with the compiler-rt sanitizer code.  It also
appears as though there is some effort to do OS/platform detection using
manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But these are
based on things like "#if defined(__linux__)" and do not appear to be
granular enough to accomodate the header differences among Linux'es.

I'm a newbie to building/using and looking at Clang so I don't know the
idioms for OS/platform detection or the consumer side of sanitizer; and I
suspect fixups in those areas are the right way to address this bust.

+eugenis following Kostya Serebryany's lead

--
Mark Deric <[hidden email]>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Mark Deric
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?

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 http://lab.llvm.org:8011/buildslaves, 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.

Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
===================================================================
--- lib/sanitizer_common/sanitizer_platform_limits_posix.cc (revision 186236)
+++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc (working copy)
@@ -73,8 +73,11 @@
 #include <linux/if_eql.h>
 #include <linux/if_plip.h>
 #include <linux/lp.h>
+#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
+#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
 #include <linux/mroute.h>
 #include <linux/mroute6.h>
+#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
 #include <linux/scc.h>
 #include <linux/serial.h>
 #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
@@ -279,7 +282,7 @@
   unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
 #endif
 
-#if !SANITIZER_ANDROID
+#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
   unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
   unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
 #endif
@@ -330,7 +333,7 @@
   unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
   unsigned IOCTL_TIOCSTI = TIOCSTI;
   unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
-#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
+#if (SANITIZER_LINUX && !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
   unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
   unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
 #endif

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 http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html; but this is well outside my sweet spot.

Thank you.

Mark


On Sat, 13 Jul 2013 15:15:33 -0700
Mark Deric <[hidden email]> wrote:

> This is the same issue as reported in the "Trouble compiling CLANG on on
> RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.  Afaict, the
> bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> [sanitizer] ioctl interceptor"; though that's from code inspection, not
> from having tried the immediate predecessor.  The Clang 3.3 certainly
> builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the distro's
> stock gcc 4.1.2.  I did not automate the SVN checkout and build until 24
> June and have been getting this bust since then; here's last night's try:
>
> 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:
> In file included from /usr/include/linux/mroute.h:5:
> /usr/include/linux/in.h:26:3: error: redefinition of enumerator 'IPPROTO_IP'
>   IPPROTO_IP = 0,               /* Dummy protocol for TCP               */
>   ^
> /usr/include/netinet/in.h:34:21: note: expanded from macro 'IPPROTO_IP'
> #define IPPROTO_IP              IPPROTO_IP
>                                 ^
> /usr/include/netinet/in.h:33:5: note: previous definition is here
>     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
>     ^
>
> IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other manifest
> constants/enums collide in later messages.  Further, if the build got by
> this issue, I think it would land on the rocks again with the subsequent
> include of <linux/mroute6.h> on the next line of
> sanitizer_platform_limits_posix.cc since that file does not exist in the
> CentOS/RHEL 5 distribution.
>
> I did a code check of these headers on Ubuntu 12.04 and the organization
> seems updated and consistent with the compiler-rt sanitizer code.  It also
> appears as though there is some effort to do OS/platform detection using
> manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But these are
> based on things like "#if defined(__linux__)" and do not appear to be
> granular enough to accomodate the header differences among Linux'es.
>
> I'm a newbie to building/using and looking at Clang so I don't know the
> idioms for OS/platform detection or the consumer side of sanitizer; and I
> suspect fixups in those areas are the right way to address this bust.
>
> +eugenis following Kostya Serebryany's lead
>
> --
> Mark Deric <[hidden email]>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


--
Mark Deric <[hidden email]>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Kostya Serebryany
+samsonov


On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]> wrote:
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?

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 http://lab.llvm.org:8011/buildslaves, 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.

Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
===================================================================
--- lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (revision 186236)
+++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (working copy)
@@ -73,8 +73,11 @@
 #include <linux/if_eql.h>
 #include <linux/if_plip.h>
 #include <linux/lp.h>
+#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
+#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
 #include <linux/mroute.h>
 #include <linux/mroute6.h>
+#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
 #include <linux/scc.h>
 #include <linux/serial.h>
 #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
@@ -279,7 +282,7 @@
   unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
 #endif

-#if !SANITIZER_ANDROID
+#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
   unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
   unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
 #endif
@@ -330,7 +333,7 @@
   unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
   unsigned IOCTL_TIOCSTI = TIOCSTI;
   unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
-#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
+#if (SANITIZER_LINUX && !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
   unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
   unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
 #endif

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 http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html; but this is well outside my sweet spot.

Thank you.

Mark


On Sat, 13 Jul 2013 15:15:33 -0700
Mark Deric <[hidden email]> wrote:

> This is the same issue as reported in the "Trouble compiling CLANG on on
> RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.  Afaict, the
> bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> [sanitizer] ioctl interceptor"; though that's from code inspection, not
> from having tried the immediate predecessor.  The Clang 3.3 certainly
> builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the distro's
> stock gcc 4.1.2.  I did not automate the SVN checkout and build until 24
> June and have been getting this bust since then; here's last night's try:
>
> 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:
> In file included from /usr/include/linux/mroute.h:5:
> /usr/include/linux/in.h:26:3: error: redefinition of enumerator 'IPPROTO_IP'
>   IPPROTO_IP = 0,               /* Dummy protocol for TCP               */
>   ^
> /usr/include/netinet/in.h:34:21: note: expanded from macro 'IPPROTO_IP'
> #define IPPROTO_IP              IPPROTO_IP
>                                 ^
> /usr/include/netinet/in.h:33:5: note: previous definition is here
>     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
>     ^
>
> IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other manifest
> constants/enums collide in later messages.  Further, if the build got by
> this issue, I think it would land on the rocks again with the subsequent
> include of <linux/mroute6.h> on the next line of
> sanitizer_platform_limits_posix.cc since that file does not exist in the
> CentOS/RHEL 5 distribution.
>
> I did a code check of these headers on Ubuntu 12.04 and the organization
> seems updated and consistent with the compiler-rt sanitizer code.  It also
> appears as though there is some effort to do OS/platform detection using
> manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But these are
> based on things like "#if defined(__linux__)" and do not appear to be
> granular enough to accomodate the header differences among Linux'es.
>
> I'm a newbie to building/using and looking at Clang so I don't know the
> idioms for OS/platform detection or the consumer side of sanitizer; and I
> suspect fixups in those areas are the right way to address this bust.
>
> +eugenis following Kostya Serebryany's lead
>
> --
> Mark Deric <[hidden email]>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


--
Mark Deric <[hidden email]>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Alexey Samsonov
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.
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...


On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <[hidden email]> wrote:
+samsonov


On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]> wrote:
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?

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 http://lab.llvm.org:8011/buildslaves, 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.

Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
===================================================================
--- lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (revision 186236)
+++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (working copy)
@@ -73,8 +73,11 @@
 #include <linux/if_eql.h>
 #include <linux/if_plip.h>
 #include <linux/lp.h>
+#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
+#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
 #include <linux/mroute.h>
 #include <linux/mroute6.h>
+#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
 #include <linux/scc.h>
 #include <linux/serial.h>
 #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
@@ -279,7 +282,7 @@
   unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
 #endif

-#if !SANITIZER_ANDROID
+#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
   unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
   unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
 #endif
@@ -330,7 +333,7 @@
   unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
   unsigned IOCTL_TIOCSTI = TIOCSTI;
   unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
-#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
+#if (SANITIZER_LINUX && !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
   unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
   unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
 #endif

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 http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html; but this is well outside my sweet spot.

Thank you.

Mark


On Sat, 13 Jul 2013 15:15:33 -0700
Mark Deric <[hidden email]> wrote:

> This is the same issue as reported in the "Trouble compiling CLANG on on
> RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.  Afaict, the
> bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> [sanitizer] ioctl interceptor"; though that's from code inspection, not
> from having tried the immediate predecessor.  The Clang 3.3 certainly
> builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the distro's
> stock gcc 4.1.2.  I did not automate the SVN checkout and build until 24
> June and have been getting this bust since then; here's last night's try:
>
> 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:
> In file included from /usr/include/linux/mroute.h:5:
> /usr/include/linux/in.h:26:3: error: redefinition of enumerator 'IPPROTO_IP'
>   IPPROTO_IP = 0,               /* Dummy protocol for TCP               */
>   ^
> /usr/include/netinet/in.h:34:21: note: expanded from macro 'IPPROTO_IP'
> #define IPPROTO_IP              IPPROTO_IP
>                                 ^
> /usr/include/netinet/in.h:33:5: note: previous definition is here
>     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
>     ^
>
> IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other manifest
> constants/enums collide in later messages.  Further, if the build got by
> this issue, I think it would land on the rocks again with the subsequent
> include of <linux/mroute6.h> on the next line of
> sanitizer_platform_limits_posix.cc since that file does not exist in the
> CentOS/RHEL 5 distribution.
>
> I did a code check of these headers on Ubuntu 12.04 and the organization
> seems updated and consistent with the compiler-rt sanitizer code.  It also
> appears as though there is some effort to do OS/platform detection using
> manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But these are
> based on things like "#if defined(__linux__)" and do not appear to be
> granular enough to accomodate the header differences among Linux'es.
>
> I'm a newbie to building/using and looking at Clang so I don't know the
> idioms for OS/platform detection or the consumer side of sanitizer; and I
> suspect fixups in those areas are the right way to address this bust.
>
> +eugenis following Kostya Serebryany's lead
>
> --
> Mark Deric <[hidden email]>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev


--
Mark Deric <[hidden email]>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev




--
Alexey Samsonov, MSK

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Mark Deric
Kernel is pretty old, but it's the core of a wildly popular RHEL5 distribution that's still getting kernel updates (i.e., kernel-2.6.18-348.12.1.el5 as recently as last week!).  I think a bunch of 'nix shops are passing on RHEL6 awaiting 7, then there's the conversion period.  So, my guess is that RHEL5 will represent widespread active production machines for at least the next 24 months.

On the "do I use sanitizers" question, the answer is not explicitly and/or not yet, being new to Clang.  I only use the compiler now, but I want to use static analyzer and other llvm code quality tools as I find them, and play with formatter.  The problem I had was even compiler would not build following the basic instructions with the mroute6?.h headers.

Conceptually, if there's a code bit that drills into headers for very platform specific things like ioctl, using autotool-like detection or support of a narrowed platform set seems like a real design choice.  In the event of picking the latter, maybe the top level build instructions should provide a way to unplug "sanitizer" so the compiler itself can enjoy an wider target range?

Thank you.

Mark

On Wed, 17 Jul 2013 17:29:40 +0400
Alexey Samsonov <[hidden email]> wrote:

> 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.
> 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...
>
>
> On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <[hidden email]> wrote:
>
> > +samsonov
> >
> >
> > On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]>wrote:
> >
> >> 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?
> >>
> >> 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
> >> http://lab.llvm.org:8011/buildslaves, 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.
> >>
> >> Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> ===================================================================
> >> --- lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (revision
> >> 186236)
> >> +++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (working
> >> copy)
> >> @@ -73,8 +73,11 @@
> >>  #include <linux/if_eql.h>
> >>  #include <linux/if_plip.h>
> >>  #include <linux/lp.h>
> >> +#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
> >> +#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >>  #include <linux/mroute.h>
> >>  #include <linux/mroute6.h>
> >> +#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >>  #include <linux/scc.h>
> >>  #include <linux/serial.h>
> >>  #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
> >> @@ -279,7 +282,7 @@
> >>    unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
> >>  #endif
> >>
> >> -#if !SANITIZER_ANDROID
> >> +#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >>    unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
> >>    unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
> >>  #endif
> >> @@ -330,7 +333,7 @@
> >>    unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
> >>    unsigned IOCTL_TIOCSTI = TIOCSTI;
> >>    unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
> >> -#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
> >> +#if (SANITIZER_LINUX && !SANITIZER_ANDROID &&
> >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
> >>    unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
> >>    unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
> >>  #endif
> >>
> >> 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
> >> http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html;
> >> but this is well outside my sweet spot.
> >>
> >> Thank you.
> >>
> >> Mark
> >>
> >>
> >> On Sat, 13 Jul 2013 15:15:33 -0700
> >> Mark Deric <[hidden email]> wrote:
> >>
> >> > This is the same issue as reported in the "Trouble compiling CLANG on on
> >> > RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.  Afaict,
> >> the
> >> > bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> >> > [sanitizer] ioctl interceptor"; though that's from code inspection, not
> >> > from having tried the immediate predecessor.  The Clang 3.3 certainly
> >> > builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the
> >> distro's
> >> > stock gcc 4.1.2.  I did not automate the SVN checkout and build until 24
> >> > June and have been getting this bust since then; here's last night's
> >> try:
> >> >
> >> > 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:
> >> > In file included from /usr/include/linux/mroute.h:5:
> >> > /usr/include/linux/in.h:26:3: error: redefinition of enumerator
> >> 'IPPROTO_IP'
> >> >   IPPROTO_IP = 0,               /* Dummy protocol for TCP
> >> */
> >> >   ^
> >> > /usr/include/netinet/in.h:34:21: note: expanded from macro 'IPPROTO_IP'
> >> > #define IPPROTO_IP              IPPROTO_IP
> >> >                                 ^
> >> > /usr/include/netinet/in.h:33:5: note: previous definition is here
> >> >     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
> >> >     ^
> >> >
> >> > IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other manifest
> >> > constants/enums collide in later messages.  Further, if the build got by
> >> > this issue, I think it would land on the rocks again with the subsequent
> >> > include of <linux/mroute6.h> on the next line of
> >> > sanitizer_platform_limits_posix.cc since that file does not exist in the
> >> > CentOS/RHEL 5 distribution.
> >> >
> >> > I did a code check of these headers on Ubuntu 12.04 and the organization
> >> > seems updated and consistent with the compiler-rt sanitizer code.  It
> >> also
> >> > appears as though there is some effort to do OS/platform detection using
> >> > manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But these
> >> are
> >> > based on things like "#if defined(__linux__)" and do not appear to be
> >> > granular enough to accomodate the header differences among Linux'es.
> >> >
> >> > I'm a newbie to building/using and looking at Clang so I don't know the
> >> > idioms for OS/platform detection or the consumer side of sanitizer; and
> >> I
> >> > suspect fixups in those areas are the right way to address this bust.
> >> >
> >> > +eugenis following Kostya Serebryany's lead
> >> >
> >> > --
> >> > Mark Deric <[hidden email]>
> >> > _______________________________________________
> >> > cfe-dev mailing list
> >> > [hidden email]
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >>
> >> --
> >> Mark Deric <[hidden email]>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> [hidden email]
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >
> >
>
>
> --
> Alexey Samsonov, MSK
>


--
Mark Deric <[hidden email]>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Alexey Samsonov
I see your point. We'll try to add header detection to our build system soon.


On Wed, Jul 17, 2013 at 6:01 PM, Mark Deric <[hidden email]> wrote:
Kernel is pretty old, but it's the core of a wildly popular RHEL5 distribution that's still getting kernel updates (i.e., kernel-2.6.18-348.12.1.el5 as recently as last week!).  I think a bunch of 'nix shops are passing on RHEL6 awaiting 7, then there's the conversion period.  So, my guess is that RHEL5 will represent widespread active production machines for at least the next 24 months.

On the "do I use sanitizers" question, the answer is not explicitly and/or not yet, being new to Clang.  I only use the compiler now, but I want to use static analyzer and other llvm code quality tools as I find them, and play with formatter.  The problem I had was even compiler would not build following the basic instructions with the mroute6?.h headers.

Conceptually, if there's a code bit that drills into headers for very platform specific things like ioctl, using autotool-like detection or support of a narrowed platform set seems like a real design choice.  In the event of picking the latter, maybe the top level build instructions should provide a way to unplug "sanitizer" so the compiler itself can enjoy an wider target range?

Thank you.

Mark

On Wed, 17 Jul 2013 17:29:40 +0400
Alexey Samsonov <[hidden email]> wrote:

> 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.
> 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...
>
>
> On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <[hidden email]> wrote:
>
> > +samsonov
> >
> >
> > On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]>wrote:
> >
> >> 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?
> >>
> >> 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
> >> http://lab.llvm.org:8011/buildslaves, 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.
> >>
> >> Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> ===================================================================
> >> --- lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (revision
> >> 186236)
> >> +++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (working
> >> copy)
> >> @@ -73,8 +73,11 @@
> >>  #include <linux/if_eql.h>
> >>  #include <linux/if_plip.h>
> >>  #include <linux/lp.h>
> >> +#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
> >> +#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >>  #include <linux/mroute.h>
> >>  #include <linux/mroute6.h>
> >> +#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >>  #include <linux/scc.h>
> >>  #include <linux/serial.h>
> >>  #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
> >> @@ -279,7 +282,7 @@
> >>    unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
> >>  #endif
> >>
> >> -#if !SANITIZER_ANDROID
> >> +#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >>    unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
> >>    unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
> >>  #endif
> >> @@ -330,7 +333,7 @@
> >>    unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
> >>    unsigned IOCTL_TIOCSTI = TIOCSTI;
> >>    unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
> >> -#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
> >> +#if (SANITIZER_LINUX && !SANITIZER_ANDROID &&
> >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
> >>    unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
> >>    unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
> >>  #endif
> >>
> >> 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
> >> http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html;
> >> but this is well outside my sweet spot.
> >>
> >> Thank you.
> >>
> >> Mark
> >>
> >>
> >> On Sat, 13 Jul 2013 15:15:33 -0700
> >> Mark Deric <[hidden email]> wrote:
> >>
> >> > This is the same issue as reported in the "Trouble compiling CLANG on on
> >> > RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.  Afaict,
> >> the
> >> > bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> >> > [sanitizer] ioctl interceptor"; though that's from code inspection, not
> >> > from having tried the immediate predecessor.  The Clang 3.3 certainly
> >> > builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the
> >> distro's
> >> > stock gcc 4.1.2.  I did not automate the SVN checkout and build until 24
> >> > June and have been getting this bust since then; here's last night's
> >> try:
> >> >
> >> > 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:
> >> > In file included from /usr/include/linux/mroute.h:5:
> >> > /usr/include/linux/in.h:26:3: error: redefinition of enumerator
> >> 'IPPROTO_IP'
> >> >   IPPROTO_IP = 0,               /* Dummy protocol for TCP
> >> */
> >> >   ^
> >> > /usr/include/netinet/in.h:34:21: note: expanded from macro 'IPPROTO_IP'
> >> > #define IPPROTO_IP              IPPROTO_IP
> >> >                                 ^
> >> > /usr/include/netinet/in.h:33:5: note: previous definition is here
> >> >     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
> >> >     ^
> >> >
> >> > IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other manifest
> >> > constants/enums collide in later messages.  Further, if the build got by
> >> > this issue, I think it would land on the rocks again with the subsequent
> >> > include of <linux/mroute6.h> on the next line of
> >> > sanitizer_platform_limits_posix.cc since that file does not exist in the
> >> > CentOS/RHEL 5 distribution.
> >> >
> >> > I did a code check of these headers on Ubuntu 12.04 and the organization
> >> > seems updated and consistent with the compiler-rt sanitizer code.  It
> >> also
> >> > appears as though there is some effort to do OS/platform detection using
> >> > manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But these
> >> are
> >> > based on things like "#if defined(__linux__)" and do not appear to be
> >> > granular enough to accomodate the header differences among Linux'es.
> >> >
> >> > I'm a newbie to building/using and looking at Clang so I don't know the
> >> > idioms for OS/platform detection or the consumer side of sanitizer; and
> >> I
> >> > suspect fixups in those areas are the right way to address this bust.
> >> >
> >> > +eugenis following Kostya Serebryany's lead
> >> >
> >> > --
> >> > Mark Deric <[hidden email]>
> >> > _______________________________________________
> >> > cfe-dev mailing list
> >> > [hidden email]
> >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >>
> >> --
> >> Mark Deric <[hidden email]>
> >> _______________________________________________
> >> cfe-dev mailing list
> >> [hidden email]
> >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >>
> >
> >
>
>
> --
> Alexey Samsonov, MSK
>


--
Mark Deric <[hidden email]>



--
Alexey Samsonov, MSK

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Karen Shaeffer
In reply to this post by Mark Deric
Hi,
Yes, the RedHat EL5 kernel will be maintained by RedHat for several more years. They
are just now EOLing EL4. So, you can believe the 2.6.18 kernel will be viable for
a number of years yet.

The EL5 kernel has a huge patch list. I believe it is about 1500 patches. Ball Park
estimate, could be more. RedHat backports whatever features they want to support. It
remains viable even today, despite the old release number.

enjoy,
Karen

On Wed, Jul 17, 2013 at 07:01:56AM -0700, Mark Deric wrote:

> Kernel is pretty old, but it's the core of a wildly popular RHEL5 distribution that's still getting kernel updates (i.e., kernel-2.6.18-348.12.1.el5 as recently as last week!).  I think a bunch of 'nix shops are passing on RHEL6 awaiting 7, then there's the conversion period.  So, my guess is that RHEL5 will represent widespread active production machines for at least the next 24 months.
>
> On the "do I use sanitizers" question, the answer is not explicitly and/or not yet, being new to Clang.  I only use the compiler now, but I want to use static analyzer and other llvm code quality tools as I find them, and play with formatter.  The problem I had was even compiler would not build following the basic instructions with the mroute6?.h headers.
>
> Conceptually, if there's a code bit that drills into headers for very platform specific things like ioctl, using autotool-like detection or support of a narrowed platform set seems like a real design choice.  In the event of picking the latter, maybe the top level build instructions should provide a way to unplug "sanitizer" so the compiler itself can enjoy an wider target range?
>
> Thank you.
>
> Mark
>
> On Wed, 17 Jul 2013 17:29:40 +0400
> Alexey Samsonov <[hidden email]> wrote:
>
> > 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.
> > 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...
> >
> >
> > On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <[hidden email]> wrote:
> >
> > > +samsonov
> > >
> > >
> > > On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]>wrote:
> > >
> > >> 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?
> > >>
> > >> 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
> > >> http://lab.llvm.org:8011/buildslaves, 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.
> > >>
> > >> Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> > >> ===================================================================
> > >> --- lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (revision
> > >> 186236)
> > >> +++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc     (working
> > >> copy)
> > >> @@ -73,8 +73,11 @@
> > >>  #include <linux/if_eql.h>
> > >>  #include <linux/if_plip.h>
> > >>  #include <linux/lp.h>
> > >> +#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
> > >> +#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> > >>  #include <linux/mroute.h>
> > >>  #include <linux/mroute6.h>
> > >> +#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> > >>  #include <linux/scc.h>
> > >>  #include <linux/serial.h>
> > >>  #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
> > >> @@ -279,7 +282,7 @@
> > >>    unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
> > >>  #endif
> > >>
> > >> -#if !SANITIZER_ANDROID
> > >> +#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> > >>    unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
> > >>    unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
> > >>  #endif
> > >> @@ -330,7 +333,7 @@
> > >>    unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
> > >>    unsigned IOCTL_TIOCSTI = TIOCSTI;
> > >>    unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
> > >> -#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
> > >> +#if (SANITIZER_LINUX && !SANITIZER_ANDROID &&
> > >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
> > >>    unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
> > >>    unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
> > >>  #endif
> > >>
> > >> 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
> > >> http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html;
> > >> but this is well outside my sweet spot.
> > >>
> > >> Thank you.
> > >>
> > >> Mark
> > >>
> > >>
> > >> On Sat, 13 Jul 2013 15:15:33 -0700
> > >> Mark Deric <[hidden email]> wrote:
> > >>
> > >> > This is the same issue as reported in the "Trouble compiling CLANG on on
> > >> > RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.  Afaict,
> > >> the
> > >> > bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> > >> > [sanitizer] ioctl interceptor"; though that's from code inspection, not
> > >> > from having tried the immediate predecessor.  The Clang 3.3 certainly
> > >> > builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the
> > >> distro's
> > >> > stock gcc 4.1.2.  I did not automate the SVN checkout and build until 24
> > >> > June and have been getting this bust since then; here's last night's
> > >> try:
> > >> >
> > >> > 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:
> > >> > In file included from /usr/include/linux/mroute.h:5:
> > >> > /usr/include/linux/in.h:26:3: error: redefinition of enumerator
> > >> 'IPPROTO_IP'
> > >> >   IPPROTO_IP = 0,               /* Dummy protocol for TCP
> > >> */
> > >> >   ^
> > >> > /usr/include/netinet/in.h:34:21: note: expanded from macro 'IPPROTO_IP'
> > >> > #define IPPROTO_IP              IPPROTO_IP
> > >> >                                 ^
> > >> > /usr/include/netinet/in.h:33:5: note: previous definition is here
> > >> >     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
> > >> >     ^
> > >> >
> > >> > IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other manifest
> > >> > constants/enums collide in later messages.  Further, if the build got by
> > >> > this issue, I think it would land on the rocks again with the subsequent
> > >> > include of <linux/mroute6.h> on the next line of
> > >> > sanitizer_platform_limits_posix.cc since that file does not exist in the
> > >> > CentOS/RHEL 5 distribution.
> > >> >
> > >> > I did a code check of these headers on Ubuntu 12.04 and the organization
> > >> > seems updated and consistent with the compiler-rt sanitizer code.  It
> > >> also
> > >> > appears as though there is some effort to do OS/platform detection using
> > >> > manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But these
> > >> are
> > >> > based on things like "#if defined(__linux__)" and do not appear to be
> > >> > granular enough to accomodate the header differences among Linux'es.
> > >> >
> > >> > I'm a newbie to building/using and looking at Clang so I don't know the
> > >> > idioms for OS/platform detection or the consumer side of sanitizer; and
> > >> I
> > >> > suspect fixups in those areas are the right way to address this bust.
> > >> >
> > >> > +eugenis following Kostya Serebryany's lead
> > >> >
> > >> > --
> > >> > Mark Deric <[hidden email]>
> > >> > _______________________________________________
> > >> > cfe-dev mailing list
> > >> > [hidden email]
> > >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > >>
> > >>
> > >> --
> > >> Mark Deric <[hidden email]>
> > >> _______________________________________________
> > >> cfe-dev mailing list
> > >> [hidden email]
> > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > >>
> > >
> > >
> >
> >
> > --
> > Alexey Samsonov, MSK
> >
>
>
> --
> Mark Deric <[hidden email]>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
--- end quoted text ---

--
Karen Shaeffer
Neuralscape, Mountain View, CA 94040
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Mark Deric
In reply to this post by Alexey Samsonov
Thanks, Alexey.

I would reiterate my willingness to put a piece of a modest RHEL5 machine in place as a buildbot slave if you could point me to the right person to get around the "builds now" requirement.  Hey, it's not just a 286, it has a great V35 modem capable of 56 kilobaud!  And I would have worked on finding some ac_helpful.m4 on mroute.h but, just as I was shutting down the fryer at my day job, this soccer team comes in ordering 31 super size.  Hate it when that happens.

On Wed, 17 Jul 2013 18:18:23 +0400
Alexey Samsonov <[hidden email]> wrote:

> I see your point. We'll try to add header detection to our build system
> soon.
>
>
> On Wed, Jul 17, 2013 at 6:01 PM, Mark Deric <[hidden email]> wrote:
>
> > Kernel is pretty old, but it's the core of a wildly popular RHEL5
> > distribution that's still getting kernel updates (i.e.,
> > kernel-2.6.18-348.12.1.el5 as recently as last week!).  I think a bunch of
> > 'nix shops are passing on RHEL6 awaiting 7, then there's the conversion
> > period.  So, my guess is that RHEL5 will represent widespread active
> > production machines for at least the next 24 months.
> >
> > On the "do I use sanitizers" question, the answer is not explicitly and/or
> > not yet, being new to Clang.  I only use the compiler now, but I want to
> > use static analyzer and other llvm code quality tools as I find them, and
> > play with formatter.  The problem I had was even compiler would not build
> > following the basic instructions with the mroute6?.h headers.
> >
> > Conceptually, if there's a code bit that drills into headers for very
> > platform specific things like ioctl, using autotool-like detection or
> > support of a narrowed platform set seems like a real design choice.  In the
> > event of picking the latter, maybe the top level build instructions should
> > provide a way to unplug "sanitizer" so the compiler itself can enjoy an
> > wider target range?
> >
> > Thank you.
> >
> > Mark
> >
> > On Wed, 17 Jul 2013 17:29:40 +0400
> > Alexey Samsonov <[hidden email]> wrote:
> >
> > > 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.
> > > 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...
> > >
> > >
> > > On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <[hidden email]>
> > wrote:
> > >
> > > > +samsonov
> > > >
> > > >
> > > > On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]
> > >wrote:
> > > >
> > > >> 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?
> > > >>
> > > >> 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
> > > >> http://lab.llvm.org:8011/buildslaves, 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.
> > > >>
> > > >> Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> > > >> ===================================================================
> > > >> --- lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> > (revision
> > > >> 186236)
> > > >> +++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> > (working
> > > >> copy)
> > > >> @@ -73,8 +73,11 @@
> > > >>  #include <linux/if_eql.h>
> > > >>  #include <linux/if_plip.h>
> > > >>  #include <linux/lp.h>
> > > >> +#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
> > > >> +#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> > > >>  #include <linux/mroute.h>
> > > >>  #include <linux/mroute6.h>
> > > >> +#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> > > >>  #include <linux/scc.h>
> > > >>  #include <linux/serial.h>
> > > >>  #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
> > > >> @@ -279,7 +282,7 @@
> > > >>    unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
> > > >>  #endif
> > > >>
> > > >> -#if !SANITIZER_ANDROID
> > > >> +#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> > > >>    unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
> > > >>    unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
> > > >>  #endif
> > > >> @@ -330,7 +333,7 @@
> > > >>    unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
> > > >>    unsigned IOCTL_TIOCSTI = TIOCSTI;
> > > >>    unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
> > > >> -#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
> > > >> +#if (SANITIZER_LINUX && !SANITIZER_ANDROID &&
> > > >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
> > > >>    unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
> > > >>    unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
> > > >>  #endif
> > > >>
> > > >> 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
> > > >>
> > http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html
> > ;
> > > >> but this is well outside my sweet spot.
> > > >>
> > > >> Thank you.
> > > >>
> > > >> Mark
> > > >>
> > > >>
> > > >> On Sat, 13 Jul 2013 15:15:33 -0700
> > > >> Mark Deric <[hidden email]> wrote:
> > > >>
> > > >> > This is the same issue as reported in the "Trouble compiling CLANG
> > on on
> > > >> > RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.
> >  Afaict,
> > > >> the
> > > >> > bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> > > >> > [sanitizer] ioctl interceptor"; though that's from code inspection,
> > not
> > > >> > from having tried the immediate predecessor.  The Clang 3.3
> > certainly
> > > >> > builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the
> > > >> distro's
> > > >> > stock gcc 4.1.2.  I did not automate the SVN checkout and build
> > until 24
> > > >> > June and have been getting this bust since then; here's last night's
> > > >> try:
> > > >> >
> > > >> > 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:
> > > >> > In file included from /usr/include/linux/mroute.h:5:
> > > >> > /usr/include/linux/in.h:26:3: error: redefinition of enumerator
> > > >> 'IPPROTO_IP'
> > > >> >   IPPROTO_IP = 0,               /* Dummy protocol for TCP
> > > >> */
> > > >> >   ^
> > > >> > /usr/include/netinet/in.h:34:21: note: expanded from macro
> > 'IPPROTO_IP'
> > > >> > #define IPPROTO_IP              IPPROTO_IP
> > > >> >                                 ^
> > > >> > /usr/include/netinet/in.h:33:5: note: previous definition is here
> > > >> >     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
> > > >> >     ^
> > > >> >
> > > >> > IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other
> > manifest
> > > >> > constants/enums collide in later messages.  Further, if the build
> > got by
> > > >> > this issue, I think it would land on the rocks again with the
> > subsequent
> > > >> > include of <linux/mroute6.h> on the next line of
> > > >> > sanitizer_platform_limits_posix.cc since that file does not exist
> > in the
> > > >> > CentOS/RHEL 5 distribution.
> > > >> >
> > > >> > I did a code check of these headers on Ubuntu 12.04 and the
> > organization
> > > >> > seems updated and consistent with the compiler-rt sanitizer code.
> >  It
> > > >> also
> > > >> > appears as though there is some effort to do OS/platform detection
> > using
> > > >> > manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But
> > these
> > > >> are
> > > >> > based on things like "#if defined(__linux__)" and do not appear to
> > be
> > > >> > granular enough to accomodate the header differences among Linux'es.
> > > >> >
> > > >> > I'm a newbie to building/using and looking at Clang so I don't know
> > the
> > > >> > idioms for OS/platform detection or the consumer side of sanitizer;
> > and
> > > >> I
> > > >> > suspect fixups in those areas are the right way to address this
> > bust.
> > > >> >
> > > >> > +eugenis following Kostya Serebryany's lead
> > > >> >
> > > >> > --
> > > >> > Mark Deric <[hidden email]>
> > > >> > _______________________________________________
> > > >> > cfe-dev mailing list
> > > >> > [hidden email]
> > > >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > > >>
> > > >>
> > > >> --
> > > >> Mark Deric <[hidden email]>
> > > >> _______________________________________________
> > > >> cfe-dev mailing list
> > > >> [hidden email]
> > > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> > > >>
> > > >
> > > >
> > >
> > >
> > > --
> > > Alexey Samsonov, MSK
> > >
> >
> >
> > --
> > Mark Deric <[hidden email]>
> >
>
>
>
> --
> Alexey Samsonov, MSK
>


--
Mark Deric <[hidden email]>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Evgeniy Stepanov-2
Hi,

sorry for the late response. First of all, any configure magic would
need to be replicated in cmake, as we have two build systems. That's
part of the reason we tend to do as much as possible right in the
source code.

I wonder if you could find out the minimal change to platform_limits
files to make them compile on your OS?

On Thu, Jul 18, 2013 at 10:37 AM, Mark Deric <[hidden email]> wrote:

> Thanks, Alexey.
>
> I would reiterate my willingness to put a piece of a modest RHEL5 machine in place as a buildbot slave if you could point me to the right person to get around the "builds now" requirement.  Hey, it's not just a 286, it has a great V35 modem capable of 56 kilobaud!  And I would have worked on finding some ac_helpful.m4 on mroute.h but, just as I was shutting down the fryer at my day job, this soccer team comes in ordering 31 super size.  Hate it when that happens.
>
> On Wed, 17 Jul 2013 18:18:23 +0400
> Alexey Samsonov <[hidden email]> wrote:
>
>> I see your point. We'll try to add header detection to our build system
>> soon.
>>
>>
>> On Wed, Jul 17, 2013 at 6:01 PM, Mark Deric <[hidden email]> wrote:
>>
>> > Kernel is pretty old, but it's the core of a wildly popular RHEL5
>> > distribution that's still getting kernel updates (i.e.,
>> > kernel-2.6.18-348.12.1.el5 as recently as last week!).  I think a bunch of
>> > 'nix shops are passing on RHEL6 awaiting 7, then there's the conversion
>> > period.  So, my guess is that RHEL5 will represent widespread active
>> > production machines for at least the next 24 months.
>> >
>> > On the "do I use sanitizers" question, the answer is not explicitly and/or
>> > not yet, being new to Clang.  I only use the compiler now, but I want to
>> > use static analyzer and other llvm code quality tools as I find them, and
>> > play with formatter.  The problem I had was even compiler would not build
>> > following the basic instructions with the mroute6?.h headers.
>> >
>> > Conceptually, if there's a code bit that drills into headers for very
>> > platform specific things like ioctl, using autotool-like detection or
>> > support of a narrowed platform set seems like a real design choice.  In the
>> > event of picking the latter, maybe the top level build instructions should
>> > provide a way to unplug "sanitizer" so the compiler itself can enjoy an
>> > wider target range?
>> >
>> > Thank you.
>> >
>> > Mark
>> >
>> > On Wed, 17 Jul 2013 17:29:40 +0400
>> > Alexey Samsonov <[hidden email]> wrote:
>> >
>> > > 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.
>> > > 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...
>> > >
>> > >
>> > > On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <[hidden email]>
>> > wrote:
>> > >
>> > > > +samsonov
>> > > >
>> > > >
>> > > > On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]
>> > >wrote:
>> > > >
>> > > >> 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?
>> > > >>
>> > > >> 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
>> > > >> http://lab.llvm.org:8011/buildslaves, 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.
>> > > >>
>> > > >> Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
>> > > >> ===================================================================
>> > > >> --- lib/sanitizer_common/sanitizer_platform_limits_posix.cc
>> > (revision
>> > > >> 186236)
>> > > >> +++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc
>> > (working
>> > > >> copy)
>> > > >> @@ -73,8 +73,11 @@
>> > > >>  #include <linux/if_eql.h>
>> > > >>  #include <linux/if_plip.h>
>> > > >>  #include <linux/lp.h>
>> > > >> +#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
>> > > >> +#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
>> > > >>  #include <linux/mroute.h>
>> > > >>  #include <linux/mroute6.h>
>> > > >> +#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
>> > > >>  #include <linux/scc.h>
>> > > >>  #include <linux/serial.h>
>> > > >>  #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
>> > > >> @@ -279,7 +282,7 @@
>> > > >>    unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
>> > > >>  #endif
>> > > >>
>> > > >> -#if !SANITIZER_ANDROID
>> > > >> +#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
>> > > >>    unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
>> > > >>    unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
>> > > >>  #endif
>> > > >> @@ -330,7 +333,7 @@
>> > > >>    unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
>> > > >>    unsigned IOCTL_TIOCSTI = TIOCSTI;
>> > > >>    unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
>> > > >> -#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
>> > > >> +#if (SANITIZER_LINUX && !SANITIZER_ANDROID &&
>> > > >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
>> > > >>    unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
>> > > >>    unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
>> > > >>  #endif
>> > > >>
>> > > >> 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
>> > > >>
>> > http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html
>> > ;
>> > > >> but this is well outside my sweet spot.
>> > > >>
>> > > >> Thank you.
>> > > >>
>> > > >> Mark
>> > > >>
>> > > >>
>> > > >> On Sat, 13 Jul 2013 15:15:33 -0700
>> > > >> Mark Deric <[hidden email]> wrote:
>> > > >>
>> > > >> > This is the same issue as reported in the "Trouble compiling CLANG
>> > on on
>> > > >> > RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.
>> >  Afaict,
>> > > >> the
>> > > >> > bust was introduced on 7 June in check in "[compiler-rt] r183517 -
>> > > >> > [sanitizer] ioctl interceptor"; though that's from code inspection,
>> > not
>> > > >> > from having tried the immediate predecessor.  The Clang 3.3
>> > certainly
>> > > >> > builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the
>> > > >> distro's
>> > > >> > stock gcc 4.1.2.  I did not automate the SVN checkout and build
>> > until 24
>> > > >> > June and have been getting this bust since then; here's last night's
>> > > >> try:
>> > > >> >
>> > > >> > 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:
>> > > >> > In file included from /usr/include/linux/mroute.h:5:
>> > > >> > /usr/include/linux/in.h:26:3: error: redefinition of enumerator
>> > > >> 'IPPROTO_IP'
>> > > >> >   IPPROTO_IP = 0,               /* Dummy protocol for TCP
>> > > >> */
>> > > >> >   ^
>> > > >> > /usr/include/netinet/in.h:34:21: note: expanded from macro
>> > 'IPPROTO_IP'
>> > > >> > #define IPPROTO_IP              IPPROTO_IP
>> > > >> >                                 ^
>> > > >> > /usr/include/netinet/in.h:33:5: note: previous definition is here
>> > > >> >     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
>> > > >> >     ^
>> > > >> >
>> > > >> > IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other
>> > manifest
>> > > >> > constants/enums collide in later messages.  Further, if the build
>> > got by
>> > > >> > this issue, I think it would land on the rocks again with the
>> > subsequent
>> > > >> > include of <linux/mroute6.h> on the next line of
>> > > >> > sanitizer_platform_limits_posix.cc since that file does not exist
>> > in the
>> > > >> > CentOS/RHEL 5 distribution.
>> > > >> >
>> > > >> > I did a code check of these headers on Ubuntu 12.04 and the
>> > organization
>> > > >> > seems updated and consistent with the compiler-rt sanitizer code.
>> >  It
>> > > >> also
>> > > >> > appears as though there is some effort to do OS/platform detection
>> > using
>> > > >> > manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But
>> > these
>> > > >> are
>> > > >> > based on things like "#if defined(__linux__)" and do not appear to
>> > be
>> > > >> > granular enough to accomodate the header differences among Linux'es.
>> > > >> >
>> > > >> > I'm a newbie to building/using and looking at Clang so I don't know
>> > the
>> > > >> > idioms for OS/platform detection or the consumer side of sanitizer;
>> > and
>> > > >> I
>> > > >> > suspect fixups in those areas are the right way to address this
>> > bust.
>> > > >> >
>> > > >> > +eugenis following Kostya Serebryany's lead
>> > > >> >
>> > > >> > --
>> > > >> > Mark Deric <[hidden email]>
>> > > >> > _______________________________________________
>> > > >> > cfe-dev mailing list
>> > > >> > [hidden email]
>> > > >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Mark Deric <[hidden email]>
>> > > >> _______________________________________________
>> > > >> cfe-dev mailing list
>> > > >> [hidden email]
>> > > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> > > >>
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Alexey Samsonov, MSK
>> > >
>> >
>> >
>> > --
>> > Mark Deric <[hidden email]>
>> >
>>
>>
>>
>> --
>> Alexey Samsonov, MSK
>>
>
>
> --
> Mark Deric <[hidden email]>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Mark Deric
Hi Evgeniy,

Now my apologies for being late; the day job's been pretty consuming but maybe I'm on the good side.  I'll look at the platform_limits files and see if I can help.

I'll keep you posted.

Thank you.

Mark


On Tue, 30 Jul 2013 15:16:42 +0400
Evgeniy Stepanov <[hidden email]> wrote:

> Hi,
>
> sorry for the late response. First of all, any configure magic would
> need to be replicated in cmake, as we have two build systems. That's
> part of the reason we tend to do as much as possible right in the
> source code.
>
> I wonder if you could find out the minimal change to platform_limits
> files to make them compile on your OS?
>
> On Thu, Jul 18, 2013 at 10:37 AM, Mark Deric <[hidden email]> wrote:
> > Thanks, Alexey.
> >
> > I would reiterate my willingness to put a piece of a modest RHEL5 machine in place as a buildbot slave if you could point me to the right person to get around the "builds now" requirement.  Hey, it's not just a 286, it has a great V35 modem capable of 56 kilobaud!  And I would have worked on finding some ac_helpful.m4 on mroute.h but, just as I was shutting down the fryer at my day job, this soccer team comes in ordering 31 super size.  Hate it when that happens.
> >
> > On Wed, 17 Jul 2013 18:18:23 +0400
> > Alexey Samsonov <[hidden email]> wrote:
> >
> >> I see your point. We'll try to add header detection to our build system
> >> soon.
> >>
> >>
> >> On Wed, Jul 17, 2013 at 6:01 PM, Mark Deric <[hidden email]> wrote:
> >>
> >> > Kernel is pretty old, but it's the core of a wildly popular RHEL5
> >> > distribution that's still getting kernel updates (i.e.,
> >> > kernel-2.6.18-348.12.1.el5 as recently as last week!).  I think a bunch of
> >> > 'nix shops are passing on RHEL6 awaiting 7, then there's the conversion
> >> > period.  So, my guess is that RHEL5 will represent widespread active
> >> > production machines for at least the next 24 months.
> >> >
> >> > On the "do I use sanitizers" question, the answer is not explicitly and/or
> >> > not yet, being new to Clang.  I only use the compiler now, but I want to
> >> > use static analyzer and other llvm code quality tools as I find them, and
> >> > play with formatter.  The problem I had was even compiler would not build
> >> > following the basic instructions with the mroute6?.h headers.
> >> >
> >> > Conceptually, if there's a code bit that drills into headers for very
> >> > platform specific things like ioctl, using autotool-like detection or
> >> > support of a narrowed platform set seems like a real design choice.  In the
> >> > event of picking the latter, maybe the top level build instructions should
> >> > provide a way to unplug "sanitizer" so the compiler itself can enjoy an
> >> > wider target range?
> >> >
> >> > Thank you.
> >> >
> >> > Mark
> >> >
> >> > On Wed, 17 Jul 2013 17:29:40 +0400
> >> > Alexey Samsonov <[hidden email]> wrote:
> >> >
> >> > > 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.
> >> > > 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...
> >> > >
> >> > >
> >> > > On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <[hidden email]>
> >> > wrote:
> >> > >
> >> > > > +samsonov
> >> > > >
> >> > > >
> >> > > > On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]
> >> > >wrote:
> >> > > >
> >> > > >> 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?
> >> > > >>
> >> > > >> 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
> >> > > >> http://lab.llvm.org:8011/buildslaves, 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.
> >> > > >>
> >> > > >> Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> > > >> ===================================================================
> >> > > >> --- lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> > (revision
> >> > > >> 186236)
> >> > > >> +++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc
> >> > (working
> >> > > >> copy)
> >> > > >> @@ -73,8 +73,11 @@
> >> > > >>  #include <linux/if_eql.h>
> >> > > >>  #include <linux/if_plip.h>
> >> > > >>  #include <linux/lp.h>
> >> > > >> +#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
> >> > > >> +#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >> > > >>  #include <linux/mroute.h>
> >> > > >>  #include <linux/mroute6.h>
> >> > > >> +#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >> > > >>  #include <linux/scc.h>
> >> > > >>  #include <linux/serial.h>
> >> > > >>  #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
> >> > > >> @@ -279,7 +282,7 @@
> >> > > >>    unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
> >> > > >>  #endif
> >> > > >>
> >> > > >> -#if !SANITIZER_ANDROID
> >> > > >> +#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
> >> > > >>    unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
> >> > > >>    unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
> >> > > >>  #endif
> >> > > >> @@ -330,7 +333,7 @@
> >> > > >>    unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
> >> > > >>    unsigned IOCTL_TIOCSTI = TIOCSTI;
> >> > > >>    unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
> >> > > >> -#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
> >> > > >> +#if (SANITIZER_LINUX && !SANITIZER_ANDROID &&
> >> > > >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
> >> > > >>    unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
> >> > > >>    unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
> >> > > >>  #endif
> >> > > >>
> >> > > >> 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
> >> > > >>
> >> > http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html
> >> > ;
> >> > > >> but this is well outside my sweet spot.
> >> > > >>
> >> > > >> Thank you.
> >> > > >>
> >> > > >> Mark
> >> > > >>
> >> > > >>
> >> > > >> On Sat, 13 Jul 2013 15:15:33 -0700
> >> > > >> Mark Deric <[hidden email]> wrote:
> >> > > >>
> >> > > >> > This is the same issue as reported in the "Trouble compiling CLANG
> >> > on on
> >> > > >> > RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.
> >> >  Afaict,
> >> > > >> the
> >> > > >> > bust was introduced on 7 June in check in "[compiler-rt] r183517 -
> >> > > >> > [sanitizer] ioctl interceptor"; though that's from code inspection,
> >> > not
> >> > > >> > from having tried the immediate predecessor.  The Clang 3.3
> >> > certainly
> >> > > >> > builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the
> >> > > >> distro's
> >> > > >> > stock gcc 4.1.2.  I did not automate the SVN checkout and build
> >> > until 24
> >> > > >> > June and have been getting this bust since then; here's last night's
> >> > > >> try:
> >> > > >> >
> >> > > >> > 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:
> >> > > >> > In file included from /usr/include/linux/mroute.h:5:
> >> > > >> > /usr/include/linux/in.h:26:3: error: redefinition of enumerator
> >> > > >> 'IPPROTO_IP'
> >> > > >> >   IPPROTO_IP = 0,               /* Dummy protocol for TCP
> >> > > >> */
> >> > > >> >   ^
> >> > > >> > /usr/include/netinet/in.h:34:21: note: expanded from macro
> >> > 'IPPROTO_IP'
> >> > > >> > #define IPPROTO_IP              IPPROTO_IP
> >> > > >> >                                 ^
> >> > > >> > /usr/include/netinet/in.h:33:5: note: previous definition is here
> >> > > >> >     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
> >> > > >> >     ^
> >> > > >> >
> >> > > >> > IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other
> >> > manifest
> >> > > >> > constants/enums collide in later messages.  Further, if the build
> >> > got by
> >> > > >> > this issue, I think it would land on the rocks again with the
> >> > subsequent
> >> > > >> > include of <linux/mroute6.h> on the next line of
> >> > > >> > sanitizer_platform_limits_posix.cc since that file does not exist
> >> > in the
> >> > > >> > CentOS/RHEL 5 distribution.
> >> > > >> >
> >> > > >> > I did a code check of these headers on Ubuntu 12.04 and the
> >> > organization
> >> > > >> > seems updated and consistent with the compiler-rt sanitizer code.
> >> >  It
> >> > > >> also
> >> > > >> > appears as though there is some effort to do OS/platform detection
> >> > using
> >> > > >> > manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But
> >> > these
> >> > > >> are
> >> > > >> > based on things like "#if defined(__linux__)" and do not appear to
> >> > be
> >> > > >> > granular enough to accomodate the header differences among Linux'es.
> >> > > >> >
> >> > > >> > I'm a newbie to building/using and looking at Clang so I don't know
> >> > the
> >> > > >> > idioms for OS/platform detection or the consumer side of sanitizer;
> >> > and
> >> > > >> I
> >> > > >> > suspect fixups in those areas are the right way to address this
> >> > bust.
> >> > > >> >
> >> > > >> > +eugenis following Kostya Serebryany's lead
> >> > > >> >
> >> > > >> > --
> >> > > >> > Mark Deric <[hidden email]>
> >> > > >> > _______________________________________________
> >> > > >> > cfe-dev mailing list
> >> > > >> > [hidden email]
> >> > > >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Mark Deric <[hidden email]>
> >> > > >> _______________________________________________
> >> > > >> cfe-dev mailing list
> >> > > >> [hidden email]
> >> > > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
> >> > > >>
> >> > > >
> >> > > >
> >> > >
> >> > >
> >> > > --
> >> > > Alexey Samsonov, MSK
> >> > >
> >> >
> >> >
> >> > --
> >> > Mark Deric <[hidden email]>
> >> >
> >>
> >>
> >>
> >> --
> >> Alexey Samsonov, MSK
> >>
> >
> >
> > --
> > Mark Deric <[hidden email]>


--
Mark Deric <[hidden email]>
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Evgeniy Stepanov-2
Well, I tried building clang on centos 5.9 and it did not go well.
Clang itself builds mostly fine, but the result is essentially
unusable because of incompatibilities with glibc headers.
There is a bunch of "extern inline" declarations in
"/usr/include/bits/string2.h". Because of the different semantics
between clang and gcc, they are emitted as publicly visible symbols in
every object file. As a result, linking fails with "multiple
definitions" errors. Newer glibc headers don't use "extern inline"
unless some magic GCC macros are defined.

How do people do it? Do I need to upgrade glibc? That sounds a bit scary.

On Sun, Aug 18, 2013 at 9:43 AM, Mark Deric <[hidden email]> wrote:

> Hi Evgeniy,
>
> Now my apologies for being late; the day job's been pretty consuming but maybe I'm on the good side.  I'll look at the platform_limits files and see if I can help.
>
> I'll keep you posted.
>
> Thank you.
>
> Mark
>
>
> On Tue, 30 Jul 2013 15:16:42 +0400
> Evgeniy Stepanov <[hidden email]> wrote:
>
>> Hi,
>>
>> sorry for the late response. First of all, any configure magic would
>> need to be replicated in cmake, as we have two build systems. That's
>> part of the reason we tend to do as much as possible right in the
>> source code.
>>
>> I wonder if you could find out the minimal change to platform_limits
>> files to make them compile on your OS?
>>
>> On Thu, Jul 18, 2013 at 10:37 AM, Mark Deric <[hidden email]> wrote:
>> > Thanks, Alexey.
>> >
>> > I would reiterate my willingness to put a piece of a modest RHEL5 machine in place as a buildbot slave if you could point me to the right person to get around the "builds now" requirement.  Hey, it's not just a 286, it has a great V35 modem capable of 56 kilobaud!  And I would have worked on finding some ac_helpful.m4 on mroute.h but, just as I was shutting down the fryer at my day job, this soccer team comes in ordering 31 super size.  Hate it when that happens.
>> >
>> > On Wed, 17 Jul 2013 18:18:23 +0400
>> > Alexey Samsonov <[hidden email]> wrote:
>> >
>> >> I see your point. We'll try to add header detection to our build system
>> >> soon.
>> >>
>> >>
>> >> On Wed, Jul 17, 2013 at 6:01 PM, Mark Deric <[hidden email]> wrote:
>> >>
>> >> > Kernel is pretty old, but it's the core of a wildly popular RHEL5
>> >> > distribution that's still getting kernel updates (i.e.,
>> >> > kernel-2.6.18-348.12.1.el5 as recently as last week!).  I think a bunch of
>> >> > 'nix shops are passing on RHEL6 awaiting 7, then there's the conversion
>> >> > period.  So, my guess is that RHEL5 will represent widespread active
>> >> > production machines for at least the next 24 months.
>> >> >
>> >> > On the "do I use sanitizers" question, the answer is not explicitly and/or
>> >> > not yet, being new to Clang.  I only use the compiler now, but I want to
>> >> > use static analyzer and other llvm code quality tools as I find them, and
>> >> > play with formatter.  The problem I had was even compiler would not build
>> >> > following the basic instructions with the mroute6?.h headers.
>> >> >
>> >> > Conceptually, if there's a code bit that drills into headers for very
>> >> > platform specific things like ioctl, using autotool-like detection or
>> >> > support of a narrowed platform set seems like a real design choice.  In the
>> >> > event of picking the latter, maybe the top level build instructions should
>> >> > provide a way to unplug "sanitizer" so the compiler itself can enjoy an
>> >> > wider target range?
>> >> >
>> >> > Thank you.
>> >> >
>> >> > Mark
>> >> >
>> >> > On Wed, 17 Jul 2013 17:29:40 +0400
>> >> > Alexey Samsonov <[hidden email]> wrote:
>> >> >
>> >> > > 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.
>> >> > > 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...
>> >> > >
>> >> > >
>> >> > > On Wed, Jul 17, 2013 at 1:04 PM, Kostya Serebryany <[hidden email]>
>> >> > wrote:
>> >> > >
>> >> > > > +samsonov
>> >> > > >
>> >> > > >
>> >> > > > On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <[hidden email]
>> >> > >wrote:
>> >> > > >
>> >> > > >> 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?
>> >> > > >>
>> >> > > >> 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
>> >> > > >> http://lab.llvm.org:8011/buildslaves, 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.
>> >> > > >>
>> >> > > >> Index: lib/sanitizer_common/sanitizer_platform_limits_posix.cc
>> >> > > >> ===================================================================
>> >> > > >> --- lib/sanitizer_common/sanitizer_platform_limits_posix.cc
>> >> > (revision
>> >> > > >> 186236)
>> >> > > >> +++ lib/sanitizer_common/sanitizer_platform_limits_posix.cc
>> >> > (working
>> >> > > >> copy)
>> >> > > >> @@ -73,8 +73,11 @@
>> >> > > >>  #include <linux/if_eql.h>
>> >> > > >>  #include <linux/if_plip.h>
>> >> > > >>  #include <linux/lp.h>
>> >> > > >> +#define SOMETIME_AFTER_LINUX_KERNEL_2_6_18 0 // 1 if newer distro
>> >> > > >> +#if SOMETIME_AFTER_LINUX_KERNEL_2_6_18
>> >> > > >>  #include <linux/mroute.h>
>> >> > > >>  #include <linux/mroute6.h>
>> >> > > >> +#endif // SOMETIME_AFTER_LINUX_KERNEL_2_6_18
>> >> > > >>  #include <linux/scc.h>
>> >> > > >>  #include <linux/serial.h>
>> >> > > >>  #endif // SANITIZER_LINUX && !SANITIZER_ANDROID
>> >> > > >> @@ -279,7 +282,7 @@
>> >> > > >>    unsigned struct_unimapinit_sz = sizeof(struct unimapinit);
>> >> > > >>  #endif
>> >> > > >>
>> >> > > >> -#if !SANITIZER_ANDROID
>> >> > > >> +#if !SANITIZER_ANDROID && SOMETIME_AFTER_LINUX_KERNEL_2_6_18
>> >> > > >>    unsigned struct_sioc_sg_req_sz = sizeof(struct sioc_sg_req);
>> >> > > >>    unsigned struct_sioc_vif_req_sz = sizeof(struct sioc_vif_req);
>> >> > > >>  #endif
>> >> > > >> @@ -330,7 +333,7 @@
>> >> > > >>    unsigned IOCTL_TIOCSPGRP = TIOCSPGRP;
>> >> > > >>    unsigned IOCTL_TIOCSTI = TIOCSTI;
>> >> > > >>    unsigned IOCTL_TIOCSWINSZ = TIOCSWINSZ;
>> >> > > >> -#if (SANITIZER_LINUX && !SANITIZER_ANDROID) || SANITIZER_MAC
>> >> > > >> +#if (SANITIZER_LINUX && !SANITIZER_ANDROID &&
>> >> > > >> SOMETIME_AFTER_LINUX_KERNEL_2_6_18) || SANITIZER_MAC
>> >> > > >>    unsigned IOCTL_SIOCGETSGCNT = SIOCGETSGCNT;
>> >> > > >>    unsigned IOCTL_SIOCGETVIFCNT = SIOCGETVIFCNT;
>> >> > > >>  #endif
>> >> > > >>
>> >> > > >> 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
>> >> > > >>
>> >> > http://mailman.icsi.berkeley.edu/pipermail/xorp-cvs/2009-September/011678.html
>> >> > ;
>> >> > > >> but this is well outside my sweet spot.
>> >> > > >>
>> >> > > >> Thank you.
>> >> > > >>
>> >> > > >> Mark
>> >> > > >>
>> >> > > >>
>> >> > > >> On Sat, 13 Jul 2013 15:15:33 -0700
>> >> > > >> Mark Deric <[hidden email]> wrote:
>> >> > > >>
>> >> > > >> > This is the same issue as reported in the "Trouble compiling CLANG
>> >> > on on
>> >> > > >> > RHEL 3.0" from 18 June.  It applies to CentOS/RHEL 5 as well.
>> >> >  Afaict,
>> >> > > >> the
>> >> > > >> > bust was introduced on 7 June in check in "[compiler-rt] r183517 -
>> >> > > >> > [sanitizer] ioctl interceptor"; though that's from code inspection,
>> >> > not
>> >> > > >> > from having tried the immediate predecessor.  The Clang 3.3
>> >> > certainly
>> >> > > >> > builds fine on CentOS/RHEL 5 using gcc upgraded to 4.8.1 from the
>> >> > > >> distro's
>> >> > > >> > stock gcc 4.1.2.  I did not automate the SVN checkout and build
>> >> > until 24
>> >> > > >> > June and have been getting this bust since then; here's last night's
>> >> > > >> try:
>> >> > > >> >
>> >> > > >> > 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:
>> >> > > >> > In file included from /usr/include/linux/mroute.h:5:
>> >> > > >> > /usr/include/linux/in.h:26:3: error: redefinition of enumerator
>> >> > > >> 'IPPROTO_IP'
>> >> > > >> >   IPPROTO_IP = 0,               /* Dummy protocol for TCP
>> >> > > >> */
>> >> > > >> >   ^
>> >> > > >> > /usr/include/netinet/in.h:34:21: note: expanded from macro
>> >> > 'IPPROTO_IP'
>> >> > > >> > #define IPPROTO_IP              IPPROTO_IP
>> >> > > >> >                                 ^
>> >> > > >> > /usr/include/netinet/in.h:33:5: note: previous definition is here
>> >> > > >> >     IPPROTO_IP = 0,        /* Dummy protocol for TCP.  */
>> >> > > >> >     ^
>> >> > > >> >
>> >> > > >> > IPPROTO_ICMP, IPPROTO_IGMP, IPPROTO_TCP and a number of other
>> >> > manifest
>> >> > > >> > constants/enums collide in later messages.  Further, if the build
>> >> > got by
>> >> > > >> > this issue, I think it would land on the rocks again with the
>> >> > subsequent
>> >> > > >> > include of <linux/mroute6.h> on the next line of
>> >> > > >> > sanitizer_platform_limits_posix.cc since that file does not exist
>> >> > in the
>> >> > > >> > CentOS/RHEL 5 distribution.
>> >> > > >> >
>> >> > > >> > I did a code check of these headers on Ubuntu 12.04 and the
>> >> > organization
>> >> > > >> > seems updated and consistent with the compiler-rt sanitizer code.
>> >> >  It
>> >> > > >> also
>> >> > > >> > appears as though there is some effort to do OS/platform detection
>> >> > using
>> >> > > >> > manifest constants SANITIZER_LINUX, SANITIZER_ANDROID, etc.  But
>> >> > these
>> >> > > >> are
>> >> > > >> > based on things like "#if defined(__linux__)" and do not appear to
>> >> > be
>> >> > > >> > granular enough to accomodate the header differences among Linux'es.
>> >> > > >> >
>> >> > > >> > I'm a newbie to building/using and looking at Clang so I don't know
>> >> > the
>> >> > > >> > idioms for OS/platform detection or the consumer side of sanitizer;
>> >> > and
>> >> > > >> I
>> >> > > >> > suspect fixups in those areas are the right way to address this
>> >> > bust.
>> >> > > >> >
>> >> > > >> > +eugenis following Kostya Serebryany's lead
>> >> > > >> >
>> >> > > >> > --
>> >> > > >> > Mark Deric <[hidden email]>
>> >> > > >> > _______________________________________________
>> >> > > >> > cfe-dev mailing list
>> >> > > >> > [hidden email]
>> >> > > >> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >> > > >>
>> >> > > >>
>> >> > > >> --
>> >> > > >> Mark Deric <[hidden email]>
>> >> > > >> _______________________________________________
>> >> > > >> cfe-dev mailing list
>> >> > > >> [hidden email]
>> >> > > >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>> >> > > >>
>> >> > > >
>> >> > > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > Alexey Samsonov, MSK
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Mark Deric <[hidden email]>
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> Alexey Samsonov, MSK
>> >>
>> >
>> >
>> > --
>> > Mark Deric <[hidden email]>
>
>
> --
> Mark Deric <[hidden email]>

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev