https://koji.fedoraproject.org/koji/taskinfo?taskID=17259189 + mv 'swipl-7.2.3/lib/*/libjpl.so' swipl-jpl/ mv: cannot stat 'swipl-7.2.3/lib/*/libjpl.so': No such file or directory
The real failure is: gcc -shared -rdynamic -Wl,--enable-new-dtags -pthread -Wl,-rpath=/usr/lib/swipl-7.2.3/lib/armv7hl-linux -L/builddir/build/BUILD/swipl-7.2.3/src/../lib/armv7hl-linux -L'/usr/lib/jvm/java-1.8.0-openjdk-aarch32-1.8.0.112-2.161109.fc26.arm/jre/lib/arm/server' -L'/usr/lib/jvm/java-1.8.0-openjdk-aarch32-1.8.0.112-2.161109.fc26.arm/jre/lib/arm' -o libjpl.so src/c/jpl.o -ljava -lverify -ljvm -lswipl /usr/bin/ld: cannot find -ljava /usr/bin/ld: cannot find -lverify /usr/bin/ld: cannot find -ljvm collect2: error: ld returned 1 exit status I would say that openjdk relocated its libraries again as happened many times in the history. But Koschei blames glibc: glibc-devel 2.24.90-24.fc26 > 2.24.90-25.fc26 glibc 2.24.90-24.fc26 > 2.24.90-25.fc26 libcrypt-nss 2.24.90-24.fc26 > 2.24.90-25.fc26 glibc-common 2.24.90-24.fc26 > 2.24.90-25.fc26 glibc-headers 2.24.90-24.fc26 > 2.24.90-25.fc26 glibc-all-langpacks 2.24.90-24.fc26 > 2.24.90-25.fc26 kernel-headers 4.10.0-0.rc0.git8.1.... > 4.10.0-0.rc0.git9.1.... python3-lxml 3.7.0-2.fc26 > 3.7.1-1.fc26 python3-setuptools 30.4.0-2.fc26 > 32.2.0-1.fc26
It actually looks like a change in openjdk. There is an experimental arm32 package that misplaces the shared libraries (bug #1412953).
I applied a workaround in the pl package.