Guys, I don't know what the heck happened here but -lfreetype is getting passed to gcc as /usr/lib64/libfreetype.so instead of $EPREFIX/usr/lib/libfreetype.so or something like that. Here is one such example: x86_64-pc-linux-gnu-gcc -shared .libs/adjustablearrowcap.o .libs/bitmap.o .libs/brush.o .libs/carbon-private.o .libs/customlinecap.o .libs/dstream.o .libs/font.o .libs/general.o .libs/graphics.o .libs/graphics-cairo.o .libs/graphics-metafile.o .libs/graphics-path.o .libs/graphics-pathiterator.o .libs/hatchbrush.o .libs/icocodec.o .libs/image.o .libs/imageattributes.o .libs/lineargradientbrush.o .libs/matrix.o .libs/metafile.o .libs/pathgradientbrush.o .libs/pen.o .libs/print.o .libs/region.o .libs/region-bitmap.o .libs/region-path-tree.o .libs/solidbrush.o .libs/stringformat.o .libs/text.o .libs/text-cairo.o .libs/text-pango.o .libs/text-metafile.o .libs/texturebrush.o .libs/bmpcodec.o .libs/emfcodec.o .libs/emfplus.o .libs/gifcodec.o .libs/jpegcodec.o .libs/pngcodec.o .libs/tiffcodec.o .libs/wmfcodec.o -Wl,--rpath -Wl,/home/jolexa/portage/linux-64/usr/lib -Wl,--rpath -Wl,/usr/lib64 -Wl,--rpath -Wl,/home/jolexa/portage/linux-64/usr/lib -Wl,--rpath -Wl,/usr/lib64 -lglib-2.0 /home/jolexa/portage/linux-64/usr/lib/libcairo.so -L/home/jolexa/portage/linux-64/usr/lib -L/usr/lib64 /usr/lib64/libfreetype.so -lz /home/jolexa/portage/linux-64/usr/lib/libXrender.so /home/jolexa/portage/linux-64/usr/lib/libX11.so /home/jolexa/portage/linux-64/usr/lib/libtiff.so /usr/lib64/libjpeg.so /home/jolexa/portage/linux-64/usr/lib/libpng12.so -lpthread /home/jolexa/portage/linux-64/usr/lib/libfontconfig.so -pthread -Wl,-soname -Wl,libgdiplus.so.0 -o .libs/libgdiplus.so.0.0.0 We have three identified packages and probably *many* more, as defined by: http://tinderbox.dev.gentoo.org/misc/rindex/media-libs/freetype Is something wrong with gcc's search dirs or what? I tried tracing the issue down to an eclass but that was inconclusive, I don't know what changed. %% gcc -print-search-dirs libraries: =/home/jolexa/portage/linux-64/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/:/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/:/home/jolexa/portage/linux-64/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/4.2.4/:/home/jolexa/portage/linux-64/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/lib/../lib64/:/home/jolexa/portage/linux-64/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../x86_64-pc-linux-gnu/4.2.4/:/home/jolexa/portage/linux-64/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../lib64/:/lib/x86_64-pc-linux-gnu/4.2.4/:/lib/../lib64/:/usr/lib/x86_64-pc-linux-gnu/4.2.4/:/usr/lib/../lib64/:/home/jolexa/portage/linux-64/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../x86_64-pc-linux-gnu/lib/:/home/jolexa/portage/linux-64/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../:/lib/:/usr/lib/
Is this compiler call generated by libtool? If so, how does it look?
This is a another libtool call when emerging app-text/poppler-0.10.0: /bin/sh ../libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wall -Wno-write-strings -march=opteron -O2 -pipe -fomit-frame-pointer -o perf-test perf-test.o perf-test-preview-dummy.o ../poppler/libpoppler.la -lfreetype -lz -lopenjpeg -lz creating pdf-fullrewrite x86_64-pc-linux-gnu-g++ -Wall -Wno-write-strings -march=opteron -O2 -pipe -fomit-frame-pointer -o .libs/perf-test perf-test.o perf-test-preview-dummy.o ../poppler/.libs/libpoppler.so /usr/lib64/libfreetype.so -lopenjpeg -lz -Wl,--rpath -Wl,$EPREFIX/usr/lib -Wl,--rpath -Wl,/usr/lib64 $EPREFIX/usr/lib/libfontconfig.so.1: undefined reference to `FT_Select_Size' collect2: ld returned 1 exit status This is the reason why /usr/lib64/libfreetype.so is used: poppler-0.10.0/configure is evaluating the output of "gcc -print-search-dirs" starting at line 9042. "$EPREFIX/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../lib64/" represents "$EPREFIX/usr/lib64" which does not exist without using a multilib profile. Thus the created poppler-0.10.0/libtool will have the variable "sys_lib_search_path_spec = $EPREFIX/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4 /lib64 /usr/lib64 $EPREFIX/usr/x86_64-pc-linux-gnu/lib $EPREFIX/usr/lib" and the wrong /usr/lib64/libfreetype.so is used due to the order of the paths.
please insert -L${EPREFIX}/usr/lib using append-ldflags in the ebuild before configure, and see if the same thing happens.
Your suggestion fixes app-text/poppler-0.10.0, but it does NOT fix the x11-libs/pango-1.22.2 ebuild when inserted just before the econf call: /bin/sh ../../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -march=opteron -O2 -pipe -fomit-frame-pointer -Wall -o harfbuzz-dump harfbuzz-dump.o harfbuzz-dump-main.o -lfreetype -lz -lfontconfig libharfbuzz-1.la x86_64-pc-linux-gnu-gcc -march=opteron -O2 -pipe -fomit-frame-pointer -Wall -o harfbuzz-dump harfbuzz-dump.o harfbuzz-dump-main.o ./.libs/libharfbuzz-1.a /usr/lib64/libfreetype.so -lz -lfontconfig $EPREFIX/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../libfontconfig.so: undefined reference to `FT_Select_Size'
It's not gcc, it's libtool. Pango doesn't work, because -L... doesn't end up in the piece you quote. libtool does a lot preprocessing of what it sees, including finding libraries that you refer to. Unfortunately libtool doesn't know about prefix, hence it doesn't look in the prefix paths by default.
(In reply to comment #5) > It's not gcc, it's libtool. Pango doesn't work, because -L... doesn't end up > in the piece you quote. > > libtool does a lot preprocessing of what it sees, including finding libraries > that you refer to. Unfortunately libtool doesn't know about prefix, hence it > doesn't look in the prefix paths by default. > I just also tested with libtool-2.2.6a and the same problem occurs. Ideas on how to make it "prefix aware" and why we haven't seen it until now?
In most cases the prefix lib dir(s) get in there through e.g. libiconv or something else where pkgconfig returns them. In some other I just added the prefix libdir in the ebuild like I suggested with a comment above it. haubi is against modifying libtool, and since I think he has a point somehow, I have no better solution. We eventually need some elibtoolize, perhaps, like the FreeBSD people need it for every libtoolized package.
pango problem seems to be caused by pkg-config --libs freetype not returning -L.... whereas it does for my ~amd64-linux system. % pkg-config --libs "freetype2" -L/ufs/fabian/scratch/programs/gentoo/usr/lib -lfreetype -lz
------------------------------------------------------------------------ r32036 | haubi | 2008-10-10 14:45:05 +0200 (Fri, 10 Oct 2008) | 2 lines besides /usr/{include,lib}, also filter EPREFIX/usr/{include,lib} from --{cflags,libs} output. (Portage version: 2.2.00.11505-prefix/svn/Linux 2.6.24-gentoo-r4 i686) now I reemerged pkgconfig my I no longer have the -L in there, and pango indeed nicely fails :( haubi what's the deal with this? To me it seems like it breaks more than it solves, or?...
(In reply to comment #9) > haubi what's the deal with this? To me it seems like it breaks more than it > solves, or?... Indeed - this was intended as a cleanup only, no particular reason AFAIR. Although relying on pkg-config returning prefix paths still feels hackish... Anyway: reverted r32036 in r33814, please try again. Thank you for pointing out!
(In reply to comment #10) > Anyway: reverted r32036 in r33814, please try again. > > Thank you for pointing out! > confirmed. seems fixed now.
