| Summary: | dev-python/imaging-1.1.7-r2 - In file included from _imaging.c:77: libImaging/ImPlatform.h:17:2: error: #error Sorry, this library requires ANSI header files. | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Bartosz Krzeszewski <bartek> |
| Component: | [OLD] Development | Assignee: | Python Gentoo Team <python> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | toralf |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Bartosz Krzeszewski
2013-07-15 20:33:27 UTC
(In reply to Bartosz Krzeszewski from comment #0) > * If you need support, post the output of `emerge --info > '=dev-python/imaging-1.1.7-r2'`, Please do. (Regardles of the below, I'd call this an upstream failure.) libImaging/Imaging.h relies on HAVE_PROTOTYPES and STDC_HEADERS being set in pyconfig.h. The later is kind of redundant (probably for about a decade by now). The former is just plain silly, however the check must have failed for some reason during building python. Obviously, there's no data here to guess why. emerge --info '=dev-python/imaging-1.1.7-r2'
Portage 2.2.0_alpha177 (default/linux/amd64/13.0, gcc-4.6.3, glibc-2.15-r3, 3.10.1-gentoo x86_64)
=================================================================
System Settings
=================================================================
System uname: Linux-3.10.1-gentoo-x86_64-AMD_A8-5600K_APU_with_Radeon-tm-_HD_Graphics-with-gentoo-2.2
KiB Mem: 7279088 total, 4847268 free
KiB Swap: 9873432 total, 9873432 free
Timestamp of tree: Mon, 15 Jul 2013 11:30:01 +0000
ld GNU ld (GNU Binutils) 2.23.1
ccache version 3.1.9 [enabled]
app-shells/bash: 4.2_p45
dev-java/java-config: 2.1.12-r1
dev-lang/python: 2.7.5, 3.2.5-r1
dev-util/ccache: 3.1.9
dev-util/cmake: 2.8.10.2-r2
dev-util/pkgconfig: 0.28
sys-apps/baselayout: 2.2
sys-apps/openrc: 0.11.8
sys-apps/sandbox: 2.6-r1
sys-devel/autoconf: 2.13, 2.69
sys-devel/automake: 1.11.6, 1.12.6
sys-devel/binutils: 2.23.1
sys-devel/gcc: 4.6.3
sys-devel/gcc-config: 1.7.3
sys-devel/libtool: 2.4-r1
sys-devel/make: 3.82-r4
sys-kernel/linux-headers: 3.7 (virtual/os-headers)
sys-libs/glibc: 2.15-r3
Repositories: gentoo science wine-diablo3 bitcoin local
Installed sets: @system
ACCEPT_KEYWORDS="amd64"
ACCEPT_LICENSE="*"
CBUILD="x86_64-pc-linux-gnu"
CFLAGS="-march=athlon64 -O2 -pipe -msse -msse2 -msse3 -mmmx -m3dnow"
CHOST="x86_64-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/share/config /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5.4/ext-active/ /etc/php/cgi-php5.4/ext-active/ /etc/php/cli-php5.4/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-march=athlon64 -O2 -pipe -msse -msse2 -msse3 -mmmx -m3dnow"
DISTDIR="/home/gentoo/distfiles"
EMERGE_DEFAULT_OPTS="--keep-going --jobs=2"
FCFLAGS="-O2 -pipe"
FEATURES="assume-digests binpkg-logs ccache config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch"
FFLAGS="-O2 -pipe"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
LANG="pl_PL.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j5"
PKGDIR="/home/gentoo/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages"
PORTAGE_TMPDIR="/home/gentoo/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/var/lib/layman/science /var/lib/layman/wine-diablo3 /var/lib/layman/bitcoin /home/gentoo/local"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="3dnow 3dnowex 3dnowext X acl alsa amd64 amr berkdb bzip2 cli cracklib crypt cxx dri ffmpeg fortran gdbm gpm iconv icu ipv6 kde mmx mmxext modules mp3 mudflap multilib ncurses nls nptl opencl opengl openmp pam pcre readline scanner session smp spell sse sse2 ssl ssse3 tcpd unicode v4l vhosts x264 xinerama xscreensaver xv xvmc zlib" ABI_X86="32 64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" APACHE2_MPMS="peruser" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump author" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="pl" NETBEANS_MODULES="php" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-4" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby19 ruby18" SANE_BACKENDS="hp" USERLAND="GNU" VIDEO_CARDS="fglrx vesa" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset: CPPFLAGS, CTARGET, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON
emerge -pqv '=dev-python/imaging-1.1.7-r2' [ebuild N ] dev-python/imaging-1.1.7-r2 USE="X scanner -doc -examples -lcms -tk" PYTHON_TARGETS="python2_7 -python2_5 -python2_6" How long can it take to fix this bug? I can't install net-print/hplip because of this and can't use my new printer + scanner. (In reply to Bartosz Krzeszewski from comment #5) The refund for your support contract is in the mail. Feel free to fix it yourself and send us a patch. Short of that, someone will address it when they have time. (In reply to Bartosz Krzeszewski from comment #5) > How long can it take to fix this bug? I can't install net-print/hplip > because of this and can't use my new printer + scanner. Well you can but ask... Let's see. The above is the polite version. Another 'polite' version goes like so; "about the same as the answer to how long is a piece of string?" To put it another way, the question is fundamentally a non question and reaks of, well let's just not say what it reaks of. I really get the impression there's a plain innocence behind this non question, so a sharp rebuke I sense is a horribly wrong way to go here. While I'm doing a pypy build which will take a long time I'll see what I get. ...and - as I already noted - it seems that the immediate problem is that something went wrong during python 2.7.5 build. My english is poor so please try be more forgiving. I know how opensource works you don't have to tell me this. I just wanted to know if someone is working on this and if it is possible that it will be fixed in near future. (In reply to Bartosz Krzeszewski from comment #9) > My english is poor so please try be more forgiving. I know how opensource > works you don't have to tell me this. I just wanted to know if someone is > working on this and if it is possible that it will be fixed in near future. Bartosz, yep no problem, I can tell re your english by 1) your very continental Europe name, and 2) by your sentence presentation, I can also tell you I'm working on it and here's a result; Here's your line of failure. x86_64-pc-linux-gnu-gcc -pthread -march=athlon64 -O2 -pipe -msse -msse2 -msse3 -mmmx -m3dnow -fPIC -DHAVE_LIBJPEG -DHAVE_LIBZ -I/usr/include/freetype2 -IlibImaging -I/usr/include -I/usr/include/python2.7 -c _imaging.c -o /home/gentoo/tmp/portage/dev-python/imaging-1.1.7-r2/work/Imaging-1.1.7-python2_7/temp.linux-x86_64-2.7/_imaging.o Mine builds fine. Here's the equiv. line x86_64-pc-linux-gnu-gcc -pthread -march=athlon64 -pipe -fomit-frame-pointer -O2 -fPIC -DHAVE_LIBJPEG -DHAVE_LIBZ -I/usr/include/freetype2 -IlibImaging -I/usr/include -I/usr/local/include -I/usr/include/python2.7 -c _imaging.c -o /mnt/gen2/TmpDir/portage/dev-python/imaging-1.1.7-r2/work/Imaging-1.1.7-python2_7/temp.linux-x86_64-2.7/_imaging.o and it appears to be the very final line of the py2.7 build. So what do we have here? I'd say the notable diffs are your -msse -msse2 -msse3 -mmmx -m3dnow gcc options. These maybe come from your make.conf global USE settings. So try to tease out those options from your system setup and it looks like it's not a bug but your system setup is contaminating the py2.7 build (In reply to Rafał Mużyło from comment #2) > (Regardles of the below, I'd call this an upstream failure.) > > libImaging/Imaging.h relies on HAVE_PROTOTYPES and STDC_HEADERS being set in > pyconfig.h. > The later should be latter > is kind of redundant (probably for about a decade by now). > > The former is just plain silly, however the check must have failed for some > reason during building python. Obviously, there's no data here to guess why. Not sure what to make of this really, because mine BUILT. That means the ebuild is viable along with the source code of the package. I'm most reticent to endorse an upstream failure when it actually builds. The data would be his build log. Does yours build? (In reply to Ian Delaney from comment #10) > (In reply to Bartosz Krzeszewski from comment #9) > > My english is poor so please try be more forgiving. I know how opensource > > works you don't have to tell me this. I just wanted to know if someone is > > working on this and if it is possible that it will be fixed in near future. > > Bartosz, yep no problem, I can tell re your english by 1) your very > continental Europe name, and 2) by your sentence presentation, I can also > tell you I'm working on it and here's a result; > Here's your line of failure. > > x86_64-pc-linux-gnu-gcc -pthread -march=athlon64 -O2 -pipe -msse -msse2 > -msse3 -mmmx -m3dnow -fPIC -DHAVE_LIBJPEG -DHAVE_LIBZ > -I/usr/include/freetype2 -IlibImaging -I/usr/include > -I/usr/include/python2.7 -c _imaging.c -o > /home/gentoo/tmp/portage/dev-python/imaging-1.1.7-r2/work/Imaging-1.1.7- > python2_7/temp.linux-x86_64-2.7/_imaging.o > > Mine builds fine. Here's the equiv. line > > x86_64-pc-linux-gnu-gcc -pthread -march=athlon64 -pipe -fomit-frame-pointer > -O2 -fPIC -DHAVE_LIBJPEG -DHAVE_LIBZ > -I/usr/include/freetype2 -IlibImaging -I/usr/include -I/usr/local/include > -I/usr/include/python2.7 -c _imaging.c -o > /mnt/gen2/TmpDir/portage/dev-python/imaging-1.1.7-r2/work/Imaging-1.1.7- > python2_7/temp.linux-x86_64-2.7/_imaging.o > > and it appears to be the very final line of the py2.7 build. So what do we > have here? I'd say the notable diffs are your -msse -msse2 -msse3 -mmmx > -m3dnow gcc options. These maybe come from your make.conf global USE > settings. So try to tease out those options from your system setup and it > looks like it's not a bug but your system setup is contaminating the py2.7 > build I reemerged python and after this imaging emerged without problem. Thank you. (In reply to Bartosz Krzeszewski from comment #12) > I reemerged python and after this imaging emerged without problem. Thank you. Ah tops. Perfect result (In reply to Rafał Mużyło from comment #2) > (Regardles of the below, I'd call this an upstream failure.) > In light of all the above, I wouldn't. Oh yes, and you can forge ahead with the shiny new printer + scanner. Enjoy (In reply to Ian Delaney from comment #13) > (In reply to Rafał Mużyło from comment #2) > > (Regardles of the below, I'd call this an upstream failure.) > > > > In light of all the above, I wouldn't. To elaborate: both of those two check these days are basically "see if the water is wet", so yes, regardless of the other circumstances. That is seems to have been a user failure, is a completely different matter. (In reply to Rafał Mużyło from comment #15) > > To elaborate: both of those two check these days are basically "see if the > water is wet", so yes, regardless of the other circumstances. > > That is seems to have been a user failure, is a completely different matter. I don't quite follow, but this is merely a side track anyway seeing Bartosz is up and running. 'See if the water is wet', my this is a new one. The water can arguably come up as dry, dehydrated or semi wet maybe? I use metaphors all the time but on this one I just come up dry. That is seems; is this 'that is, it seems'? A user failure is what happened here it seems to me, yes? A completely different matter by its nature I'm going for 'makes for those 2 checks to be utterly irrelevant'. Guys, can we drop this sidebar discussion of hydration please? No more replies unless it is relevant to fixing something. (In reply to Ian Delaney from comment #14) > Oh yes, and you can forge ahead with the shiny new printer + scanner. Enjoy Thank you. It works perfect. (In reply to Rafał Mużyło from comment #15) > That is seems to have been a user failure, is a completely different matter. But why use failure? I didn't do nothing wrong. I was just emerging. (In reply to Bartosz Krzeszewski from comment #19) > But why use failure? I didn't do nothing wrong. I was just emerging. Right, I don't think this was your fault. However, I also don't think it is worth spending time figuring out how your python installation got messed up unless someone else reports the same problem. (In reply to Mike Gilbert from comment #20) > (In reply to Bartosz Krzeszewski from comment #19) > > But why use failure? I didn't do nothing wrong. I was just emerging. > > Right, I don't think this was your fault. However, I also don't think it is > worth spending time figuring out how your python installation got messed up > unless someone else reports the same problem. I think it is because of lack of USE flags (as Ian Delaney nothiced my python was compiled without -msse -msse2 -msse3 -mmmx -m3dnow USE flags) in dev-lang/python-2.7.5:2.7. If those USE flags were there my world updates (after I added them) would reemerge python and there would not be that bug. (In reply to Bartosz Krzeszewski from comment #21) Frankly, Ian's guess makes no sense, and he is confusing CFLAGS with USE flags. "That it seems to have been a user failure" meant that in my experience a messed up pyconfig.h was most likely a result of some atypical setting of this particular user. Obviously, without the logs of such incorrect build and given the user can't reproduce that kind of build anymore, we're unlikely to learn what was the actual cause of this situation. I doubt it were CFLAGS, unless at some point they were a completely bogus value, but in such case the build would most likely simply failed. As for my upstream rant, the way I see it, there are things, that you should check for and things, you should be able to safely assume past a certain point - these two IMHO fall strongly into the second case. (In reply to Mike Gilbert from comment #22) > (In reply to Bartosz Krzeszewski from comment #21) > > Frankly, Ian's guess makes no sense, and he is confusing CFLAGS with USE > flags. Recently I have added those USE flags "mmxext ssse3 3dnow 3dnowex 3dnowext" to my /etc/make.conf. (In reply to Rafał Mużyło from comment #23) > "That it seems to have been a user failure" meant that in my experience a > messed up pyconfig.h was most likely a result of some atypical setting of > this particular user. Obviously, without the logs of such incorrect build > and given the user can't reproduce that kind of build anymore, we're > unlikely to learn what was the actual cause of this situation. I think that if I remove recently added USE flags (mmxext ssse3 3dnow 3dnowex 3dnowext) from my /etc/make.conf and emerge --emptytree world, than add those flags back and emerge all exept python-2.7 then the bug would come back. But it is a lot of work and processor power. |
