| 1 |
On Thu, October 30, 2008 23:04, Jeremy Olexa wrote: |
| 2 |
|
| 3 |
> You are right, I am wrong. I shoudn't have assumed that poppler-0.10.0 |
| 4 |
would behave the same as 0.8.7 |
| 5 |
> |
| 6 |
> x86_64-pc-linux-gnu-g++ -Wall -Wno-write-strings -O2 -pipe |
| 7 |
> -fomit-frame-pointer -o .libs/perf-test perf-test.o |
| 8 |
> perf-test-preview-dummy.o ../poppler/.libs/libpoppler.so |
| 9 |
> /usr/lib64/libfreetype.so -lopenjpeg -lz -Wl,--rpath |
| 10 |
> -Wl,/home/jolexa/portage/linux-64/usr/lib -Wl,--rpath -Wl,/usr/lib64 |
| 11 |
/home/jolexa/portage/linux-64/usr/lib/libfontconfig.so.1: undefined |
| 12 |
reference to `FT_Select_Size' |
| 13 |
> |
| 14 |
> So the question remains, where does that /usr/lib64/libfreetype.so bit |
| 15 |
come from and how do we fix it? Nothing jumps out at me in config.log |
| 16 |
and the Makefile. |
| 17 |
|
| 18 |
The reason why /usr/lib64/libfreetype.so is quite simple: |
| 19 |
poppler-0.10.0/configure is evaluating the output of |
| 20 |
"gcc -print-search-dirs" starting at line 9042. |
| 21 |
"$EPREFIX/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../lib64/" |
| 22 |
represents "$EPREFIX/usr/lib64" which does not exist without the multilib |
| 23 |
symlink $EPREFIX/usr/lib64. Thus the created poppler-0.10.0/libtool will |
| 24 |
have the variable "sys_lib_search_path_spec = |
| 25 |
$EPREFIX/usr/lib/gcc/x86_64-pc-linux-gnu/4.2.4 /lib64 /usr/lib64 |
| 26 |
$EPREFIX/usr/x86_64-pc-linux-gnu/lib $EPREFIX/usr/lib" |
| 27 |
and the wrong /usr/lib64/libfreetype.so is used due. |
| 28 |
If you run "cd $EPREFIX/usr/lib && ln -s lib lib64" poppler can be emerged |
| 29 |
without any problems. |
| 30 |
|
| 31 |
I do not really understand why the prefix gcc-4.2.4 is searching in |
| 32 |
$EPREFIX/usr/lib64 although this directory does not exist. Maybe a gcc |
| 33 |
ebuild (or toolchain.eclass) issue? Another issue could be that "/lib64 |
| 34 |
/usr/lib64" are not the last directories being looked at. |
| 35 |
|
| 36 |
Regards, |
| 37 |
Stefan |
Archives