On AMD64 platform be it building from ebuild or by hand there seems to be a problem with tcplient (god knows where else!), that it causes to report: temporarily unable to figure out IP address for X.X.X.X: file not found I have traced the problem to a gethostname() call in dns_rcrw.c line 94 if (gethostname(host,sizeof host) == -1) return -1; Somehow gethostname is not working or working as expected. BUT. and big BUT.. i've downloaded a compiled tcpclient program from another distro ( i believe it's mandrake) and it works without problems. I have only one amd64 system so my tests can't be called conclusive I've read on the forums http://forums.gentoo.org/viewtopic-t-323008-highlight-gethostname+amd64.html that some users are having problems related to FQDN resolution of the hostname so this may be related. Reproducible: Always Steps to Reproduce: 1. emerge ucspi-tcp 2. tcpclient 127.0.0.1 22 /bin/grep 3. Actual Results: You get the error tcpclient: fatal: temporarily unable to figure out IP address for 127.0.0.1: file does not exist Expected Results: should have run /bin/grep and exit This system has sys-libs/glibc-2.3.5-r1 sys-devel/gcc-3.4.4-r1 make.conf looks like: CFLAGS="-O3 -march=athlon64 -pipe" CHOST="x86_64-pc-linux-gnu" USE="-X -gnome -gtk -qt -kde -alsa mysql innodb gd ntpl curl imap clearpasswd -ipv6" MAKEOPTS="-j3" Doing a emerge -u world right now.So i'll report later if i have luck.
Ooops, big showstopper, tcpserver also throws out the same error, guess i will not be able to run qmail anymore!
base-system: something is screwed up with the domainname/hostname services. gerardo: please post your FULL 'emerge info' output. Also run the following and include output: hostname -v domainname -v dnsdomainname -v nisdomainname -v egrep -v '^$|^#' /etc/conf.d/hostname egrep -v '^$|^#' /etc/conf.d/domainname
highly doubtful the problem lays with the services
emerge info Portage 2.0.51.22-r2 (default-linux/amd64/2005.1, gcc-3.4.4, glibc-2.3.5-r1, 2.6.12-gentoo-r6 x86_64) ================================================================= System uname: 2.6.12-gentoo-r6 x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.13 dev-lang/python: 2.3.5 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.15.92.0.2-r10 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O3 -march=athlon64 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/share/config /var/qmail/alias /var/qmail/control /var/vpopmail/domains /var/vpopmail/etc" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon64 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://mirrors.tds.net/gentoo" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 avi berkdb bitmap-fonts clearpasswd crypt cups curl eds encode foomaticdb fortran gd gif gpm gstreamer gtk2 imap imlib innodb jpeg libwww lzw lzw-tiff mp3 mpeg mysql ncurses nls ntpl opengl pam pdflib perl png python quicktime readline sdl spell ssl tcpd tiff truetype-fonts type1-fonts usb userlocales xpm xv zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY #hostname -v gethostname()=`kuchelinux' kuchelinux #domainname -v getdomainname()=`(none)' (none) #dnsdomainname -v gethostname()=`kuchelinux' Resolving `kuchelinux' ... Result: h_name=`localhost' Result: h_aliases=`localhost.localdomain' Result: h_aliases=`kuchelinux' Result: h_aliases=`kuchelinux.localdomain' Result: h_addr_list=`127.0.0.1' #nisdomainname -v getdomainname()=`(none)' (none) # egrep -v '^$|^#' /etc/conf.d/hostname HOSTNAME="localhost" # egrep -v '^$|^#' /etc/conf.d/domainname OVERRIDE=1 I don't really understand how a mandrake compiled binary works and anything compiled in this box doesn't
Ah, and by the way, same stuff compiled for pentium4 or anything that's not amd64 works without problems!
I did a emerge -u world and still doesn't work, any clue ?
Read On: http://groups.yahoo.com/group/djb-qmail/message/122948 excerpt: "gcc -O2" is the default setting for conf-cc. The compiler generates code which causes the test at dns_rcrw.c:92 to always fail. dns_rcrw.c:92 compiled with -O2: call gethostname movl $-1, %eax cmpl %eax, %eax je .L86 dns_rcrw.c:92 compiled with no optimization: call gethostname cmpl $-1, %eax jne .L49 You have to change the ebuild line that reads echo "${CC} ${CFLAGS}" > conf-cc to echo "${CC}" > conf-cc Or if you are afraid of modyfing ebuild use CFLAGS="" emerge ucpsi-tcp Please someone patch the ebuild to detect AMD64 platforms and don't use optimizations
Hmm, I'd definetly call that a GCC bug that it's generating the incorrect assembly. Could you please test against other CFLAGS and see what the source of the problem is more exactly, so I know which flags to strip out? -- movl $-1, %eax cmpl %eax, %eax je .L86 -- This jump always occurs. -- cmpl $-1, %eax jne .L49 -- This one actually does a proper comparision, and only jumps if EAX does not contain -1.
-O3 -pipe causes the error too. Tell me what CFLAGS you want me to test and i'll test them. i bet that the problem is the -O flag
First of all, please test -O1. If it causes the problem, please test each of the following flags to find which one causes it: -fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fif-conversion -fif-conversion2 -fdelayed-branch -fguess-branch-probability -fcprop-registers If it does not occur with -O1, then you need to test these flags instead: -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps - fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm - fgcse-sm -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations - fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict- aliasing -funit-at-a-time -falign-functions -falign-jumps -falign-loops - falign-labels -fcrossjumping I'd strongly suggest you figure out a quick automated way to test the above, due to the number of flags (and use a binary search pattern as well).
None of the options caused the problem, thou -O2 still does, i even tried the sum of the two option lists and there was no error , although i had to remove -fdelayed-branch due to compiler warning about that option not being supported by amd64 (In reply to comment #10) > First of all, please test -O1. If it causes the problem, please test each of > the following flags to find which one causes it: > -fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fif-conversion > -fif-conversion2 -fdelayed-branch -fguess-branch-probability -fcprop-registers > > If it does not occur with -O1, then you need to test these flags instead: > -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps - > fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm - > fgcse-sm -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations - > fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec > -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict- > aliasing -funit-at-a-time -falign-functions -falign-jumps -falign-loops - > falign-labels -fcrossjumping > > I'd strongly suggest you figure out a quick automated way to test the above, > due to the number of flags (and use a binary search pattern as well).
-Os (optimize for code size) causes the error too. It's very strange, i've tried all the optimizations listed on gcc man page and i don't get the error, as soon as i use -O2 it comes back.! (In reply to comment #11) > None of the options caused the problem, thou -O2 still does, i even tried the > sum of the two option lists and there was no error , although i had to remove > -fdelayed-branch due to compiler warning about that option not being supported > by amd64 > (In reply to comment #10) > > First of all, please test -O1. If it causes the problem, please test each of > > the following flags to find which one causes it: > > -fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fif-conversion > > -fif-conversion2 -fdelayed-branch -fguess-branch-probability -fcprop-registers > > > > If it does not occur with -O1, then you need to test these flags instead: > > -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps - > > fcse-skip-blocks -frerun-cse-after-loop -frerun-loop-opt -fgcse -fgcse-lm - > > fgcse-sm -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations - > > fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec > > -fcaller-saves -fpeephole2 -freorder-blocks -freorder-functions -fstrict- > > aliasing -funit-at-a-time -falign-functions -falign-jumps -falign-loops - > > falign-labels -fcrossjumping > > > > I'd strongly suggest you figure out a quick automated way to test the above, > > due to the number of flags (and use a binary search pattern as well). > >
hmm, this is really weird. So just to recap: -O1 does not exhibit problem. -O2 does does exhibit problem. the sum of options implied by -O2 does not exhibit the problem. Could you try various combinations of the -O2 options if this is the case? I'm trying to narrow it down to some set of options.
I've divided the options as this gcc -fif-conversion2 -fguess-branch-probability -fcprop-registers -fomit-frame-pointer #gcc -falign-loops -falign-labels -fcrossjumping -fdefer-pop -fmerge-constants -fthread-jumps -floop-optimize -fif-conversion #gcc -freorder-blocks -freorder-functions -fstrict-aliasing -funit-at-a-time -falign-functions -falign-jumps #gcc -fregmove -fschedule-insns -fschedule-insns2 -fsched-interblock -fsched-spec -fcaller-saves -fpeephole2 #gcc -frerun-loop-opt -fgcse -fgcse-lm -fgcse-sm -fgcse-las -fdelete-null-pointer-checks -fexpensive-optimizations #gcc -fforce-mem -foptimize-sibling-calls -fstrength-reduce -fcse-follow-jumps -fcse-skip-blocks -frerun-cse-after-loop Tried each line separately modyfing conf-cc and recompiling from source, no line produced the error. (In reply to comment #13) > hmm, this is really weird. > So just to recap: > -O1 does not exhibit problem. > -O2 does does exhibit problem. > the sum of options implied by -O2 does not exhibit the problem. > > Could you try various combinations of the -O2 options if this is the case? > I'm trying to narrow it down to some set of options.
Might this be related to bug 90581?
No response in half a year.
