Bug 1284428 - libreswan fails to build on s390 architecture
libreswan fails to build on s390 architecture
Product: Fedora
Classification: Fedora
Component: libreswan (Show other bugs)
s390 Linux
unspecified Severity unspecified
: ---
: ---
Assigned To: Paul Wouters
Fedora Extras Quality Assurance
Depends On: 1284884
Blocks: ZedoraTracker
  Show dependency treegraph
Reported: 2015-11-23 05:22 EST by Sinny Kumari
Modified: 2016-01-21 10:16 EST (History)
2 users (show)

See Also:
Fixed In Version: libreswan-3.16-1.fc22
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2016-01-21 10:16:36 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Sinny Kumari 2015-11-23 05:22:45 EST
Description of problem:
Latest version of package libreswan fails to build on F21 and F22 for s390 architecture.
From the build log, following is the error message:

/builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2_parent.c: In function 'ikev2_verify_and_decrypt_sk_payload':
/builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2_parent.c:1594:10: error: format '%zu' expects argument of type 'size_t', but argument 2 has type 'int' [-Werror=format=]
          payload_end - wire_iv_start);
/builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2_parent.c: In function 'process_encrypted_informational_ikev2':
/builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2_parent.c:4068:7: error: format '%tu' expects argument of type 'unsigned ptrdiff_t', but argument 2 has type 'long unsigned int' [-Werror=format=]
       v2del->isad_nrspi * v2del->isad_spisize);

By looking into error messages, it appears that format specifier doesn't match with the variable type passed to printf() function arguments.

koji build log link
F21 - http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1991454
F22 - http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1991945

Version-Release number of selected component (if applicable): libreswan-3.15-1.fc21 and libreswan-3.15-1.fc22
Comment 1 Sinny Kumari 2015-11-23 05:34:02 EST
Locally, I modified format specifier at line 1593 from %zu to %d and at line 4066 from %tu to %zu . After modification build works fine on s390 machine but now it fails on s390x with following error message:
/builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2_parent.c: In function 'ikev2_verify_and_decrypt_sk_payload':
/builddir/build/BUILD/libreswan-3.15/programs/pluto/ikev2_parent.c:1593:17: error: format '%d' expects argument of type 'int', but argument 2 has type 'long int' [-Werror=format=]
   libreswan_log("encrypted payload impossibly short (%d)",

From the behavior of error message, it appears that data type of variable is changing with architecture change. On S390, variable expects an int format specifier while on s390x, it expects long int.
I see one of the solution here which is to add a conditional macro in source file ikev2_parent.c if build arch is s390.

F22 koji scratch build link with modification: http://s390.koji.fedoraproject.org/koji/taskinfo?taskID=1992034
Comment 2 Paul Wouters 2015-11-23 15:27:02 EST
I believe this is fixed in upstream already, and should be part of 3.16 when it is released.
Comment 3 Sinny Kumari 2015-11-24 03:12:24 EST
Ah yes! after checking libreswan master code, found that it has already been fixed with commit https://github.com/libreswan/libreswan/commit/03beaf73b3cbc52eb351d950b07cd2a58c569813 . After applying this fix, build works fine on s390 along with other architectures.

I couldn't find upcoming release date of 3.16 on its official webpage https://libreswan.org/ . Any idea when next release is lined up?
Comment 4 Paul Wouters 2015-11-24 10:45:17 EST
we are looking at 2-3 bugs to resolve before doing the 3.16 release. Hopefully in a day or 2?
Comment 5 Dan Horák 2015-11-24 11:00:15 EST
sounds good, no need for patching of older releases then, thanks.
Comment 6 Sinny Kumari 2015-11-25 01:08:48 EST
Good to know that 3.16 release is just 2 days behind.

Note You need to log in before you can comment on or make changes to this bug.