if I build imlib2 with "-march=pentium3 -O3 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse,387" Eterm will be unable to open images, failing with an "unknown error". if I go down to "-march=i686 -O1 -pipe" imlib2 and hence Eterm work as intended. finding the proper limits and filtering out the appropriate flags is probably a good idea. for what its worth: orion-seven Eterm # emerge info Portage 2.0.48-r7 (default-x86-1.4, gcc-3.2.3, glibc-2.3.2-r1) ================================================================= System uname: 2.4.21 i686 Pentium III (Coppermine) GENTOO_MIRRORS="ftp://ftp.uio.no/linux/Gentoo/ http://gentoo.oregonstate.edu/ http://www.ibiblio.org/pub/Linux/distributions/gentoo" CONFIG_PROTECT="/etc /var/qmail/control /usr/kde/2/share/config /usr/kde/3/share/config /usr/X11R6/lib/X11/xkb /usr/kde/3.1/share/config /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/config" CONFIG_PROTECT_MASK="/etc/gconf /etc/env.d" PORTDIR="/usr/portage" DISTDIR="/usr/portage/distfiles" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR_OVERLAY="" USE="x86 oss 3dnow apm avi crypt cups foomaticdb gif jpeg libg++ mad mikmod mmx mpeg ncurses nls pdflib png spell truetype xml2 xmms zlib gdbm berkdb slang readline svga java sdl gpm tcpd pam perl python imlib oggvorbis motif opengl X gtk gtk2 kde imap gnome alsa arts xv qt ruby quicktime encode tcltk doc sse mozilla leim tetex threads tiff esd dvd cdr scanner gphoto2 bonobo mysql libwww maildir sasl ssl" COMPILER="gcc3" CHOST="i686-pc-linux-gnu" CFLAGS="-march=pentium3 -O3 -pipe -fomit-frame-pointer -ffast-math -mfpmath=sse,387" CXXFLAGS="-O2 -mcpu=i686 -pipe" ACCEPT_KEYWORDS="x86 ~x86" MAKEOPTS="-j3" AUTOCLEAN="yes" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" FEATURES="sandbox buildpkg ccache userpriv usersandbox"
yeah, i had the same problem, just never bothered to track it down ;)
the real question is if it's the fast-math or the fpmath or the -O3 that does it. the box is more or less in production with an Eterm-user so I really can't test that easily. :-/
nah dont worry about it, i can reproduce it on my box
Imlib crashed during compilation at testimg.c when i used: CHOST="i686-pc-linux-gnu" CFLAGS="-mcpu=pentium2 -O2 -Os -pipe" i did a little testing and ended up with: CFLAGS="-mcpu=pentium2 -pipe" and it compiled fine several times. It seems like imlib or whatever it is causing this is very sensitive to optimization flags. Perhaps the imlib emerge script can be made so that it filters out optimizations? Just my two cents. Keep up the good work! :)
And another note. I changed my CFLAGS back to what they used to be after the compilation of imlib. And everything have compiled fine after that :)
I was having the same problem with Eterm not being able to load images. For sure "-march=pentium3 -O2 -pipe" works. I tried adding in more optimizations and ended up where I started with "-march=pentium3 -03 -pipe -fomit-frame-pointer -fPIC" and it is still working so I think there is a problem with the library being cached right now. If you know a way to force Eterm to use the newly compiled version of the library on disk I can pretty quickly run through more options.
ok i *was* able to reproduce this at one point but am not able to do so any longer ... could the people who experience this post the following information: `emerge info` `qpkg -I -v gcc` `qpkg -I -v eterm` `qpkg -I -v imlib2`
chris: please read my last comment (#7)
Created attachment 17222 [details] output requested in comment #7 As requested the output from the commands listed in comment #7. I did this as an attachment because it is rather long.
Created attachment 17223 [details] output requested in comment #7 As requested the output from the commands listed in comment #7. I did this as an attachment because it is rather long.
well it's long because i asked for -I (that is an i [sounds like eye] not an l [sounds like el]) ... but the -l also shows the version ;)
------- Additional Comments From lambacck@ieee.org 2003-18-09 11:01 EST ------- Seems to work, though I am now using gcc 3.3.1-r1
*** Bug 29237 has been marked as a duplicate of this bug. ***
ok, ive updated the snapshots to 1.1.0 since this original bug ... you guys still have issues using 1.1.0 and your normal optimizations ? if so, does gcc-3.3.1 seem to resolve it ?
I am using gcc 3.3.1-r4 and imlib2 1.1.0 with no problems with my normal optimizations.
alright, i added strip-flags for users of gcc-3.2.x to imlib2-1.0.6 as this doesnt seem to affect 3.3.x users or imlib2-1.1.0
