[cfe-dev] CentOS 5.9 build bust: rt sanitizer & incompatible TCP/IP headers

Alexey Samsonov samsonov at google.com
Wed Jul 17 06:29:40 PDT 2013 

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 <kcc at google.com> wrote:

> +samsonov
>
>
> On Mon, Jul 15, 2013 at 12:04 PM, Mark Deric <codetech at dericnet.com>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 <codetech at dericnet.com> 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 <codetech at dericnet.com>
>> > _______________________________________________
>> > cfe-dev mailing list
>> > cfe-dev at cs.uiuc.edu
>> > http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>>
>> --
>> Mark Deric <codetech at dericnet.com>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>>
>
>


-- 
Alexey Samsonov, MSK
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130717/fbb74b8f/attachment.html>

More information about the cfe-dev mailing list