mjpegtool compile fails if -fstack-protector is specified in /etc/make.conf Reproducible: Always Steps to Reproduce: 1. add -fstack-protector to CFLAGS in /etc/make.conf 2. emerge mjpegtools 3. watch the compile choke and die Actual Results: compile dies Expected Results: compile should complete successfully FIX: strip -fstack-protector out of the CFLAGS in ebuild
Is this where it dies for you? motion.c: In function `calc_SAD_mmx': motion.c:143: internal compiler error: asm clobber conflict with output operand Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://bugs.gentoo.org/> for instructions. Preprocessed source stored into /data/tmp/portage/mjpegtools-1.6.2/temp/ccReWJ2E.out file, please attach this to your bugreport make[2]: *** [motion.o] Error 1 make[2]: Leaving directory `/data/tmp/portage/mjpegtools-1.6.2/work/mjpegtools-1.6.2/yuvdenoise' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/tmp/portage/mjpegtools-1.6.2/work/mjpegtools-1.6.2' make: *** [all] Error 2 !!! ERROR: media-video/mjpegtools-1.6.2 failed. !!! Function src_compile, Line 85, Exitcode 2 !!! compile problem Removing the matching enable line and specifically disabling simd as follows fixes it for me: myconf="${myconf} --disable-simd-accel" Granted, thats a sloppy thing to do and doesn't track down the real problem, but it does let it compile. And doing this, I do NOT need to filter out pic or stack-protector.
What about something like. use mmx || myconf="${myconf} --disable-simd-accel"
i would prefer: myconf="${myconf} `use_enable mmx simd-accel`" but that is just semantics...
Their simd-accel functions are a generic trigger for allowing mmx/sse/sse2 and so on. It is entirely possible that the accelerations that are in there work fine if PIC is not enabled. The processor type is autodetected by ./configure, and the simd-accel set is enabled unless it is explicitly disabled. And something in that set of code breaks with -fPIC.
Just confirmed that adding -yet_exec into the Makefile in that directory (that Makefile forcibly overwrites CC and CFLAGS) compiles without the asm clobber conflict. So, the enable-simd-accel is appropriate to be turned on UNLESS hardened-gcc or gcc-pie are active.
I just read in the ChangeLog: *mjpegtools-1.6.1.92 (16 Jan 2004) 16 Jan 2004; Wout Mertens <wmertens@gentoo.org> mjpegtools-1.6.1.92.ebuild: Version bump and disabling -fPIC on x86 where it fails. Could you please verify if there's still a problem?
see bug #47335, it is not needed. what is the proper fix for this bug?
[ebuild U ] media-video/mjpegtools-1.6.2-r1 [1.6.0-r7] -3dnow +X +avi -dv -gtk +mmx +quicktime +sdl +sse 0 kB ----------------------------------------------------------------------------- checking for vidix... no ./configure: line 13191: test: too many arguments tail: `-1' option is obsolete; use `-n 1' since this will be removed in the future updating cache ./config.cache creating ./config.status ----------------------------------------------------------------------------- r/lib/libquicktime.so: undefined reference to `png_set_compression_level' /usr/lib/libquicktime.so: undefined reference to `png_create_read_struct' /usr/lib/libquicktime.so: undefined reference to `png_set_read_fn' /usr/lib/libquicktime.so: undefined reference to `png_get_io_ptr' /usr/lib/libquicktime.so: undefined reference to `png_set_IHDR' /usr/lib/libquicktime.so: undefined reference to `png_create_write_struct' /usr/lib/libquicktime.so: undefined reference to `png_write_info' /usr/lib/libquicktime.so: undefined reference to `png_write_end' /usr/lib/libquicktime.so: undefined reference to `png_set_write_fn' /usr/lib/libquicktime.so: undefined reference to `png_read_info' /usr/lib/libquicktime.so: undefined reference to `png_destroy_read_struct' /usr/lib/libquicktime.so: undefined reference to `png_write_image' /usr/lib/libquicktime.so: undefined reference to `png_read_image' /usr/lib/libquicktime.so: undefined reference to `png_create_info_struct' /usr/lib/libquicktime.so: undefined reference to `png_destroy_write_struct' collect2: ld returned 1 exit status make[2]: *** [lavplay] Error 1 make[2]: Leaving directory `/space/tmp/portage/mjpegtools-1.6.2-r1/work/mjpegtools-1.6.2/lavtools' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/space/tmp/portage/mjpegtools-1.6.2-r1/work/mjpegtools-1.6.2' make: *** [all] Error 2 !!! ERROR: media-video/mjpegtools-1.6.2-r1 failed. !!! Function src_compile, Line 78, Exitcode 2 !!! compile problem ----------------------------------------------------------------- The proper fix trigger --disable-simd-accel when fstack-protctor is in CFLAGS or USE=hardened is enabled and to correct or remove the quicktime behavior.
"and to correct or remove the quicktime behaviour" <-- what does that mean?
This should really be another bug but I lack the time/motivation to track down quicktime linking errors. solar@simple c $ emerge -pv quicktime [ebuild U ] media-libs/quicktime4linux-2.0.0-r1 [1.5.5-r1] 3,742 kB solar@simple c $ ldd /usr/lib/libquicktime.so libc.so.6 => /lib/libc.so.6 (0x21584000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x0b5d2000) solar@simple c $ nm /usr/lib/libquicktime.so | grep "U png" U png_create_info_struct U png_create_read_struct U png_create_write_struct U png_destroy_read_struct U png_destroy_write_struct U png_get_io_ptr U png_read_image U png_read_info U png_set_IHDR U png_set_compression_level U png_set_read_fn U png_set_write_fn U png_write_end U png_write_image U png_write_info ------------------------------------------------ As we can clearly see quicktime itself has undefined references to png but the libpng is nowhere to be found in the ELF DT_NEEDED. In short... When building mjpegtools this bug presented itself to me. It could be probably be worked around by simply adding to either of the two .ebuilds. (preferably quicktime itself) inherit flag-o-matic append-ldflags -lpng Note: - My quicktime is an older version and this may have been fixed already. ------------------------------------------------
i don't get the quicktime error and the simd-accel thing is fixed in mjpegtools-1.6.2-r3
