My system is x86_64, and rubberband is built for both 64bit and 32bit. 32bit version is built first - it is ok, but 64bit fails there: x86_64-pc-linux-gnu-g++ -shared -Wl,-Bsymbolic -Wl,-soname=librubberband.so.2 src/rubberband-c.o src/RubberBandStretcher.o src/StretcherProcess.o src/StretchCalculator.o src/base/Profiler.o src/dsp/AudioCurveCalculator.o src/audiocurves/CompoundAudioCurve.o src/audiocurves/SpectralDifferenceAudioCurve.o src/audiocurves/HighFrequencyAudioCurve.o src/audiocurves/SilentAudioCurve.o src/audiocurves/ConstantAudioCurve.o src/audiocurves/PercussiveAudioCurve.o src/dsp/Resampler.o src/dsp/FFT.o src/system/Allocators.o src/system/sysutils.o src/system/Thread.o src/StretcherChannelData.o src/StretcherImpl.o -o lib/librubberband.so -lsamplerate -lfftw3 -O2 -lpthread -O2 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: cannot open output file lib/librubberband.so: No such file or directory collect2: error: ld returned 1 exit status After looking to all subdirs inside WORKDIR (origin and multilib copies) i found, that only 32bit copy has "lib" subdir, which is created by configuration. But 64bit is configured too (has config.log with same conf command as in build log). Previous time it was installed by upgrade, and also for both 32 and 64 bit. But that time I had glibc-2.26. Now I upgraded glibc to 2.27 (I suspect more possible build failures with 2.28, so trying to do it step-by-step). Now I'm doing $ emerge -1avbke @system.
Created attachment 575330 [details] Build log
Created attachment 575332 [details] emerge info
Ooops... This bug is appears hard to reproduce. After $ emerge --info it passed without problems and any attempts to fix.
It appears 1 to 2 times or so. No matter, wether temporary directories exist or not (emerge removes old dir if found, before new emerge).
Found root of problem: 'lib' dir in source dir root should be created by make rule in dependencies of 'all': all: bin lib $(PROGRAM_TARGET) $(DYNAMIC_TARGET) $(VAMP_TARGET) $(LADSPA_TARGET) But such makefile design is clearly uncareful of multiple make jobs. Adding -j1 to make options solves problem.
It appears with options like '-j3 -l1.8' (for my 2-core cpu), but with just -j3 it is ok. I'm not sure, is it sys-devel/make bug, because rubberband's Makefile still seems to be not enough well designed (or I just don't comprehend something).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8edcf54165e5af94c9a59c4ae60704c7561e7557 commit 8edcf54165e5af94c9a59c4ae60704c7561e7557 Author: Miroslav Šulc <fordfrog@gentoo.org> AuthorDate: 2020-09-20 08:30:58 +0000 Commit: Miroslav Šulc <fordfrog@gentoo.org> CommitDate: 2020-09-20 08:31:11 +0000 media-libs/rubberband: bump to 1.9.0 1) added use flags for optional features 2) organized deps Closes: https://bugs.gentoo.org/547904 Closes: https://bugs.gentoo.org/685110 Closes: https://bugs.gentoo.org/590500 Package-Manager: Portage-3.0.7, Repoman-3.0.1 Signed-off-by: Miroslav Šulc <fordfrog@gentoo.org> media-libs/rubberband/Manifest | 1 + media-libs/rubberband/metadata.xml | 4 ++ media-libs/rubberband/rubberband-1.9.0.ebuild | 67 +++++++++++++++++++++++++++ 3 files changed, 72 insertions(+)
