Hi,
I am building CAMotics with cbang builds successfully for i686 and x86_64 platforms, I am trying to make it work for other architectures, in particular armv7 and ppc64 (there is no v8-314 available for others).
So while testing fixes on copr I've stumbled upon an issue of what I am not sure about, the build for ppc64le pass for f24-f27 but fails on epel7.
src/cbang/tar/TarHeader.cpp:226:43: error: format '%llo' expects argument of type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' [-Werror=format=] sprintf(buf, "%0*" PRIo64, length - 1, n); ^
copr test: https://copr.fedorainfracloud.org/coprs/srakitnican/ppc64le-tests/build/5763... cbang: https://github.com/CauldronDevelopmentLLC/cbang/
Is this really an issue in cbang?
Best regards, Samuel Raktiničan
Am 06.07.2017 um 10:14 schrieb Samuel Rakitničan:
Hi,
I am building CAMotics with cbang builds successfully for i686 and x86_64 platforms, I am trying to make it work for other architectures, in particular armv7 and ppc64 (there is no v8-314 available for others).
So while testing fixes on copr I've stumbled upon an issue of what I am not sure about, the build for ppc64le pass for f24-f27 but fails on epel7.
src/cbang/tar/TarHeader.cpp:226:43: error: format '%llo' expects argument of type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' [-Werror=format=] sprintf(buf, "%0*" PRIo64, length - 1, n); ^
copr test: https://copr.fedorainfracloud.org/coprs/srakitnican/ppc64le-tests/build/5763... cbang: https://github.com/CauldronDevelopmentLLC/cbang/
Is this really an issue in cbang?
Best regards, Samuel Raktiničan
Patch that line to read `sprintf(buf, "%0*" PRIo64, static_cast<long long unsigned int>(length - 1), n);` and you're cool. It might be related to how that particular gcc version in EPEL7 inherits those atomic data-types.
On 07/06/2017 02:28 AM, Björn 'besser82' Esser wrote:
Am 06.07.2017 um 10:14 schrieb Samuel Rakitničan:
src/cbang/tar/TarHeader.cpp:226:43: error: format '%llo' expects argument of type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' [-Werror=format=] sprintf(buf, "%0*" PRIo64, length - 1, n); ^
Patch that line to read `sprintf(buf, "%0*" PRIo64, static_cast<long long unsigned int>(length - 1), n);` and you're cool. It might be related to how that particular gcc version in EPEL7 inherits those atomic data-types.
Argument 4 is the "n". The problem is with the definition of "PRIo64. There was a recent commit attempting to fix that, but it probably needs some adjustment to handle your case. Check out the lines around line 48 in that file and see if you can patch it to work in all cases. The odd thing is that it only doesn't work on epel7. I guess you need to compare how old the compiler is on there compared to the Fedora versions.
Argument 4 is the "n". The problem is with the definition of "PRIo64. There was a recent commit attempting to fix that, but it probably needs some adjustment to handle your case. Check out the lines around line 48 in that file and see if you can patch it to work in all cases. The odd thing is that it only doesn't work on epel7. I guess you need to compare how old the compiler is on there compared to the Fedora versions.
So Joseph and I managed to fix this for epel7 with following patch:
src/cbang/tar/TarHeader.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/cbang/tar/TarHeader.cpp b/src/cbang/tar/TarHeader.cpp index 470b37c..50df710 100644 --- a/src/cbang/tar/TarHeader.cpp +++ b/src/cbang/tar/TarHeader.cpp @@ -45,7 +45,8 @@ #endif
#ifndef PRIo64 -#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__)) +#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__)) || \ + defined(__aarch64__) || defined(__ppc64__) || defined(__PPC64__) #define PRIo64 "lo" #else #define PRIo64 "llo"
It seems GCC 4.8 needs these macros defined explicitly, while GCC > 6 inherits it from something else (_M_X64 perhaps?), thoughts?
On Wed, 12 Jul 2017 08:17:46 -0000 Samuel Rakitničan srakitnican@fedoraproject.org wrote:
Argument 4 is the "n". The problem is with the definition of "PRIo64. There was a recent commit attempting to fix that, but it probably needs some adjustment to handle your case. Check out the lines around line 48 in that file and see if you can patch it to work in all cases. The odd thing is that it only doesn't work on epel7. I guess you need to compare how old the compiler is on there compared to the Fedora versions.
So Joseph and I managed to fix this for epel7 with following patch:
src/cbang/tar/TarHeader.cpp | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/src/cbang/tar/TarHeader.cpp b/src/cbang/tar/TarHeader.cpp index 470b37c..50df710 100644 --- a/src/cbang/tar/TarHeader.cpp +++ b/src/cbang/tar/TarHeader.cpp @@ -45,7 +45,8 @@ #endif
#ifndef PRIo64 -#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__)) +#if defined(_M_X64) || (defined(__x86_64__) && !defined(__ILP32__)) || \
- defined(__aarch64__) || defined(__ppc64__) || defined(__PPC64__)
#define PRIo64 "lo" #else #define PRIo64 "llo"
It seems GCC 4.8 needs these macros defined explicitly, while GCC > 6 inherits it from something else (_M_X64 perhaps?), thoughts?
I guess it depends if (and how) inttypes.h header gets included, it's provided by glibc.
Dan
Patch that line to read `sprintf(buf, "%0*" PRIo64, static_cast<long long unsigned int>(length - 1), n);` and you're cool. It might be related to how that particular gcc version in EPEL7 inherits those atomic data-types.
I've tried with that and this is what I get.
src/cbang/tar/TarHeader.cpp:226:80: error: field width specifier '*' expects argument of type 'int', but argument 3 has type 'long long unsigned int' [-Werror=format=] sprintf(buf, "%0*" PRIo64, static_cast<long long unsigned int>(length - 1), n); ^ src/cbang/tar/TarHeader.cpp:226:80: error: format '%llo' expects argument of type 'long long unsigned int', but argument 4 has type 'uint64_t {aka long unsigned int}' [-Werror=format=]
I've also sent a mail to ppc lists seems there is an issue somewhere in that platform.
Argument 4 is the "n".
Right, if I adapt the fix for 4th argument, that works.
The problem is with the definition of "PRIo64. There was a recent commit attempting to fix that, but it probably needs some adjustment to handle your case. Check out the lines around line 48 in that file and see if you can patch it to work in all cases. The odd thing is that it only doesn't work on epel7. I guess you need to compare how old the compiler is on there compared to the Fedora versions.
Not sure how to fix this myself, I've notified program author and he thinks that the code should work [1]. So I've emailed ppc list [2].
[1] https://github.com/CauldronDevelopmentLLC/cbang/issues/21#issuecomment-31377... [2] https://lists.fedoraproject.org/archives/list/ppc@lists.fedoraproject.org/th...
I guess it depends if (and how) inttypes.h header gets included, it's provided by glibc.
Dan
Find out some more information, do in both Fedora and EPEL __STDC_FORMAT_MACROS is not defined. The difference is in following patch:
https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=sysdeps/generic/inttype...