[jira] [Updated] (HDFS-1619) Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ?
[ https://issues.apache.org/jira/browse/HDFS-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shaposhnik updated HDFS-1619: --- Attachment: HDFS-1619-C99.patch.txt Agreed. Minor nitpick, I think we should replace AC_PROG_CC with AC_PROG_CC_C99 not add an extra check. Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ? -- Key: HDFS-1619 URL: https://issues.apache.org/jira/browse/HDFS-1619 Project: Hadoop HDFS Issue Type: Improvement Reporter: Roman Shaposhnik Assignee: Konstantin Shvachko Attachments: HDFS-1619-C99.patch.txt, HDFS-1619.patch.txt, hdfs-1619-2.patch Currently configure.ac uses AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T and thus requires autoconf 2.61 or higher. This prevents using it on such platforms as CentOS/RHEL 5.4 and 5.5. Given that those are pretty popular and also given that it is really difficult to find a platform these days that doesn't natively define intXX_t types I'm curious as to whether we can simply remove those macros or perhaps fail ONLY if we happen to be on such a platform. Here's a link to GNU autoconf docs for your reference: http://www.gnu.org/software/hello/manual/autoconf/Particular-Types.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1619) Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ?
[ https://issues.apache.org/jira/browse/HDFS-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eli Collins updated HDFS-1619: -- Component/s: libhdfs Fix Version/s: 0.22.0 Assignee: Roman Shaposhnik (was: Konstantin Shvachko) Hadoop Flags: [Reviewed] Good point. (and per previous comments we can introduce AC_PROG_CC_C99 when we actually require it). +1 to HDFS-1619.patch.txt Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ? -- Key: HDFS-1619 URL: https://issues.apache.org/jira/browse/HDFS-1619 Project: Hadoop HDFS Issue Type: Improvement Components: libhdfs Reporter: Roman Shaposhnik Assignee: Roman Shaposhnik Fix For: 0.22.0 Attachments: HDFS-1619-C99.patch.txt, HDFS-1619.patch.txt, hdfs-1619-2.patch Currently configure.ac uses AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T and thus requires autoconf 2.61 or higher. This prevents using it on such platforms as CentOS/RHEL 5.4 and 5.5. Given that those are pretty popular and also given that it is really difficult to find a platform these days that doesn't natively define intXX_t types I'm curious as to whether we can simply remove those macros or perhaps fail ONLY if we happen to be on such a platform. Here's a link to GNU autoconf docs for your reference: http://www.gnu.org/software/hello/manual/autoconf/Particular-Types.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1619) Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ?
[ https://issues.apache.org/jira/browse/HDFS-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eli Collins updated HDFS-1619: -- Attachment: hdfs-1619-2.patch bq. IIRC, using // is a comment for C code is defined as a standard in C99. So yes, we do use C99 features in libhdfs. gcc's default std (gnu89) permits some extensions like C++ style comments (most compilers introduced this well before 1999). libhdfs compiles fine with -std=gnu89 -pedantic. In any case, using c99 features in libhdfs is totally reasonable so we might as well indicate it's required. I think we're all in agreement that Roman's patch plus using AC_PROG_CC_C99 is acceptable. Any objections to hdfs-1619-2.patch? Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ? -- Key: HDFS-1619 URL: https://issues.apache.org/jira/browse/HDFS-1619 Project: Hadoop HDFS Issue Type: Improvement Reporter: Roman Shaposhnik Assignee: Konstantin Shvachko Attachments: HDFS-1619.patch.txt, hdfs-1619-2.patch Currently configure.ac uses AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T and thus requires autoconf 2.61 or higher. This prevents using it on such platforms as CentOS/RHEL 5.4 and 5.5. Given that those are pretty popular and also given that it is really difficult to find a platform these days that doesn't natively define intXX_t types I'm curious as to whether we can simply remove those macros or perhaps fail ONLY if we happen to be on such a platform. Here's a link to GNU autoconf docs for your reference: http://www.gnu.org/software/hello/manual/autoconf/Particular-Types.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1619) Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ?
[ https://issues.apache.org/jira/browse/HDFS-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shaposhnik updated HDFS-1619: --- Status: Patch Available (was: Open) Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ? -- Key: HDFS-1619 URL: https://issues.apache.org/jira/browse/HDFS-1619 Project: Hadoop HDFS Issue Type: Improvement Reporter: Roman Shaposhnik Assignee: Konstantin Shvachko Attachments: HDFS-1619.patch.txt Currently configure.ac uses AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T and thus requires autoconf 2.61 or higher. This prevents using it on such platforms as CentOS/RHEL 5.4 and 5.5. Given that those are pretty popular and also given that it is really difficult to find a platform these days that doesn't natively define intXX_t types I'm curious as to whether we can simply remove those macros or perhaps fail ONLY if we happen to be on such a platform. Here's a link to GNU autoconf docs for your reference: http://www.gnu.org/software/hello/manual/autoconf/Particular-Types.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (HDFS-1619) Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ?
[ https://issues.apache.org/jira/browse/HDFS-1619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Shaposhnik updated HDFS-1619: --- Attachment: HDFS-1619.patch.txt This trivial patch bites the bullet and removes the dependency on newer autoconf and on AC_TYPE_INTXX macros. The logic here is this -- on all platforms with conformant C99 compilers these macros are useless anyway, on platforms where C99 compiler is NOT available libhdfs is unlikely to compile even when these macros are present. Does libhdfs really need to depend on AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T ? -- Key: HDFS-1619 URL: https://issues.apache.org/jira/browse/HDFS-1619 Project: Hadoop HDFS Issue Type: Improvement Reporter: Roman Shaposhnik Assignee: Konstantin Shvachko Attachments: HDFS-1619.patch.txt Currently configure.ac uses AC_TYPE_INT16_T, AC_TYPE_INT32_T, AC_TYPE_INT64_T and AC_TYPE_UINT16_T and thus requires autoconf 2.61 or higher. This prevents using it on such platforms as CentOS/RHEL 5.4 and 5.5. Given that those are pretty popular and also given that it is really difficult to find a platform these days that doesn't natively define intXX_t types I'm curious as to whether we can simply remove those macros or perhaps fail ONLY if we happen to be on such a platform. Here's a link to GNU autoconf docs for your reference: http://www.gnu.org/software/hello/manual/autoconf/Particular-Types.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
