|Summary:||media-libs/jpeg-6b-r4 doesn't installs libjpeg.so.62 if the compiler reports some warnings during the -fpic test|
|Product:||Gentoo Linux||Reporter:||Dead Schorsch <spamlover>|
|Component:||New packages||Assignee:||Gentoo Graphics Project <graphics+disabled>|
|Severity:||blocker||CC:||amd64, gygas2000, lanius, mgorny, motaboy|
|Package list:||Runtime testing required:||---|
|Bug Depends on:|
|Bug Blocks:||66594, 71539|
|Attachments:||Output of emerge media-libs/jpeg ebuild|
Description Dead Schorsch 2004-11-12 03:44:12 UTC
It looks like the above ebuild installs the required library and immediatly removes it again. However, this behaviour is only observed on one of my machine, the second one does not look affected. The lack of this library, also shown as being installed by portage removes functionality by almost every other GUI programm (gnome-terminal, evolution, etc.) Reproducible: Always Steps to Reproduce: 1. emerge media-libs/jpeg 2. 3. Actual Results: I will add the complete emerge log as attachement. king ~ # emerge info Portage 2.0.51-r3 (default-linux/x86/2004.3, gcc-3.4.3, glibc-22.214.171.12441102-r0,glibc-2.2.5-r2, 2.6.9-gentoo-r2 i686) ================================================================= System uname: 2.6.9-gentoo-r2 i686 AMD Athlon(tm) XP 2200+ Gentoo Base System version 1.6.6 Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-126.96.36.199.2-r1 Headers: sys-kernel/linux26-headers-188.8.131.52-r1 Libtools: sys-devel/libtool-1.5.2-r7 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-mcpu=athlon-xp -O2 -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mcpu=athlon-xp -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs buildpkg ccache distcc distlocks fixpackages sandbox sfperms userpriv usersandbox" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="X aalib acpi alsa apm avi berkdb bitmap-fonts bonobo cdr crypt cups debug doc dvd dvdr encode esd f77 fam flac foomaticdb fortran gd gdbm gimpprint gnome gpm gstreamer gtk gtk2 gtkhtml guile hbci imagemagick imlib ipv6 java jpeg junit ldap libg++ libwww mad mozilla moznocompose moznoirc moznomail mpeg ncurses network nls nocardbus nptl nvidia oggvorbis opengl pam pda pdflib perl png python readline samba scanner sdl slang spell ssl svga tcltk tcpd tetex tiff truetype usb userlocales vanilla x86 xml xml2 xmms xv zlib"
Comment 1 Dead Schorsch 2004-11-12 03:45:00 UTC
Created attachment 43772 [details] Output of emerge media-libs/jpeg ebuild
Comment 2 Dead Schorsch 2004-11-12 04:02:53 UTC
Oh wait, looks like the email removes the symlinks, because they are dead. There is no libjpeg.so.62.0.0 references by the symlinks. And the reason is, I still had the -mcpu compiler switch in my make.conf, after changing it to -march the library above is build and properly installed. Damn, looks like I have to re-emerge a lot of applications ..
Comment 3 Simone Gotti (RETIRED) 2004-11-12 06:00:02 UTC
Just to inform you: I've also noticed this behavior but only with media-libs/jpeg. I think the "problem" is that its configure checks if gcc can build shared objects, but using -mcpu with gcc 3.4 reports a warning and the script interpretes this as an error and reports that the shared objects can't be compiled. So the .so lib isn't created but only the static one.
Comment 4 Simone Gotti (RETIRED) 2004-11-15 11:08:41 UTC
Me and Stuart had a talk on irc. The problem is caused but the -fpic check in ltconfig that disable shared objects generation for any warning returned by the test program, this is done to avoid an HP-UX bug. So every warning like the "-mcpu deprecated" one or for example the distcc output will disable them. This is a wrong behavior as many programs like kde and gnome will break. We have various solutions and I'll reopen this bug until a fixed ebuild is committed.
Comment 5 Jonathan Fors 2004-11-16 08:53:10 UTC
I have had the same problem and can therefore confirm its existence. A quick search for libjpeg on forums.gentoo.org show several people that have the same problem. After some hours of debugging I have concluded that in the configuration of jpeg-6b-r4 it wrongly gets to the desicion that libtool does not support shared libraries. All other libraries that I have tried to emerge say "yes" to this question. When compiling, the library libjpeg.so doesnt get built, but creates the link from /usr/lib/libjpeg.so.62 to /usr/lib/libjpeg.so. Since this library is badly needed for all programs that use JPEGs I had to make an ugly hack to the ./configure script to install libjpeg.so. I am quite confident with bash scripting, but I didn't understand too much of the configure script, since some fairly advanced tricks are used within it. Perhaps someone can take over from where I have come?
Comment 6 Mikael Rosbacke 2004-11-17 14:14:23 UTC
Can only confirm previous findings. However, building the package with ebuild /usr/portage/media-libs/jpeg/jpeg-6b-r4.ebuild compile will result in the following configure command to be run: ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --enable-shared --enable-static The following snippet is found in the configure output: checking for BSD-compatible nm... /usr/bin/nm -B checking command to parse /usr/bin/nm -B output... yes checking how to hardcode library paths into programs... immediate checking for /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld option to reload object files... -r checking dynamic linker characteristics... Linux ld.so checking if libtool supports shared libraries... no checking whether to build shared libraries... no checking whether to build static libraries... yes checking for objdir... .libs creating libtool while copy and paste of the configure command into a shell window and manually running it gives: checking for BSD-compatible nm... /usr/bin/nm -B checking command to parse /usr/bin/nm -B output... yes checking how to hardcode library paths into programs... immediate checking for /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.4/../../../../i686-pc-linux-gnu/bin/ld option to reload object files... -r checking dynamic linker characteristics... Linux ld.so checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking for objdir... .libs creating libtool It seems like emerge and ebuild add something which prevents libtool from building shared libraries. I made a manual install afterwards as a temporary solution but the ebuild is still broken.
Comment 7 Simone Gotti (RETIRED) 2004-11-17 16:46:31 UTC
I've already explained the problem in comment #4. I'll fix it removing that check but I'm waiting for an answer from the right herd. Just noticed they weren't CCed... my bad.
Comment 8 Jonathan Fors 2004-11-17 23:54:23 UTC
Perhaps -Wno-deprecated should be used in the -fpic test?
Comment 9 Luca Barbato 2004-11-18 13:28:04 UTC
fixed in cvs since the problem is just for HPUX, I made the check happen just for it.
Comment 10 Luca Barbato 2004-11-18 13:36:53 UTC
Forgot to change its status...
Comment 11 Simone Gotti (RETIRED) 2004-11-24 15:06:44 UTC
*** Bug 72399 has been marked as a duplicate of this bug. ***
Comment 12 Patrick Kursawe (RETIRED) 2004-11-30 06:55:49 UTC
*** Bug 66594 has been marked as a duplicate of this bug. ***
Comment 13 Heinrich Wendel (RETIRED) 2005-01-29 18:01:01 UTC
this patch brakes compile on amd64, configure gives the following output: checking if gcc PIC flag -fPIC works... ./ltconfig: line 556: test: -fPIC: integer expression expected and doesn't add -fPIC to CFLAGS
Comment 14 Heinrich Wendel (RETIRED) 2005-01-29 18:09:15 UTC
the patch says if test -s conftest.err -a $pic_flag -eq '+Z'; then i think this should be if test -s conftest.err -a '$pic_flag' = '+Z'; then
Comment 15 Heinrich Wendel (RETIRED) 2005-01-29 18:11:12 UTC
forget my last comment, there has to be another reason, just uncommeting the patch works fine
Comment 16 Simone Gotti (RETIRED) 2005-01-30 04:56:04 UTC
lanius: you used the wrong quotes (you have to use " " because ' ' will just block the shell expansion). Can you please try in this way? (it doesn't return any error for me). if test -s conftest.err -a "$pic_flag" = '+Z'; then I don't know if this will fix your problem as I didn't understand clearly what's your problem, can you elaborate more on it?
Comment 17 Heinrich Wendel (RETIRED) 2005-01-31 05:14:57 UTC
The problem is, that configure doesn't add -fPIC to CFLAGS, because of the error. LD can't link the objects then. Your solution works fine.
Comment 18 Heinrich Wendel (RETIRED) 2005-02-19 11:44:51 UTC
Simone: can you please apply this?
Comment 19 Simone Gotti (RETIRED) 2005-02-20 05:08:16 UTC
I'm not in the graphics herd (I was thinking it was already applied). Graphics herd: any reason why it wasn't applied to the ebuild? lanius: I think that if we don't get any answer we can apply it ourself in the next days.
Comment 20 Heinrich Wendel (RETIRED) 2005-02-26 02:55:34 UTC
strange, now it builds fine again without it -> close
Comment 21 Dead Schorsch 2005-10-06 08:42:24 UTC