Summary: | dev-lang/python-2.6.4-r1 does not compile (USE="tk") | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrzej Szary <aszary> |
Component: | New packages | Assignee: | TCL/TK Project <tcltk> |
Status: | RESOLVED WONTFIX | ||
Severity: | normal | CC: | python, vapier |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | complete build log file |
Description
Andrzej Szary
2010-03-19 14:10:08 UTC
I have noticed that the same bug applies also to dev-lang/python-3.1.1-r1 so it could be some kind of dependence error... ...and I've noticed you've failed to attach full build log, as the real error is missing in the pasted output. Created attachment 224297 [details]
complete build log file
*** WARNING: renaming "_tkinter" since importing it failed: build/lib.linux-x86_64-2.6/_tkinter.so: undefined symbol: jpeg_stdio_src Looks like an incorrect jpeg upgrade. As that symbol is present in jpeg8 (8a is already stable on amd64), you probably need to follow postinstall note. I am not sure if I understood correctly but I have reinstalled media-libs/jpeg-8a (no postinstall note) and I still get same error (warning) when reemerging python. Also I have reinstalled dev-lang/tcl-8.5.8 and dev-lang/tk-8.5.8 (both without any problem) but this did not help too. In the postinstall note: revdep-rebuild --library libjpeg.so.7 and chances are that revdep-rebuild --library libjpeg.so.62 has not been done yet too. Looks like everything there is fine: * There are no dynamic links to libjpeg.so.7... All done. * There are no dynamic links to libjpeg.so.62... All done. any other suggestions? OK, in that case, it may get tricky, either: - you have a stale copy of old lib/headers (i.e. in /usr/local) or - for some reason build process of python picks up wrong lib version to link to then again, it seems that jpeg_stdio_src was in 6b after all... Check in all of the instances of libjpeg the result of nm -C -D <libname> | grep jpeg_stdio_src and try rebuilding tk. Ok this is output of the command you suggested for every libjpg I could find on my ststem: /usr/lib32/libjpeg.so.7 >> 000114d0 T jpeg_stdio_src /usr/lib32/libjpeg.so.8.0.0 >> 00011a00 T jpeg_stdio_src /usr/lib32/libjpeg.so.62 >> 0000d830 T jpeg_stdio_src /usr/lib32/libjpeg.so.8 >> 00011a00 T jpeg_stdio_src /usr/lib32/libjpeg.so >> 00011a00 T jpeg_stdio_src /usr/lib64/libjpegtcl1.0.so >> broken link /usr/lib64/libjpegtcl1.0.so -> Img1.3/libjpegtcl1.0.so (see below for details) /usr/lib64/Img1.4/libjpegtcl1.0.so >> U jpeg_stdio_src /usr/lib64/libjpeg.so.8.0.1 >> 00000000000138bb T jpeg_stdio_src /usr/lib64/libjpeg.so.8 >> 00000000000138bb T jpeg_stdio_src /usr/lib64/libjpeg.so >> 00000000000138bb T jpeg_stdio_src /opt/sun-jdk-1.6.0.18/jre/lib/amd64/libjpeg.so >> (nothing) There was one broken link /usr/lib64/libjpegtcl1.0.so > Img1.3/libjpegtcl1.0.so but reemerging package it belongs to (dev-tcltk/tkimg-1.3.20081202) did not help - still broken link. I have repaired this link with: ln -s /usr/lib64/Img1.4/libjpegtcl1.0.so /usr/lib64/libjpegtcl1.0.so but it did not solve the problem... There is one lib file without jpeg_stdio_src symbol (/opt/sun-jdk-1.6.0.18/jre/lib/amd64/libjpeg.so). Do you think it is loaded instead of proper library? What does ldd print for that freshly built _tkinter.so ? Ok, I have python running with tk use flag... 1. I have repaired broken links from dev-tcltk/tkimg-1.3.20081202: libjpegtcl1.0.so -> /usr/lib64/Img1.4/libjpegtcl1.0.so libpngtcl1.2.24.so -> Img1.4/libpngtcl1.2.24.so libtifftcl3.8.2.so -> Img1.4/libtifftcl3.8.2.so libzlibtcl1.2.3.so -> Img1.4/libzlibtcl1.2.3.so 2. I have reemerged dev-lang/tk-8.5.8 and dev-lang/tcl-8.5.8 BTW. Right now my python version is dev-lang/python-2.6.5 (not 2.6.4-r1), but I think it helped because I also managed to install dev-lang/python-3.1.1-r1 with tk use flag (earlier the same error)... Thank you for your help I wouldn't exactly call manually creating those symlinks "fixing", cause either that ebuild is broken or there was a good reason they were missing in the first place. Reassigning to tcltk, as the problem seems to be on their side. I've found the cause in dev-tcltk/blt-2.4z-r8, my changes to its blt-2.4z-darwin.patch should solve it. See bug 373695 (In reply to comment #14) This bug is unrelated to bug #373695. It was filed over 1 year before the cause of bug #373695 was introduced. Python 2.6 is no longer supported and undergoing preparations for removal. |