openssl.inc: avoid random ptest failures

"make alltests" is sensitive to the timestamps of the installed files. Depending on the order in which cp copies files, .o and/or executables may end up with time stamps older than the source files. Running tests then triggers recompilation attempts, which typically will fail because dev tools and files are not installed.

"cp -a" is not enough because the files also have to be newer than the installed header files. Setting the file time stamps to the current time explicitly after copying solves the problem because do_install_ptest_base is guaranteed to run after do_install.

---
 meta/recipes-connectivity/openssl/openssl.inc | 13 +++++++++++++
 1 file changed, 13 insertions(+)

index f83664c..a632d8a 100644
@@ -215,6 +215,19 @@ do_install_ptest () {
 	mkdir -p ${D}${PTEST_PATH}/util
 	install util/opensslwrap.sh    ${D}${PTEST_PATH}/util
 	install util/shlib_wrap.sh     ${D}${PTEST_PATH}/util
+	# Time stamps are relevant for "make alltests", otherwise
+	# make may try to recompile binaries. Not only must the
+	# binary files be newer than the sources, they also must
+	# be more recent than the header files in /usr/include.
+	#
+	# Using "cp -a" is not sufficient, because do_install
+	# does not preserve the original time stamps.
+	#
+	# So instead of using the original file stamps, we set
+	# the current time for all files. Binaries will get
+	# modified again later when stripping them, but that's okay.
+	touch ${D}${PTEST_PATH}
+	find ${D}${PTEST_PATH} -type f -print0 | xargs --verbose -0 touch -r ${D}${PTEST_PATH}
 }
 
 do_install_append_class-native() {

2.1.4

Patch 2/2 hasn't arrived.

Alex

Hello!

This patch can be applied stand-alone. I had it in a branch together with the 1.0.2i update and then didn't export it independently, hence the erroneous "PATCH 1/2" in the subject.

Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.