Created attachment 640904 [details] build.log.gz samplerate.a | | /bin/sed 's/.* //' | sort | uniq > .libs/libgavl.exp ../libtool: eval: line 1774: syntax error near unexpected token `|' ../libtool: eval: line 1774: `nm .libs/absdiff.o .libs/arith128.o .libs/audioconverter.o .libs/audioformat.o .libs/audioframe.o .libs/audiooptions.o .libs/blend.o .libs/colorchannel.o .libs/colorspace.o .libs/compression.o .libs/cputest.o .libs/deinterlace.o .libs/deinterlace_blend.o .libs/deinterlace_copy.o .libs/deinterlace_scale.o .libs/dsp.o .libs/dsputils.o .libs/frametable.o .libs/interleave.o .libs/memcpy.o .libs/metadata.o .libs/mix.o .libs/peakdetector.o .libs/psnr.o .libs/rectangle.o .libs/sampleformat.o .libs/samplerate.o .libs/scale.o .libs/scale_context.o .libs/scale_kernels.o .libs/scale_table.o .libs/ssim.o .libs/time.o .libs/timecode.o .libs/timer.o .libs/transform.o .libs/transform_context.o .libs/transform_table.o .libs/video.o .libs/videoformat.o .libs/videoframe.o .libs/videooptions.o .libs/volume.o mmx/.libs/libgavl_mmx.a mmxext/.libs/libgavl_mmxext.a sse/.libs/libgavl_sse.a sse2/.libs/libgavl_sse2.a sse3/.libs/libgavl_sse3.a 3dnow/.libs/libgavl_3dnow.a c/.libs/libgavl_c.a hq/.libs/libgavl_hq.a libgdither/.libs/libgdither.a libsamplerate/.libs/libsamplerate.a | | /bin/sed 's/.* //' | sort | uniq > .libs/libgavl.exp' make[2]: *** [Makefile:596: libgavl.la] Error 2 make[2]: Leaving directory '/var/tmp/portage/media-libs/gavl-1.4.0-r1/work/gavl-1.4.0-abi_x86_32.x86/gavl' make[1]: *** [Makefile:688: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/media-libs/gavl-1.4.0-r1/work/gavl-1.4.0-abi_x86_32.x86/gavl' make: *** [Makefile:466: all-recursive] Error 1 This *could* be a bug in libtool, as this seems to be the second place I've encountered this specific pattern: > ../libtool: eval: line 1774: syntax error near unexpected token `|' > ../libtool: eval: line 1774: `nm <stuff> (As seen in bug #724448) But I don't see existing libtool bugs open for this specific issue. (They all express similarly, but seem unrelated to the presence of nm in /usr/bin)
Seeing > checking for BSD- or MS-compatible name lister (nm)... no I think it's a case of bug #724558. Can you reproduce build failure past that commit? 32-bit build does not fail for me and detects NM as: > checking for BSD- or MS-compatible name lister (nm)... x86_64-pc-linux-gnu-nm
Now works with multilib.eclass fixes :)