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-2.3.4.20041102-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-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-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"
Created attachment 43772 [details] Output of emerge media-libs/jpeg ebuild
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 ..
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.
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.
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?
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.
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.
Perhaps -Wno-deprecated should be used in the -fpic test?
fixed in cvs since the problem is just for HPUX, I made the check happen just for it.
Forgot to change its status...
*** Bug 72399 has been marked as a duplicate of this bug. ***
*** Bug 66594 has been marked as a duplicate of this bug. ***
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
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
forget my last comment, there has to be another reason, just uncommeting the patch works fine
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?
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.
Simone: can you please apply this?
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.
strange, now it builds fine again without it -> close
Closed
