Bugzilla Bug 70947

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 an attachment (id=43772) [edit]
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