Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
libpng-1.5.x entered stable - upgrade tips
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
CrazyCasta
n00b
n00b


Joined: 01 Sep 2011
Posts: 16

PostPosted: Mon Oct 24, 2011 3:04 am    Post subject: Reply with quote

Having trouble remerging wxGTK-2.9.1.1. Looks similar (if not exactly the same) to the R issue above:

Code:
/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/wxgtk_build/bk-deps x86_64-pc-linux-gnu-g++ -c -o coredll_imagxpm.o  -D__WXGTK__      -DWXBUILDING      -I/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/src/regex  -DWXUSINGDLL -DWXMAKINGDLL_CORE -DwxUSE_BASE=0 -fPIC -DPIC -Wall -Wundef -Wunused-parameter -Wno-ctor-dtor-privacy -Woverloaded-virtual -D_FILE_OFFSET_BITS=64 -I/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/wxgtk_build/lib/wx/include/gtk2-unicode-2.9 -I/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/include -pthread -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm -DG_DISABLE_CAST_CHECKS -pthread -pthread -I/usr/include/libgnomeprintui-2.2 -I/usr/include/libgnomeprint-2.2 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/libxml2 -I/usr/include/pango-1.0 -I/usr/include/gail-1.0 -I/usr/include/gtk-2.0 -I/usr/include/freetype2 -I/usr/include/atk-1.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pixman-1 -I/usr/include/libpng15 -I/usr/include/libdrm -march=core2 -mtune=core2 -O3 -pipe -fno-strict-aliasing -fvisibility=hidden -fvisibility-inlines-hidden /var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/src/common/imagxpm.cpp
/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/src/common/imagpng.cpp: In member function 'virtual bool wxPNGHandler::LoadFile(wxImage*, wxInputStream&, bool, int)':
/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/src/common/imagpng.cpp:524: error: 'voidp' was not declared in this scope
/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/src/common/imagpng.cpp:581: error: invalid use of incomplete type 'struct png_info_def'
/usr/include/libpng15/png.h:695: error: forward declaration of 'struct png_info_def'
/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/src/common/imagpng.cpp:588: error: invalid use of incomplete type 'struct png_info_def'
/usr/include/libpng15/png.h:695: error: forward declaration of 'struct png_info_def'
/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/src/common/imagpng.cpp:589: error: invalid use of incomplete type 'struct png_info_def'
/usr/include/libpng15/png.h:695: error: forward declaration of 'struct png_info_def'
/var/tmp/portage/x11-libs/wxGTK-2.9.1.1/work/wxPython-src-2.9.1.1/src/common/imagpng.cpp:590: error: invalid use of incomplete type 'struct png_info_def'
/usr/include/libpng15/png.h:695: error: forward declaration of 'struct png_info_def'


Thank you very much for this thread.
Back to top
View user's profile Send private message
audiodef
Watchman
Watchman


Joined: 06 Jul 2005
Posts: 5256

PostPosted: Mon Oct 24, 2011 12:42 pm    Post subject: ERROR: dev-python/pygoocanvas-0.14.1 failed Reply with quote

What happened, and how can I fix this?

Code:

>>> Emerging (1 of 1) dev-python/pygoocanvas-0.14.1
 * pygoocanvas-0.14.1.tar.bz2 RMD160 SHA1 SHA256 size ;-) ...                                                                                                                          [ ok ]
>>> Unpacking source...
>>> Unpacking pygoocanvas-0.14.1.tar.bz2 to /var/tmp/portage/dev-python/pygoocanvas-0.14.1/work
>>> Source unpacked in /var/tmp/portage/dev-python/pygoocanvas-0.14.1/work
>>> Preparing source in /var/tmp/portage/dev-python/pygoocanvas-0.14.1/work/pygoocanvas-0.14.1 ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/dev-python/pygoocanvas-0.14.1/work/pygoocanvas-0.14.1 ...
 * Configuration of dev-python/pygoocanvas-0.14.1 with CPython 2.7...
 * econf: updating pygoocanvas-0.14.1/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating pygoocanvas-0.14.1/config.sub with /usr/share/gnuconfig/config.sub
 * econf: updating pygoocanvas-0.14.1-2.7/config.guess with /usr/share/gnuconfig/config.guess
 * econf: updating pygoocanvas-0.14.1-2.7/config.sub with /usr/share/gnuconfig/config.sub
./configure --prefix=/usr --build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib64 --disable-docs --disable-gtk-doc
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking for some Win32 platform... no
checking for native Win32... no
checking for style of include used by make... GNU
checking for x86_64-pc-linux-gnu-gcc... x86_64-pc-linux-gnu-gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether x86_64-pc-linux-gnu-gcc accepts -g... yes
checking for x86_64-pc-linux-gnu-gcc option to accept ISO C89... none needed
checking dependency style of x86_64-pc-linux-gnu-gcc... gcc3
checking for a sed that does not truncate output... /bin/sed
checking for grep that handles long lines and -e... /bin/grep
checking for egrep... /bin/grep -E
checking for fgrep... /bin/grep -F
checking for ld used by x86_64-pc-linux-gnu-gcc... /usr/x86_64-pc-linux-gnu/bin/ld
checking if the linker (/usr/x86_64-pc-linux-gnu/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking whether the shell understands some XSI constructs... yes
checking whether the shell understands "+="... yes
checking for /usr/x86_64-pc-linux-gnu/bin/ld option to reload object files... -r
checking for x86_64-pc-linux-gnu-objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for x86_64-pc-linux-gnu-ar... x86_64-pc-linux-gnu-ar
checking for x86_64-pc-linux-gnu-strip... x86_64-pc-linux-gnu-strip
checking for x86_64-pc-linux-gnu-ranlib... x86_64-pc-linux-gnu-ranlib
checking command to parse /usr/bin/nm -B output from x86_64-pc-linux-gnu-gcc object... ok
checking how to run the C preprocessor... x86_64-pc-linux-gnu-gcc -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if x86_64-pc-linux-gnu-gcc supports -fno-rtti -fno-exceptions... no
checking for x86_64-pc-linux-gnu-gcc option to produce PIC... -fPIC -DPIC
checking if x86_64-pc-linux-gnu-gcc PIC flag -fPIC -DPIC works... yes
checking if x86_64-pc-linux-gnu-gcc static flag -static works... yes
checking if x86_64-pc-linux-gnu-gcc supports -c -o file.o... yes
checking if x86_64-pc-linux-gnu-gcc supports -c -o file.o... (cached) yes
checking whether the x86_64-pc-linux-gnu-gcc linker (/usr/x86_64-pc-linux-gnu/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... no
configure: creating ./config.lt
config.lt: creating libtool
checking whether x86_64-pc-linux-gnu-gcc and cc understand -c and -o together... yes
checking for a Python interpreter with version >= 2.2... python
checking for python... /usr/bin/python
checking for python version... 2.7
checking for python platform... linux2
checking for python script directory... /usr/lib64/python2.7/site-packages
checking for python extension module directory... /usr/lib64/python2.7/site-packages
checking for headers required to compile python extensions... found
checking for Python library path... /usr/lib64
checking for x86_64-pc-linux-gnu-pkg-config... no
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for PYGOBJECT... yes
checking for PYGOOCANVAS... yes
checking for pygtk codegen... yes
checking whether x86_64-pc-linux-gnu-gcc understands -Wall... yes
checking whether x86_64-pc-linux-gnu-gcc understands -std=c9x... yes
checking whether x86_64-pc-linux-gnu-gcc understands -fno-strict-aliasing... yes
checking whether to build gtk-doc documentation... no
checking for gtkdoc-check... no
configure: creating ./config.status
config.status: creating Makefile
config.status: creating demo/Makefile
config.status: creating docs/Makefile
config.status: creating docs/reference/entities.docbook
config.status: creating pygoocanvas.pc
config.status: creating config.h
config.status: executing depfiles commands
config.status: executing libtool commands
>>> Source configured.
>>> Compiling source in /var/tmp/portage/dev-python/pygoocanvas-0.14.1/work/pygoocanvas-0.14.1 ...
 * Building of dev-python/pygoocanvas-0.14.1 with CPython 2.7...
make
make  all-recursive
make[1]: Entering directory `/var/tmp/portage/dev-python/pygoocanvas-0.14.1/work/pygoocanvas-0.14.1-2.7'
make[2]: Entering directory `/var/tmp/portage/dev-python/pygoocanvas-0.14.1/work/pygoocanvas-0.14.1-2.7'
/bin/sh ./libtool --tag=CC   --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/usr/include/python2.7   -pthread -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/goocanvas-1.0 -I/usr/include/pycairo   -O2 -pipe -Wall -std=c9x -fno-strict-aliasing -MT goocanvasmodule_la-goocanvasmodule.lo -MD -MP -MF .deps/goocanvasmodule_la-goocanvasmodule.Tpo -c -o goocanvasmodule_la-goocanvasmodule.lo `test -f 'goocanvasmodule.c' || echo './'`goocanvasmodule.c
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/usr/include/python2.7 -pthread -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/goocanvas-1.0 -I/usr/include/pycairo -O2 -pipe -Wall -std=c9x -fno-strict-aliasing -MT goocanvasmodule_la-goocanvasmodule.lo -MD -MP -MF .deps/goocanvasmodule_la-goocanvasmodule.Tpo -c goocanvasmodule.c  -fPIC -DPIC -o .libs/goocanvasmodule_la-goocanvasmodule.o
mv -f .deps/goocanvasmodule_la-goocanvasmodule.Tpo .deps/goocanvasmodule_la-goocanvasmodule.Plo
(cd .\
&& /usr/bin/python /usr/lib64/python2.7/site-packages/gtk-2.0/codegen/codegen.py \
   --override goocanvas.override \
   --load-types arg-types.py \
   --register /usr/share/pygtk/2.0/defs/gdk-types.defs \
   --register /usr/share/pygtk/2.0/defs/pango-types.defs \
   --register /usr/share/pygtk/2.0/defs/gtk-types.defs \
   --prefix pygoocanvas goocanvas.defs) > gen-goocanvas.c \
   && cp gen-goocanvas.c goocanvas.c \
   && rm -f gen-goocanvas.c
Could not write virtual accessor method GooCanvasItem.get_child_property: No ArgType for GValue*
Could not write virtual accessor method GooCanvasItem.set_child_property: No ArgType for const-GValue*
Could not write virtual accessor method GooCanvasItem.get_items_at: No ArgType for GList*
Could not write virtual accessor method GooCanvasItem.child_notify: No ArgType for GParamSpec*
Could not write interface proxy GooCanvasItem.get_child_property: No ArgType for GValue*
Could not write interface proxy GooCanvasItem.set_child_property: No ArgType for const-GValue*
Could not write interface proxy GooCanvasItem.get_transform_for_child: No ArgType for cairo_matrix_t*
Could not write interface proxy GooCanvasItem.get_items_at: No ArgType for GList*
Could not write interface proxy GooCanvasItem.get_transform: No ArgType for cairo_matrix_t*
Could not write interface proxy GooCanvasItem.set_transform: No ArgType for cairo_matrix_t*
Could not write interface proxy GooCanvasItem.child_notify: No ArgType for GParamSpec*
Could not write virtual accessor method GooCanvasItemModel.get_child_property: No ArgType for GValue*
Could not write virtual accessor method GooCanvasItemModel.set_child_property: No ArgType for const-GValue*
Could not write virtual accessor method GooCanvasItemModel.child_notify: No ArgType for GParamSpec*
Could not write interface proxy GooCanvasItemModel.get_child_property: No ArgType for GValue*
Could not write interface proxy GooCanvasItemModel.set_child_property: No ArgType for const-GValue*
Could not write interface proxy GooCanvasItemModel.get_transform: No ArgType for cairo_matrix_t*
Could not write interface proxy GooCanvasItemModel.set_transform: No ArgType for cairo_matrix_t*
Could not write interface proxy GooCanvasItemModel.child_notify: No ArgType for GParamSpec*
Could not write function goo_canvas_parse_path_data: No ArgType for GArray*
Could not write function goo_canvas_create_path: No ArgType for GArray*
Warning: Constructor for GooCanvas needs to be updated to new API
         See http://live.gnome.org/PyGTK_2fWhatsNew28#update-constructors
***INFO*** The coverage of global functions is 66.67% (4/6)
***INFO*** The coverage of methods is 100.00% (134/134)
***INFO*** The coverage of virtual proxies is 100.00% (7/7)
***INFO*** The coverage of virtual accessors is 89.06% (57/64)
***INFO*** The coverage of interface proxies is 78.95% (45/57)
/bin/sh ./libtool --tag=CC   --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/usr/include/python2.7   -pthread -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/goocanvas-1.0 -I/usr/include/pycairo   -O2 -pipe -Wall -std=c9x -fno-strict-aliasing -MT goocanvasmodule_la-goocanvas.lo -MD -MP -MF .deps/goocanvasmodule_la-goocanvas.Tpo -c -o goocanvasmodule_la-goocanvas.lo `test -f 'goocanvas.c' || echo './'`goocanvas.c
libtool: compile:  x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I/usr/include/python2.7 -pthread -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/goocanvas-1.0 -I/usr/include/pycairo -O2 -pipe -Wall -std=c9x -fno-strict-aliasing -MT goocanvasmodule_la-goocanvas.lo -MD -MP -MF .deps/goocanvasmodule_la-goocanvas.Tpo -c goocanvas.c  -fPIC -DPIC -o .libs/goocanvasmodule_la-goocanvas.o
mv -f .deps/goocanvasmodule_la-goocanvas.Tpo .deps/goocanvasmodule_la-goocanvas.Plo
/bin/sh ./libtool --tag=CC   --mode=link x86_64-pc-linux-gnu-gcc -pthread -I/usr/include/pygtk-2.0 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng15 -I/usr/include/libdrm -I/usr/include/goocanvas-1.0 -I/usr/include/pycairo   -O2 -pipe -Wall -std=c9x -fno-strict-aliasing -module -avoid-version -no-undefined -export-symbols-regex initgoocanvas -Wl,-O1 -Wl,--as-needed -o goocanvasmodule.la -rpath /usr/lib64/python2.7/site-packages goocanvasmodule_la-goocanvasmodule.lo goocanvasmodule_la-goocanvas.lo -pthread -lgoocanvas -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcairo -L/usr/lib64 -lpython2.7
libtool: link: /usr/bin/nm -B  .libs/goocanvasmodule_la-goocanvasmodule.o .libs/goocanvasmodule_la-goocanvas.o   | sed -n -e 's/^.*[    ]\([ABCDGIRSTW][ABCDGIRSTW]*\)[    ][    ]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | /bin/sed 's/.* //' | sort | uniq > .libs/goocanvasmodule.exp
libtool: link: /bin/grep -E -e "initgoocanvas" ".libs/goocanvasmodule.exp" > ".libs/goocanvasmodule.expT"
libtool: link: mv -f ".libs/goocanvasmodule.expT" ".libs/goocanvasmodule.exp"
libtool: link: echo "{ global:" > .libs/goocanvasmodule.ver
libtool: link:  cat .libs/goocanvasmodule.exp | sed -e "s/\(.*\)/\1;/" >> .libs/goocanvasmodule.ver
libtool: link:  echo "local: *; };" >> .libs/goocanvasmodule.ver
libtool: link:  x86_64-pc-linux-gnu-gcc -shared  .libs/goocanvasmodule_la-goocanvasmodule.o .libs/goocanvasmodule_la-goocanvas.o   /usr/lib64/libgoocanvas.so -L/usr/lib64 -lresolv -lm -lpng14 -lexpat -lz -ldl -lgtk-x11-2.0 -lgdk-x11-2.0 /usr/lib64/libatk-1.0.so -lpthread -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lcairo -lpython2.7  -pthread -Wl,-O1 -Wl,--as-needed -pthread   -pthread -Wl,-soname -Wl,goocanvasmodule.so -Wl,-version-script -Wl,.libs/goocanvasmodule.ver -o .libs/goocanvasmodule.so
/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lpng14
collect2: ld returned 1 exit status
make[2]: *** [goocanvasmodule.la] Error 1
make[2]: Leaving directory `/var/tmp/portage/dev-python/pygoocanvas-0.14.1/work/pygoocanvas-0.14.1-2.7'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/dev-python/pygoocanvas-0.14.1/work/pygoocanvas-0.14.1-2.7'
make: *** [all] Error 2
emake failed
 * ERROR: dev-python/pygoocanvas-0.14.1 failed (compile phase):
 *   Building failed with CPython 2.7 in python_default_function() function
 *
 * Call stack:
 *     ebuild.sh, line   91:  Called src_compile
 *   environment, line 5735:  Called python_src_compile
 *   environment, line 5589:  Called python_execute_function '-d' '-s' '--'
 *   environment, line 4072:  Called die
 * The specific snippet of code:
 *                       die "${failure_message}";
 *
 * If you need support, post the output of 'emerge --info =dev-python/pygoocanvas-0.14.1',
 * the complete build log and the output of 'emerge -pqv =dev-python/pygoocanvas-0.14.1'.
 * The complete build log is located at '/var/tmp/portage/dev-python/pygoocanvas-0.14.1/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/dev-python/pygoocanvas-0.14.1/temp/environment'.
 * S: '/var/tmp/portage/dev-python/pygoocanvas-0.14.1/work/pygoocanvas-0.14.1'

_________________
Gentoo Studio: http://gentoostudio.org
Facebook: http://www.facebook.com/gentoostudio
G+: https://plus.google.com/113947758237122861689/posts
Pappy's Kernel Seeds: http://kernel-seeds.org
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2127
Location: Finland

PostPosted: Mon Oct 24, 2011 2:35 pm    Post subject: Reply with quote

CrazyCasta wrote:
Having trouble remerging wxGTK-2.9.1.1. Looks similar (if not exactly the same) to the R issue above:


EDIT: This should be fixed in Portage now according to http://bugs.gentoo.org/384037


Last edited by ssuominen on Tue Oct 25, 2011 12:50 pm; edited 1 time in total
Back to top
View user's profile Send private message
Hu
Watchman
Watchman


Joined: 06 Mar 2007
Posts: 8905

PostPosted: Mon Oct 24, 2011 11:24 pm    Post subject: Reply with quote

The build asked for libpng14.so, but did not find it. What is the output of emerge --info ; emerge --pretend --verbose media-libs/libpng?
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2127
Location: Finland

PostPosted: Tue Oct 25, 2011 2:46 am    Post subject: Reply with quote

No, you don't need libpng14.so. Read first post from this thread.

Last edited by ssuominen on Tue Oct 25, 2011 12:53 pm; edited 2 times in total
Back to top
View user's profile Send private message
cach0rr0
Moderator
Moderator


Joined: 13 Nov 2008
Posts: 4121
Location: Houston, Republic of Texas

PostPosted: Tue Oct 25, 2011 2:53 am    Post subject: Reply with quote

Code:
ricker ~ # eselect news read new
2011-10-15-libpng15
  Title                     Upgrade to libpng15
  Author                    Samuli Suominen <ssuominen@gentoo.org>
  Posted                    2011-10-15
  Revision                  1

After upgrading from libpng14 to libpng15 it's important that you rebuild
cairo and gdk-pixbuf as soon as possible if they are installed.

Then you can proceed with rebuilding the rest of the software against the new
library:

# revdep-rebuild --library libpng14.so.14 -- --keep-going

Note: It might be necessary to run the previous command more than once.

If you find packages not building with the message "ld: cannot find -lpng14",
they are likely caused by broken libtool archives (.la) in your system.

You can identify those files with following one-liner:

# find /usr/ -name '*.la' -exec grep png14 {} +

Once you have identified the broken files, you can either delete them,
edit them in place and replace png14 with png15, or re-emerge the packages
they belong to.

More information and help is available at the following forum post:

http://forums.gentoo.org/viewtopic-t-894950.html


_________________
Lost configuring your system?
dump lspci -n here | see Pappy's guide | Link Stash
Back to top
View user's profile Send private message
nickel
Tux's lil' helper
Tux's lil' helper


Joined: 21 Oct 2005
Posts: 146

PostPosted: Thu Nov 03, 2011 2:41 pm    Post subject: Reply with quote

thank you very very very much!
I've got this problem with lpng14. Now it's solved
Back to top
View user's profile Send private message
hurricane
Tux's lil' helper
Tux's lil' helper


Joined: 15 Jul 2004
Posts: 100

PostPosted: Sat Nov 05, 2011 7:54 am    Post subject: Haskell packages may still fail Reply with quote

Hey, I just found out, that some Haskell packages (from the haskell overlay) may still not work after this. And haskell-updater sadly also fails because of that. But I have a solution:

This does a deep update of all png14-dependent packages that would be updated by haskell-updater anyways:
Code:
emerge -auD1tv $( fgrep -R -l png14 /usr/lib/ghc-*/gentoo | while read P; do echo "dev-haskell/$(basename $P | sed 's/-[0-9.]*\(-r[0-9]*\)\?\.conf//')"; done )

So those are good now and won’t show up in the next command anymore.

The following command now identifies all png14-dependent packages that still need recompiling:
Code:
emerge -a1tv $( fgrep -R -l png14 /usr/lib/ghc-*/gentoo | while read P; do echo "dev-haskell/$(basename $P | sed 's/-[0-9.]*\(-r[0-9]*\)\?\.conf//')"; done )


After that, haskell-updater should work and do the rest.

------------------------------------------------------------------------------------------------------------------

Oh, and apparently, I had leftover libpng14.so* in /usr/lib32/ that had to be deleted first, before doing the above.
Back to top
View user's profile Send private message
Joseph_sys
Advocate
Advocate


Joined: 08 Jun 2004
Posts: 2379
Location: Edmonton, AB

PostPosted: Sun Nov 06, 2011 1:47 am    Post subject: Re: Haskell packages may still fail Reply with quote

hurricane wrote:

The following command now identifies all png14-dependent packages that still need recompiling:
Code:
emerge -a1tv $( fgrep -R -l png14 /usr/lib/ghc-*/gentoo | while read P; do echo "dev-haskell/$(basename $P | sed 's/-[0-9.]*\(-r[0-9]*\)\?\.conf//')"; done )


There is something wrong the above command, it doesn't work.

Anyhow, revded-rebuild is showing:
broken /usr/lib64/libgtksourceview-1.0.la (requires -lpng14)

find /usr/ -name '*.la' -exec grep png14 {} +
is finding libgtksourceview-1.0.la
Code:
find /usr/ -name '*.la' -exec grep png14 {} + /usr/lib64/libgtksourceview-1.0.la:dependency_libs=' -L/usr/lib64 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpixman-1 -lpng14 -lXrender -lX11 -lXau -lXdmcp -lfreetype -lfontconfig -lgnomeprint-2-2 -lart_lgpl_2 -lpango-1.0 -lxml2 -lexpat -lz -lgobject-2.0 -lgmodule-2.0 -lm -ldl -lglib-2.0'


Do I just delete the libgtksourceview-1.0.la?
How do I find out which package is using it?

I re-emerge "gtksourceview" but it doesn't seem to help.
It seems to me there are as many solution as there are post here but nothing seems to work :-/
_________________
#Joseph
Back to top
View user's profile Send private message
Joseph_sys
Advocate
Advocate


Joined: 08 Jun 2004
Posts: 2379
Location: Edmonton, AB

PostPosted: Sun Nov 06, 2011 2:17 am    Post subject: Reply with quote

Polynomial-C wrote:
Hmm... I really cannot imagine where that -lpng14 could come from...

If you guys have time and ressources to waste (;)) you might try the following:
Code:
grep -r "png14" /usr

If you get some helpful results please let us know which ones so I can adjust my first post accordingly.


Here is my partial output. What do I do with it?
Code:
grep -r "png14" /usr
/usr/local/portage/layman/kde-sunset/media-gfx/digikam/ChangeLog:  Backport libpng14 patch from portage tree.
/usr/local/portage/layman/kde-sunset/x11-libs/qt/Manifest:AUX qt-3.3.8-libpng14.patch 1680 RMD160 922a2ff3c98eb871e860ddd09b4ef2fe291f1687 SHA1 6532104043beef4ef57981dd1598aa0ffc0c2b73 SHA256 d4b63e1d2df1cf15e30f611fe04de1e1ad4ec48e2fce609f18797534f808da30
/usr/local/portage/layman/kde-sunset/x11-libs/qt/qt-3.3.8b-r2.ebuild:   epatch "${FILESDIR}"/qt-3.3.8-libpng14.patch
Binary file /usr/local/portage/layman/kde-sunset/.git/objects/pack/pack-dc80faf9ceb61c402dafe9812d96cfe6d486701f.pack matches
Binary file /usr/local/portage/layman/kde-sunset/.git/index matches
/usr/tmp/ccache/a/8/c3e53fe5db99baa7f4734b28b328f9-2017196.stderr:file-mng.c:972: warning: 'jmpbuf' is deprecated (declared at /usr/include/libpng14/png.h:1096)
/usr/tmp/ccache/a/8/c3e53fe5db99baa7f4734b28b328f9-2017196.stderr:file-mng.c:984: warning: 'width' is deprecated (declared at /usr/include/libpng14/png.h:639)
/usr/tmp/ccache/a/8/c3e53fe5db99baa7f4734b28b328f9-2017196.stderr:file-mng.c:985: warning: 'height' is deprecated (declared at /usr/include/libpng14/png.h:640)
/usr/tmp/ccache/a/8/c3e53fe5db99baa7f4734b28b328f9-2017196.stderr:file-mng.c:986: warning: 'interlace_type' is deprecated (declared at /usr/include/libpng14/png.h:660)
...

I don't run any kde-sunset application:
layman -l doesn't show anything.

UPDATE.
Solved mine.
nano -w /usr/lib64/libgtksourceview-1.0.la
changed: -lpng14 to -lpng15

Why didn't portage do it?
_________________
#Joseph
Back to top
View user's profile Send private message
Polynomial-C
Developer
Developer


Joined: 01 Jun 2003
Posts: 1391
Location: germany

PostPosted: Sun Nov 06, 2011 8:06 am    Post subject: Reply with quote

Joseph_sys wrote:
UPDATE.
Solved mine.
nano -w /usr/lib64/libgtksourceview-1.0.la
changed: -lpng14 to -lpng15

Why didn't portage do it?

Should have been covered by the script from my first post as long as the file still belongs to some package. Did you check if this file belongs to any installed package? Does the following command return any package name?
Code:
qfile -C /usr/lib64/libgtksourceview-1.0.la

If not you can remove the file followed by another revdep-rebuild run.
_________________
The manual said "Requires Windows7 or better" so I installed GNU/Linux...

my portage overlay

Need a stage1 tarball? (Unofficial builds)
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2127
Location: Finland

PostPosted: Sun Nov 06, 2011 8:24 am    Post subject: Reply with quote

Joseph_sys wrote:

Code:
grep -r "png14" /usr
/usr/local/portage/layman/kde-sunset/media-gfx/digikam/ChangeLog:  Backport libpng14 patch from portage tree.
/usr/local/portage/layman/kde-sunset/x11-libs/qt/Manifest:AUX qt-3.3.8-libpng14.patch 1680 RMD160 922a2ff3c98eb871e860ddd09b4ef2fe291f1687 SHA1 6532104043beef4ef57981dd1598aa0ffc0c2b73 SHA256 d4b63e1d2df1cf15e30f611fe04de1e1ad4ec48e2fce609f18797534f808da30
/usr/local/portage/layman/kde-sunset/x11-libs/qt/qt-3.3.8b-r2.ebuild:   epatch "${FILESDIR}"/qt-3.3.8-libpng14.patch
Binary file /usr/local/portage/layman/kde-sunset/.git/objects/pack/pack-dc80faf9ceb61c402dafe9812d96cfe6d486701f.pack matches
Binary file /usr/local/portage/layman/kde-sunset/.git/index matches

I don't run any kde-sunset application:
layman -l doesn't show anything.

nano -w /usr/lib64/libgtksourceview-1.0.la
changed: -lpng14 to -lpng15


I'm nearly sure /usr/local/portage/layman is the old location for layman which is now moved somewhere in /var/lib. Therefore I would "rm -rf /usr/local/portage/layman" to free some disk space.

Also libgtksourceview-1.0.la is completely useless, so instead of editing it, remove it.
Back to top
View user's profile Send private message
Joseph_sys
Advocate
Advocate


Joined: 08 Jun 2004
Posts: 2379
Location: Edmonton, AB

PostPosted: Sun Nov 06, 2011 4:34 pm    Post subject: Reply with quote

Polynomial-C wrote:
Joseph_sys wrote:
UPDATE.
Solved mine.
nano -w /usr/lib64/libgtksourceview-1.0.la
changed: -lpng14 to -lpng15

Why didn't portage do it?

Should have been covered by the script from my first post as long as the file still belongs to some package. Did you check if this file belongs to any installed package? Does the following command return any package name?
Code:
qfile -C /usr/lib64/libgtksourceview-1.0.la

If not you can remove the file followed by another revdep-rebuild run.


libgtksourceview belong to gtksourceview
Code:
qfile -C /usr/lib64/libgtksourceview-1.0.la
x11-libs/gtksourceview (/usr/lib64/libgtksourceview-1.0.la)
and
Code:
 depend on x11-libs/gtksourceview:
dev-python/gtksourceview-python-2.32.0 (x11-libs/gtksourceview:1.0)
dev-python/pygtksourceview-2.10.1 (>=x11-libs/gtksourceview-2.9.7:2.0)

so I think my system still need this one. Nothing depends on gtksourceview-python but pygtksourceview gives me:
Code:
equery d dev-python/pygtksourceview
 * These packages depend on dev-python/pygtksourceview:
dev-vcs/git-1.7.3.4-r1 (gtk ? dev-python/pygtksourceview:2)

_________________
#Joseph
Back to top
View user's profile Send private message
Chiitoo
l33t
l33t


Joined: 28 Feb 2010
Posts: 849
Location: Here and Away Again

PostPosted: Mon Nov 14, 2011 1:30 am    Post subject: Reply with quote

I wonder if there is a way to work around with the libpng14 requirement of media-video/glc-0.5.8 or rather if anyone has the sources for it since the site has been down for quite a while now. Been wondering what happened to the Author. S:

The 9999 version is found, but it seems to have some issues though it is still usable. I would like to play around with the 0.5.8 version too, but have removed the sources for quite some time ago from my machine. >.<

Best to post about this somewhere else I guess, but the related question is that if there really is no other way to go around it than re-building?
_________________
Kind Regards,
~ The Noob Unlimited ~

Sore wa sore, kore wa kore.
Back to top
View user's profile Send private message
gkmac
Guru
Guru


Joined: 19 Jan 2003
Posts: 323
Location: West Sussex, UK

PostPosted: Mon Nov 14, 2011 9:50 pm    Post subject: Reply with quote

If you have games-action/supertuxkart installed, then after upgrading to libpng-1.5 you will need to re-emerge dev-games/irrlicht first and then re-emerge supertuxkart.

Otherwise supertuxkart will build fine but still fail to run; neither "emerge preserved-rebuild" nor "revdep-rebuild" caught this one.
_________________
If ~amd64 ebuilds are cutting edge, then git-9999 ebuilds are chainsaws.
"Not everyone can ride a unicycle, does that mean we should put another wheel on it?" - Lokheed
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5227
Location: France, Old Europe

PostPosted: Tue Nov 22, 2011 4:06 am    Post subject: Reply with quote

ssuominen wrote:
equaeghe wrote:
After the upgrade, what should I do with:

/usr/lib64/libpng14.so
/usr/lib64/libpng14.so.14
/usr/lib64/libpng14.so.14.8.0

and

/usr/lib32/libpng14.so
/usr/lib32/libpng14.so.14
/usr/lib32/libpng14.so.14.8.0


If you still have /usr/lib64/libpng14.so, then you never upgraded. Ask again after upgrading.



Code:
[ Searching for package 'libpng' in all categories among: ]
 * installed packages
[I--] [M ] media-libs/libpng-1.2.44 (1.2)
[I--] [ ~] media-libs/libpng-1.4.8-r2 (1.4)
[I--] [ ~] media-libs/libpng-1.5.6 (0)


so why are these things slotted if they are not supposed to be installed concurrently?

I still have two or three (usual suspects to judge bvy other posts) that fail to find libpng14 during build even though it IS installed.

What a mess this is.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.

AthlonXP-M on A7N8X @ 2.6/2.4GHz (winter/summer)
2.6.32-hh1 : portage ~x86
Back to top
View user's profile Send private message
maverick6664
Guru
Guru


Joined: 13 May 2005
Posts: 409
Location: Tokyo / Japan

PostPosted: Tue Nov 22, 2011 5:53 am    Post subject: Reply with quote

Gentree wrote:


Code:
[ Searching for package 'libpng' in all categories among: ]
 * installed packages
[I--] [M ] media-libs/libpng-1.2.44 (1.2)
[I--] [ ~] media-libs/libpng-1.4.8-r2 (1.4)
[I--] [ ~] media-libs/libpng-1.5.6 (0)


so why are these things slotted if they are not supposed to be installed concurrently?

I still have two or three (usual suspects to judge bvy other posts) that fail to find libpng14 during build even though it IS installed.

What a mess this is.


I'm not sure of 14/15, but I found google-talkplugin requires libpng-1.2. So at least 2 versions are necessary concurrently.
_________________
Tetsuji Rai
a.k.a. Lukiest in the world
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5227
Location: France, Old Europe

PostPosted: Tue Nov 22, 2011 10:35 am    Post subject: Reply with quote

Code:
su-4.1#find /usr \( -name "*.la" -o -name "*.pc" -o -name "*-config" -o -name "*.pm" \) -exec grep -H png14 {} \; | cut -d : -f 1 | xargs qfile -CSq | sort | uniq
dev-python/notify-python:0
media-gfx/gimp:2
net-print/gutenprint:0
www-plugins/gnash:0
x11-libs/goffice:0.6


I unmerged and remerged media-libs/libpng-1.4.8-r2 . That cleared some of the problems and a few packages started to play ball.

However, after having spent the night fighting with portage instead of sleeping I now still have four recalcitrants that barf on not finding a library that I have on the system.

So where do I go from here?
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.

AthlonXP-M on A7N8X @ 2.6/2.4GHz (winter/summer)
2.6.32-hh1 : portage ~x86
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5227
Location: France, Old Europe

PostPosted: Wed Nov 23, 2011 12:32 pm    Post subject: Reply with quote

Is there any resolution of this mess yet ?

Four packages seem incapable of building with libpng1.4 and libpng1.5 present so I removed 1.4 again and it just gets worse. Now two days worth of screwing around with this "upgrade" . LOL.

I have half my gentoo system in bits. cupsddk is now out, that means no cups no printing. Still half a dozen packages that fail to build .

Printing is kinda important so lets start with that:

Code:
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_read_end@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_set_interlace_handling@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_init_io@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_set_packing@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_create_read_struct@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_create_info_struct@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_read_row@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_destroy_read_struct@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_get_valid@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_get_IHDR@PNG14_0'
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../libcupsimage.so: undefined reference to `png_get_x_pixels_per_meter@PNG14_0'
collect2: ld returned 1 exit status
make[1]: *** [rastertoescpx] Error 1


This was not pulled in by cups ebuild but cups fails because it can't find some cupsphp stuff. I have php 5.3 and 5.4 installed.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.

AthlonXP-M on A7N8X @ 2.6/2.4GHz (winter/summer)
2.6.32-hh1 : portage ~x86
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5227
Location: France, Old Europe

PostPosted: Wed Nov 23, 2011 12:56 pm    Post subject: Reply with quote

others still failing:

ghostscript-gpl
gdl
gnash
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.

AthlonXP-M on A7N8X @ 2.6/2.4GHz (winter/summer)
2.6.32-hh1 : portage ~x86
Back to top
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4241

PostPosted: Wed Nov 23, 2011 3:07 pm    Post subject: Reply with quote

Why we don't have a kinda fake wraper for libpng hell ? As it seems anything build against libpng12 can be just rebuild without change with libpng15 so it's not really a compatibility problem no ? And we could then link all programs using libpng to "libpng-wrapper.so" and symlink that wrapper to the current libpng version install/in use.

Or should we just wait libpng16 stikes ?
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5227
Location: France, Old Europe

PostPosted: Fri Nov 25, 2011 4:28 pm    Post subject: Reply with quote

Code:
libtool: link: i686-pc-linux-gnu-gcc -Disfinite=finite -march=athlon-xp -O2 -pipe -fomit-frame-pointer -falign-functions=64 -fgnu89-inline -Wl,-O1 -o .libs/rastertogutenprint.5.2 rastertoprinter.o i18n.o  -Wl,--as-needed ../../src/main/.libs/libgutenprint.so -ldl -lcupsimage -lcups /usr/lib/libtiff.so -L/usr/lib -lc /usr/lib/libjpeg.so -lpng -lssl -lcrypto -lz -lpthread -lm -lcrypt
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../../i686-pc-linux-gnu/bin/ld: warning: libpng14.so.14, needed by /usr/lib/libcupsimage.so, not found (try using -rpath or -rpath-link)
/usr/lib/libcupsimage.so: undefined reference to `png_set_background@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_get_y_pixels_per_meter@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_set_strip_16@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_read_info@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_set_tRNS_to_alpha@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_set_expand@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_read_end@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_set_interlace_handling@PNG14_0'
/u


gutenprint: nicht so guten.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.

AthlonXP-M on A7N8X @ 2.6/2.4GHz (winter/summer)
2.6.32-hh1 : portage ~x86
Back to top
View user's profile Send private message
ssuominen
Developer
Developer


Joined: 30 Sep 2005
Posts: 2127
Location: Finland

PostPosted: Fri Nov 25, 2011 6:51 pm    Post subject: Reply with quote

Gentree wrote:
Code:
libtool: link: i686-pc-linux-gnu-gcc -Disfinite=finite -march=athlon-xp -O2 -pipe -fomit-frame-pointer -falign-functions=64 -fgnu89-inline -Wl,-O1 -o .libs/rastertogutenprint.5.2 rastertoprinter.o i18n.o  -Wl,--as-needed ../../src/main/.libs/libgutenprint.so -ldl -lcupsimage -lcups /usr/lib/libtiff.so -L/usr/lib -lc /usr/lib/libjpeg.so -lpng -lssl -lcrypto -lz -lpthread -lm -lcrypt
/usr/lib/gcc/i686-pc-linux-gnu/4.5.1/../../../../i686-pc-linux-gnu/bin/ld: warning: libpng14.so.14, needed by /usr/lib/libcupsimage.so, not found (try using -rpath or -rpath-link)
/usr/lib/libcupsimage.so: undefined reference to `png_set_background@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_get_y_pixels_per_meter@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_set_strip_16@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_read_info@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_set_tRNS_to_alpha@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_set_expand@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_read_end@PNG14_0'
/usr/lib/libcupsimage.so: undefined reference to `png_set_interlace_handling@PNG14_0'
/u


gutenprint: nicht so guten.


The post has all the information required to solve the issue. It's really simple logic. First find out what package owns the file called libcupsimage.so. You can use portage-utils (qfile) or gentoolkit (equery) for that. Then re-emerge (emerge -1) or temporarily uninstall (emerge -C) the package owning it.
Back to top
View user's profile Send private message
Gentree
Watchman
Watchman


Joined: 01 Jul 2003
Posts: 5227
Location: France, Old Europe

PostPosted: Sat Nov 26, 2011 5:48 am    Post subject: Reply with quote

Code:
Compiling ipptest.c...
Linking ipptest...
Making all in scripting/php...
Compiling phpcups.c...
phpcups.c:43:16: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'phpcups_functions'
phpcups.c:64:3: error: 'phpcups_functions' undeclared here (not in a function)
make[1]: *** [phpcups.o] Error 1
make: *** [all] Error 1
emake failed
 * ERROR: net-print/cups-1.4.8-r22 failed (compile phase):
 *   emake failed
 *
 * Call stack:
 *     ebuild.sh, line  84:  Called src_compile
 *   environment, line 8621:  Called die
 * The specific snippet of code:


so cups fails as stated a few posts back.

Code:
gdlgstream.hpp: In constructor 'GDLGStream::GDLGStream(int, int, const char*, const char*)':
gdlgstream.hpp:53:82: error: no matching function for call to 'GDLGStream::string(const char [49])'
/usr/include/plplot/plstream.h:851:10: note: candidate is: void plstream::string(PLINT, const PLFLT*, const PLFLT*, const char*)
gdlgstream.hpp: In static member function 'static bool GDLGStream::checkPlplotDriver(const char*)':
gdlgstream.hpp:106:41: error: no matching function for call to 'GDLGStream::string(const char*&)'
/usr/include/plplot/plstream.h:851:10: note: candidate is: void plstream::string(PLINT, const PLFLT*, const PLFLT*, const char*)
gdlgstream.hpp:114:67: error: no matching function for call to 'GDLGStream::string(const char*&)'
/usr/include/plplot/plstream.h:851:10: note: candidate is: void plstream::string(PLINT, const PLFLT*, const PLFLT*, const char*)
make[3]: *** [gdl-gdleventhandler.o] Error 1
make[3]: Leaving directory `/back/tmp/portage/dev-lang/gdl-0.9.1/work/gdl-0.9.1/src'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/back/tmp/portage/dev-lang/gdl-0.9.1/work/gdl-0.9.1/src'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/back/tmp/portage/dev-lang/gdl-0.9.1/work/gdl-0.9.1'
make: *** [all] Error 2
emake failed
 * ERROR: dev-lang/gdl-0.9.1 failed (compile phase):
 *   emake failed
 *


gdl fails...


Code:
gnash.cpp:(.text._ZN5boost15program_options10validators17get_single_stringIcEERKSbIT_St11char_traitsIS3_ESaIS3_EERKSt6vectorIS7_SaIS7_EEb[std::basic_string<char, std::char_traits<char>, std::allocator<char> > const& boost::program_options::validators::get_single_string<char>(std::vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > const&, bool)]+0x158): undefined reference to `boost::program_options::validation_error::validation_error(boost::program_options::validation_error::kind_t, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
collect2: ld returned 1 exit status
make[4]: *** [sdl-gnash] Error 1
make[4]: Leaving directory `/back/tmp/portage/www-plugins/gnash-0.8.9-r1/work/gnash-0.8.9/gui'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/back/tmp/portage/www-plugins/gnash-0.8.9-r1/work/gnash-0.8.9/gui'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/back/tmp/portage/www-plugins/gnash-0.8.9-r1/work/gnash-0.8.9/gui'
make[1]: *** [all-recursive] Error 1


and Gnash ...


and cupsddk as also detailed above.


This cannot be pure coincidence.Neither does any amount of revdepping etc clear the problem. This is a total mess which has borked the system completely.

I have run the script at the head of this thread several times. It has dealt with a few packages that just needed rebuilding but the rest of the mess remains unresolved.

If it seem simple and obvious to you how to sort out this mess please post specifics.

TIA, Gentree.
_________________
Linux, because I'd rather own a free OS than steal one that's not worth paying for.

AthlonXP-M on A7N8X @ 2.6/2.4GHz (winter/summer)
2.6.32-hh1 : portage ~x86
Back to top
View user's profile Send private message
Trog Dog
Apprentice
Apprentice


Joined: 04 Aug 2007
Posts: 282

PostPosted: Sat Nov 26, 2011 6:14 am    Post subject: Reply with quote

gentree doesn't look like libpng errors to me.

your cups error doesn't look promising
http://www.google.com.au/search?q=error%3A+expected+'%3D'%2C+'%2C'%2C+'%3B'%2C+'asm'+or+'__attribute__'+gentoo&rls=com.microsoft:en-au&ie=UTF-8&oe=UTF-8&startIndex=&startPage=1&redir_esc=&ei=noHQTsnBN4mTiQeXnZjjDg

and the other two errors look like something in gcc is borked.
_________________
CIC1=CC=C(C2=N[C@@H](CC(OC(C)(C)C)=O)C3=NN=C(C)N3C4=C2C(C)=C(C)S4)C=C1
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 4 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum