Hello, It seems there need some work on asm-based packages. Reproducible: Always
>>> Configuring source in /var/tmp/portage/media-libs/libjpeg-turbo-1.2.0-r2/work/libjpeg-turbo-1.2.0 ... * econf: updating libjpeg-turbo-1.2.0/config.guess with /usr/share/gnuconfig/config.guess * econf: updating libjpeg-turbo-1.2.0/config.sub with /usr/share/gnuconfig/config.sub ./configure --prefix=/usr --build=x86_64-gentoo-linux-gnu --host=x86_64-gentoo-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/libx32 --disable-dependency-tracking --disable-static --with-jpeg8 --without-java configure: loading site script /usr/share/config.site configure: loading site script /usr/share/crossdev/include/site/linux configure: loading site script /usr/share/crossdev/include/site/linux-gnu configure: loading site script /usr/share/crossdev/include/site/x86_64-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for gawk... gawk checking whether make sets $(MAKE)... yes checking for style of include used by make... GNU checking for x86_64-gentoo-linux-gnu-gcc... x86_64-gentoo-linux-gnu-gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether x86_64-gentoo-linux-gnu-gcc accepts -g... yes checking for x86_64-gentoo-linux-gnu-gcc option to accept ANSI C... none needed checking dependency style of x86_64-gentoo-linux-gnu-gcc... none checking how to run the C preprocessor... x86_64-gentoo-linux-gnu-gcc -E checking for x86_64-gentoo-linux-gnu-gcc... (cached) x86_64-gentoo-linux-gnu-gcc checking whether we are using the GNU C compiler... (cached) yes checking whether x86_64-gentoo-linux-gnu-gcc accepts -g... (cached) yes checking for x86_64-gentoo-linux-gnu-gcc option to accept ANSI C... (cached) none needed checking dependency style of x86_64-gentoo-linux-gnu-gcc... (cached) none checking for a BSD-compatible install... /usr/bin/install -c checking build system type... x86_64-gentoo-linux-gnu checking host system type... x86_64-gentoo-linux-gnu checking for a sed that does not truncate output... /bin/sed checking for egrep... grep -E checking for ld used by x86_64-gentoo-linux-gnu-gcc... /usr/x86_64-gentoo-linux-gnu/bin/ld checking if the linker (/usr/x86_64-gentoo-linux-gnu/bin/ld) is GNU ld... yes checking for /usr/x86_64-gentoo-linux-gnu/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/bin/x86_64-gentoo-linux-gnu-nm -B checking whether ln -s works... yes checking how to recognise dependent libraries... pass_all checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for x86_64-gentoo-linux-gnu-g++... x86_64-gentoo-linux-gnu-g++ checking whether we are using the GNU C++ compiler... yes checking whether x86_64-gentoo-linux-gnu-g++ accepts -g... yes checking dependency style of x86_64-gentoo-linux-gnu-g++... none checking how to run the C++ preprocessor... x86_64-gentoo-linux-gnu-g++ -E checking for x86_64-gentoo-linux-gnu-g77... no checking for x86_64-gentoo-linux-gnu-f77... no checking for x86_64-gentoo-linux-gnu-xlf... no checking for x86_64-gentoo-linux-gnu-frt... no checking for x86_64-gentoo-linux-gnu-pgf77... no checking for x86_64-gentoo-linux-gnu-fort77... no checking for x86_64-gentoo-linux-gnu-fl32... no checking for x86_64-gentoo-linux-gnu-af77... no checking for x86_64-gentoo-linux-gnu-f90... no checking for x86_64-gentoo-linux-gnu-xlf90... no checking for x86_64-gentoo-linux-gnu-pgf90... no checking for x86_64-gentoo-linux-gnu-epcf90... no checking for x86_64-gentoo-linux-gnu-f95... no checking for x86_64-gentoo-linux-gnu-fort... no checking for x86_64-gentoo-linux-gnu-xlf95... no checking for x86_64-gentoo-linux-gnu-ifc... no checking for x86_64-gentoo-linux-gnu-efc... no checking for x86_64-gentoo-linux-gnu-pgf95... no checking for x86_64-gentoo-linux-gnu-lf95... no checking for x86_64-gentoo-linux-gnu-gfortran... x86_64-gentoo-linux-gnu-gfortran checking whether we are using the GNU Fortran 77 compiler... yes checking whether x86_64-gentoo-linux-gnu-gfortran accepts -g... yes checking the maximum length of command line arguments... 32768 checking command to parse /usr/bin/x86_64-gentoo-linux-gnu-nm -B output from x86_64-gentoo-linux-gnu-gcc object... ok checking for objdir... .libs checking for x86_64-gentoo-linux-gnu-ar... x86_64-gentoo-linux-gnu-ar checking for x86_64-gentoo-linux-gnu-ranlib... x86_64-gentoo-linux-gnu-ranlib checking for x86_64-gentoo-linux-gnu-strip... x86_64-gentoo-linux-gnu-strip checking if x86_64-gentoo-linux-gnu-gcc static flag works... yes checking if x86_64-gentoo-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no checking for x86_64-gentoo-linux-gnu-gcc option to produce PIC... -fPIC checking if x86_64-gentoo-linux-gnu-gcc PIC flag -fPIC works... yes checking if x86_64-gentoo-linux-gnu-gcc supports -c -o file.o... yes checking whether the x86_64-gentoo-linux-gnu-gcc linker (/usr/x86_64-gentoo-linux-gnu/bin/ld -m elf_i386) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by x86_64-gentoo-linux-gnu-g++... /usr/x86_64-gentoo-linux-gnu/bin/ld -m elf_i386 checking if the linker (/usr/x86_64-gentoo-linux-gnu/bin/ld -m elf_i386) is GNU ld... yes checking whether the x86_64-gentoo-linux-gnu-g++ linker (/usr/x86_64-gentoo-linux-gnu/bin/ld -m elf_i386) supports shared libraries... yes checking for x86_64-gentoo-linux-gnu-g++ option to produce PIC... -fPIC checking if x86_64-gentoo-linux-gnu-g++ PIC flag -fPIC works... yes checking if x86_64-gentoo-linux-gnu-g++ supports -c -o file.o... yes checking whether the x86_64-gentoo-linux-gnu-g++ linker (/usr/x86_64-gentoo-linux-gnu/bin/ld -m elf_i386) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes appending configuration tag "F77" to libtool checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking for x86_64-gentoo-linux-gnu-gfortran option to produce PIC... -fPIC checking if x86_64-gentoo-linux-gnu-gfortran PIC flag -fPIC works... yes checking if x86_64-gentoo-linux-gnu-gfortran supports -c -o file.o... yes checking whether the x86_64-gentoo-linux-gnu-gfortran linker (/usr/x86_64-gentoo-linux-gnu/bin/ld -m elf_i386) supports shared libraries... yes checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking whether ln -s works... yes checking whether compiler supports pointers to undefined structures... yes checking whether __SUNPRO_C is declared... no checking for ANSI C header files... (cached) yes checking stddef.h usability... yes checking stddef.h presence... yes checking for stddef.h... yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for sys/types.h... (cached) yes checking for an ANSI C-conforming const... yes checking whether char is unsigned... no checking for inline... inline checking for size_t... yes checking for unsigned char... yes checking for unsigned short... yes checking if right shift is signed... yes checking for short external names... ok checking for memset... yes checking for memcpy... yes checking libjpeg API version... 8.0 checking libjpeg shared library version... 8:2 checking whether the linker supports version scripts... yes (GNU style) checking whether to use version script when building libjpeg-turbo... yes checking for inline... __attribute__((always_inline)) checking whether to include arithmetic encoding support... yes checking whether to include arithmetic decoding support... yes checking whether to build TurboJPEG/OSS Java wrapper... no checking if we have SIMD optimisations for cpu type... yes (x86_64) checking for nasm... nasm checking for object file format of host system... ELF64 checking for object file format specifier (NAFLAGS) ... -felf64 -DELF -D__x86_64__ checking whether the assembler (nasm -felf64 -DELF -D__x86_64__) works... yes checking whether the linker accepts assembler output... no configure: error: configuration problem: maybe object file format mismatch. !!! Please attach the following file when seeking support: !!! /var/tmp/portage/media-libs/libjpeg-turbo-1.2.0-r2/work/libjpeg-turbo-1.2.0/config.log * ERROR: media-libs/libjpeg-turbo-1.2.0-r2 failed (configure phase): * econf failed * * Call stack: * ebuild.sh, line 85: Called src_configure * environment, line 3978: Called econf '--disable-static' '--with-jpeg8' '--without-java' * phase-helpers.sh, line 467: Called die * The specific snippet of code: * die "econf failed" * * If you need support, post the output of `emerge --info '=media-libs/libjpeg-turbo-1.2.0-r2'`, * the complete build log and the output of `emerge -pqv '=media-libs/libjpeg-turbo-1.2.0-r2'`. !!! When you file a bug report, please include the following information: GENTOO_VM= CLASSPATH="" JAVA_HOME="" JAVACFLAGS="" COMPILER="" and of course, the output of emerge --info * The complete build log is located at '/var/tmp/portage/media-libs/libjpeg-turbo-1.2.0-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-libs/libjpeg-turbo-1.2.0-r2/temp/environment'. * Working directory: '/var/tmp/portage/media-libs/libjpeg-turbo-1.2.0-r2/work/libjpeg-turbo-1.2.0' * S: '/var/tmp/portage/media-libs/libjpeg-turbo-1.2.0-r2/work/libjpeg-turbo-1.2.0'
1) !!! Please attach the following file when seeking support: !!! /var/tmp/portage/media-libs/libjpeg-turbo-1.2.0-r2/work/libjpeg-turbo-1.2.0/config.log 2) Please post your `emerge --info' output in a comment.
latest nasm (2.10) supports x32, so the biggest hurdle is cleared
it at least compiles for me now. if someone wants to validate past that, that would be great. Commit message: Fix building for x32 targets http://sources.gentoo.org/media-libs/libjpeg-turbo/files/libjpeg-turbo-1.2.0-x32.patch?rev=1.1 http://sources.gentoo.org/media-libs/libjpeg-turbo/libjpeg-turbo-1.2.0-r2.ebuild?r1=1.3&r2=1.4
(In reply to comment #4) > it at least compiles for me now. if someone wants to validate past that, > that would be great. I've been using a similar patch and the library has been throwing segfaults so it seems more needs to be altered in the assembly code for the simd implementation if we want to enable that for x32.
The current version in Portage did emerge. Many thanks, it unlocks QT, lxde, and many jpeg-dependent packages!
(In reply to comment #6) > The current version in Portage did emerge. Many thanks, it unlocks QT, lxde, > and many jpeg-dependent packages! Just to note, expect anything trying to do jpeg related functionality that touches the simd code to segfault. :)
(In reply to comment #7) > (In reply to comment #6) > > The current version in Portage did emerge. Many thanks, it unlocks QT, lxde, > > and many jpeg-dependent packages! > > Just to note, expect anything trying to do jpeg related functionality that > touches the simd code to segfault. :) Yep, but for now I try to build my @world. Later I will try to run it. I've also found run-time errors in some packages, the bugs are reported. At least base system do work, I can boot (without modules for now), run ssh, screen, emerge.
Commit message: Disable simd code for x32 ABIs so the package at least works (passes tests) http://sources.gentoo.org/media-libs/libjpeg-turbo/libjpeg-turbo-1.2.0-r2.ebuild?r1=1.4&r2=1.5
Although there's currently no efficient implementation of the functions in question, I understood that libjpeg-turbo at least compiles and runs fine on x32. If that's the case I'd propose to just mark this bug as fixed.
(In reply to Tolga Dalman from comment #10) > Although there's currently no efficient implementation of the functions in > question, I understood that libjpeg-turbo at least compiles and runs fine on > x32. If that's the case I'd propose to just mark this bug as fixed. not fixed yet, http://sourceforge.net/p/libjpeg-turbo/patches/35/#4d4d optimizations not working thus, no real advantage over IJG's jpeg on x32 is not the same as 'works'
(In reply to Samuli Suominen from comment #11) > optimizations not working thus, no real advantage over IJG's jpeg on x32 is > not the same as 'works' Clearly, we have different definitions over that then :) Since libjpeg-turbo is a direct dependency on (at least) chromium and firefox[system-jpeg], compiling and running deserves a 'is working' attribute in my eyes. How about adjusting this bug, i.e., setting an appropriate title, lowering the importance level, and removing the blocker from x32 ?
(In reply to Samuli Suominen from comment #11) > optimizations not working thus, no real advantage over IJG's jpeg on x32 is > not the same as 'works' Even though assembly optimizations for DCT and colorspace conversion are not available, some additional huffman optimizations in libjpeg-turbo are implemented with just C code. So "no real advantage" is a myth, but "no groundbreaking advantage" would be indeed correct. That's a copy/paste of an old post from gentoo forums, which shows that on a PPC platform (Playstation3, CFLAGS="-g -mcpu=cell -mtune=cell -maltivec -O2 -fomit-frame-pointer -pipe") the results used to be the following: # wget http://www.nasa.gov/images/content/618486main_earth_full.jpg # emerge media-libs/jpeg-8d # time djpeg 618486main_earth_full.jpg > /dev/null real 0m5.298s user 0m5.200s sys 0m0.098s # emerge ="media-libs/libjpeg-turbo-1.2.0-r1" # time djpeg 618486main_earth_full.jpg > /dev/null real 0m4.193s user 0m4.096s sys 0m0.095s The benchmark results for X32 with up to date versions of libjpeg-turbo and IJG's jpeg are welcome. But in any case, I don't see how this issue can be resolved (and what would be the gentoo role in it) without actually doing some non-trivial work and contributing it upstream.
If you feel you can still duplicate the problem feel free to reopen and update with present info.