/usr/lib64/libfftw3.so.3.5.5 in fftw-libs-double-3.3.5-10.fc28.x86_64 has not been linked with the standard Fedora linker flags (LDFLAGS) from redhat-rpm-config. It seems that something dropped the -specs=/usr/lib/rpm/redhat/redhat-hardened-ld part of LDFLAGS: libtool: link: gcc -shared -fPIC -DPIC -Wl,--whole-archive kernel/.libs/libkernel.a dft/.libs/libdft.a dft/scalar/.libs/libdft_scalar.a dft/scalar/codelets/.libs/libdft_scalar_codelets.a rdft/.libs/librdft.a rdft/scalar/.libs/librdft_scalar.a rdft/scalar/r2cf/.libs/librdft_scalar_r2cf.a rdft/scalar/r2cb/.libs/librdft_scalar_r2cb.a rdft/scalar/r2r/.libs/librdft_scalar_r2r.a reodft/.libs/libreodft.a api/.libs/libapi.a simd-support/.libs/libsimd_support.a simd-support/.libs/libsimd_sse2_nonportable.a dft/simd/sse2/.libs/libdft_sse2_codelets.a rdft/simd/sse2/.libs/librdft_sse2_codelets.a dft/simd/avx/.libs/libdft_avx_codelets.a rdft/simd/avx/.libs/librdft_avx_codelets.a -Wl,--no-whole-archive -lm -O2 -m64 -mtune=generic -mcet -Wl,-z -Wl,relro -Wl,-soname -Wl,libfftw3.so.3 -o .libs/libfftw3.so.3.5.5
@Florian, it seems (?)all libtool-using binaries will suffer from the same problem prior to https://src.fedoraproject.org/rpms/libtool/c/2e616087c1dce036105331cb0ef67e57499011f3?branch=master , which is not yet present in Fedora 28. Perhaps a more general fix makes sense?
This problem is fixed in Rawhide by https://src.fedoraproject.org/rpms/fftw/pull-request/4. F28 fix is pending resolution of bug 985592.
Rawhide: https://koji.fedoraproject.org/koji/taskinfo?taskID=26727728 F28: https://koji.fedoraproject.org/koji/taskinfo?taskID=26727740
ARM build failed on F28: https://koji.fedoraproject.org/koji/taskinfo?taskID=26727740 , but not Rawhide: https://kojipkgs.fedoraproject.org//work/tasks/7795/26727795/build.log -------------------------------------------------------------------------- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): getting local rank failed --> Returned value Not found (-13) instead of ORTE_SUCCESS -------------------------------------------------------------------------- -------------------------------------------------------------------------- It looks like orte_init failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during orte_init; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): orte_ess_init failed --> Returned value Not found (-13) instead of ORTE_SUCCESS -------------------------------------------------------------------------- -------------------------------------------------------------------------- It looks like MPI_INIT failed for some reason; your parallel process is likely to abort. There are many reasons that a parallel process can fail during MPI_INIT; some of which are due to configuration or environment problems. This failure appears to be an internal failure; here's some additional information (which may only be relevant to an Open MPI developer): ompi_mpi_init: ompi_rte_init failed --> Returned "Not found" (-13) instead of "Success" (0) -------------------------------------------------------------------------- *** An error occurred in MPI_Init_thread *** on a NULL communicator *** MPI_ERRORS_ARE_FATAL (processes in this communicator will now abort, *** and potentially your MPI job) [buildvm-armv7-11.arm.fedoraproject.org:401] Local abort before MPI_INIT completed completed successfully, but am not able to aggregate error messages, and not able to guarantee that all other processes were killed! ------------------------------------------------------- Primary job terminated normally, but 1 process returned a non-zero exit code.. Per user-direction, the job has been aborted. -------------------------------------------------------
I have noticed before that the armv7hl build occasionally "just fails" like that for mysterious reasons. (Perhaps due to lack of resources on the builder?) I suggest giving the build another try or two...
That's... unfortunate :-). Try #2: https://koji.fedoraproject.org/koji/taskinfo?taskID=26729478
You were a little too anxious on the retry. :-) failed: Build already in progress (task 26727740) The previous build is still in progress for a couple architectures...
Well, that's annoying. Can old builds be cancelled? It's still running on s390 and i686.
koji cancel <task-id|build>
(In reply to Merlin Mathesius from comment #9) > koji cancel <task-id|build> Thanks. New build kicked off here: https://koji.fedoraproject.org/koji/taskinfo?taskID=26730584
(In reply to Conrad Meyer from comment #10) > Thanks. New build kicked off here: > https://koji.fedoraproject.org/koji/taskinfo?taskID=26730584 After many hours for the s390x specific tasks, the Rawhide and F28 package builds finally completed. Thank you for taking care of those. Will you also be pushing this out as a build update for F28?
Does it make a functional change (hardened ld flags)? If so, it's probably a good thing to push, right? I will push it if you recommend I do so. Thanks for all your help on this.
There's no functional change, but it does bring the package in compliance with the Fedora packaging guidelines[1] and making sure all packages are properly hardened[2]. Thanks again! [1] https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler_flags [2] https://fedoraproject.org/wiki/Changes/Harden_All_Packages
fftw-3.3.5-11.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-58f23f45d7
I think you could make an argument that hardening is a functional change. (If it didn't change anything, why did we make the change? ;-)) Of course, it doesn't (or shouldn't anyway) change the API (not sure about ABI?) of the library.
(In reply to Conrad Meyer from comment #15) > I think you could make an argument that hardening is a functional change. > (If it didn't change anything, why did we make the change? ;-)) Of course, > it doesn't (or shouldn't anyway) change the API (not sure about ABI?) of the > library. Touché! :) Thanks for taking care of this.
fftw-3.3.5-11.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-58f23f45d7
fftw-3.3.5-11.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.