openssl: fix race condition when symlink shared libs

The build-shared target depends on do_crypto and link-shared, which will be executed in parallel. do_crypto calls link_a.linux_shared -> link_a.gnu which does SYMLINK_SO; in parallel, link-shared calls symlink.linux_shared which also does SYMLINK_SO. Before the symlink is created, it is rm'ed, but there is a tiny chance that the second one is created after the rm has been called.

Fix this by using 'ln -sf' instead of 'ln -s' so the build doesn't error out.

Patch submitted upstream at:
https://bugs.gentoo.org/show_bug.cgi?id=566260

All,

Quoted 7 lines · Ryan Barnett

The build-shared target depends on do_crypto and link-shared, which will be executed in parallel. do_crypto calls link_a.linux_shared -> link_a.gnu which does SYMLINK_SO; in parallel, link-shared calls symlink.linux_shared which also does SYMLINK_SO. Before the symlink is created, it is rm'ed, but there is a tiny chance that the second one is created after the rm has been called.

Quoted 5 lines

Fix this by using 'ln -sf' instead of 'ln -s' so the build doesn't error out.

Patch submitted upstream at:
https://bugs.gentoo.org/show_bug.cgi?id=566260

So it doesn't appear that using 'ln -sf' is a valid fix as pointed out in the bug report on the gentoo forum:

-- Comment #2 from SpanKY <[email protected]> ---
ln -sf is no more atomic than rm; ln. there is still a window where things can fail. you can easily check this:

   i=0; while [ $((i++)) -lt 500 ]; do ln -sf a b & :; done

a good number of those will fail with:
ln: failed to create symbolic link ?b?: File exists

the deps need to be fixed up

So how do we want to proceed with this? Do we revert the patch for parallel builds for openssl?

Thanks,
-Ryan

The build-shared target depends on do_crypto and link-shared, which will be executed in parallel. do_crypto calls link_a.linux_shared -> link_a.gnu which does SYMLINK_SO; in parallel, link-shared calls symlink.linux_shared which also does SYMLINK_SO. Before the symlink is created, it is rm'ed, but there is a tiny chance that the second one is created after the rm has been called.

Fix this by using 'ln -sf' instead of 'ln -s' so the build doesn't error out.

Patch submitted upstream at:
https://bugs.gentoo.org/show_bug.cgi?id=566260

Thanks to Arnout for explain the issue (wording used above).

Signed-off-by Ryan Barnett <[email protected]>

CC Arnout Vandecappelle <[email protected]>

CC Thomas Petazzoni <[email protected]>

---

Note this is a temporary fix until a gentoo maintainer weighs in and updates their parallel build patch.

v1 -> v2
Remove the 'rm -f' since we are using 'ln -sf' (Arnout originally)

---
 ...ared-fix-race-condition-when-symlinking-s.patch | 48 ++++++++++++++++++++++
 1 file changed, 48 insertions(+)
 create mode 100644 package/openssl/0003-makefile.shared-fix-race-condition-when-symlinking-s.patch

package/openssl/0003-makefile.shared-fix-race-condition-when-symlinking-s.patch new file +5 -0

new file mode 100644
index 0000000..d6672f4
@@ -0,0 +1,48 @@
+From 878793890a9b84ff313397c56478d7c6f770b2d2 Mon Sep 17 00:00:00 2001
+From: Ryan Barnett <[email protected]>
+Date: Thu, 19 Nov 2015 10:47:00 -0600
+Subject: [PATCH] makefile.shared: fix race condition when symlinking shared
+ libs

package/openssl/0003-makefile.shared-fix-race-condition-when-symlinking-s.patch new file +13 -0

+
+Signed-off-by: Ryan Barnett <[email protected]>
+---
+ Makefile.shared | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/Makefile.shared b/Makefile.shared
+index 8d57163..8ab3d18 100644
+--- a/Makefile.shared
++++ b/Makefile.shared
+@@ -117,15 +117,15 @@ SYMLINK_SO=	\
+ 		prev=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \
+ 		if [ -n "$$SHLIB_COMPAT" ]; then \

package/openssl/0003-makefile.shared-fix-race-condition-when-symlinking-s.patch new file +10 -0

+-			( $(SET_X); rm -f $$SHLIB$$SHLIB_SUFFIX; \
+-			  ln -s $$prev $$SHLIB$$SHLIB_SUFFIX ); \
++			( $(SET_X); \
++			  ln -sf $$prev $$SHLIB$$SHLIB_SUFFIX ); \
+ 		fi; \
+ 	fi
+ 
+-- 
+1.9.1
+

Quoted 7 lines · Ryan Barnett

The build-shared target depends on do_crypto and link-shared, which will be executed in parallel. do_crypto calls link_a.linux_shared -> link_a.gnu which does SYMLINK_SO; in parallel, link-shared calls symlink.linux_shared which also does SYMLINK_SO. Before the symlink is created, it is rm'ed, but there is a tiny chance that the second one is created after the rm has been called.

Quoted 5 lines

Fix this by using 'ln -sf' instead of 'ln -s' so the build doesn't error out.

Patch submitted upstream at:
https://bugs.gentoo.org/show_bug.cgi?id=566260

Ahem, gentoo is not exactly upstream :-) From [1]:

To report a bug or make an enhancement request, send email to rt at openssl.org. In the subject line, please make sure to indicate if it's a bug or a fix, and a brief description of the issue. In the body of your mail, please include the versions of the operating system and OpenSSL you are using. If you have a patch or diff, please send it as an attachment, and not inline in the message body.

As far as I can see, this patch should still apply (in slightly adapted form)
to the real upstream.

Quoted 2 lines

Thanks to Arnout for explain the issue (wording used above).

You're a native English speaker, right? explain -> explaining :-)

Quoted 10 lines · Ryan Barnett

The build-shared target depends on do_crypto and link-shared, which will be executed in parallel. do_crypto calls link_a.linux_shared -> link_a.gnu which does SYMLINK_SO; in parallel, link-shared calls symlink.linux_shared which also does SYMLINK_SO. Before the symlink is created, it is rm'ed, but there is a tiny chance that the second one is created after the rm has been called.

Fix this by using 'ln -sf' instead of 'ln -s' so the build doesn't error out.

Quoted 2 lines

Patch submitted upstream at:
https://bugs.gentoo.org/show_bug.cgi?id=566260

Ahem, gentoo is not exactly upstream :-) From [1]:

To report a bug or make an enhancement request, send email to rt at openssl.org.