Man tcsetattr implicitly says that after including <termios.h> and <unistd.h>, the constant CRTSCTS will be defined. But it is false: tty.c:38: error: `CRTSCTS' undeclared (first use in this function) I have both headers included: #include <termios.h> #include <unistd.h> clock@kestrel:~$ emerge info Portage 2.0.54 (default-linux/x86/2005.0, gcc-3.3.6, glibc-2.3.5-r2, 2.6.12-gentoo-r10 i686) ================================================================= System uname: 2.6.12-gentoo-r10 i686 Intel(R) Pentium(R) M processor 1.50GHz Gentoo Base System version 1.6.14 dev-lang/python: 2.3.5-r2, 2.4.2 sys-apps/sandbox: 1.2.12 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-r1 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.22 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CBUILD="i686-pc-linux-gnu" CFLAGS="-O3 -march=pentium3 -fomit-frame-pointer -pipe" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=pentium3 -fomit-frame-pointer -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/linux/distributions/gentoo" LC_ALL="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="x86 X aac aalib alsa apm arts audiofile avi berkdb bitmap-fonts bzip2 cdr crypt cups curl dga divx4linux dri dv dvd dvdread eds emboss encode esd ethereal exif expat fam ffmpeg fftw flac flash foomatic foomaticdb fortran ftp gd gdbm gif glut gmp gnome gpm gstreamer gtk gtk2 gtkhtml guile icq idn imagemagick imap imlib ipv6 jabber jack java javascript jpeg kde lcms ldap libcaca libg++ libwww live matroska mhash mikmod ming mmap mmx mng motif mozilla mp3 mpeg mysql nas ncurses nls ogg oggvorbis opengl oss pam pcre pdflib perl php png python qt quicktime readline real recode ruby samba sdl sharedmem shorten slang socks5 speex spell sse ssl svg svga tcltk tcpd tetex theora threads tiff tls truetype truetype-fonts type1-fonts udev unicode usb vorbis wifi win32codecs wmf xine xinerama xml xml2 xmms xpm xv xvid zlib userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LANG, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Please, report this upstream, we didn't write the man page. http://www.win.tue.nl/~aeb/linux/man/
Are you sure that the problem is not caused by gentoo having the headers installed wrong while the manpage being right?
In Debian it reportedly works: Date: Wed, 12 Apr 2006 10:42:15 -0400 From: "linux-os (Dick Johnson)" <linux-os@analogic.com> To: Nick Craig-Wood <nick@craig-wood.com> Subject: Re: CRTSCTS wrong in man tcsetattr On Wed, 12 Apr 2006, Nick Craig-Wood wrote: > In linux.kernel, you wrote: >> Man tcsetattr in gentoo implicitly states that after >> #include <termios.h> >> #include <unistd.h> >> >> CRTSCTS constant will be defined. This is however false: >> tty.c:38: error: `CRTSCTS' undeclared (first use in this function) >> >> CRTSCTS is defined in bits/termios.h and in asm/termbits.h The question >> is what is the correct state of affairs? >> 1) the manpage should say bits/termios.h instead of termios.h >> 2) the manpage should say asm/termbits.h instead of termios.h >> 3) the termios.h should include bits/termios.h or asm/termbits.h >> 4) the manpage should not mention CRTSCTS at all > 5) there is a bug in your installation > > Works for me in Debian testing > > cat <<'EOF' > z.c > #include <termios.h> > #include <unistd.h> > #include <stdio.h> > > int main(void) > { > printf("0x%08X", CRTSCTS); > return 0; > } > EOF > gcc -Wall z.c -o z > ./z > > Gives > > 0x80000000 > > -- > Nick Craig-Wood <nick@craig-wood.com> -- http://www.craig-wood.com/nick > -
glibc header, not a kernel header...
i dont know what manpage you read but `man tcsetattr` in Gentoo makes no such claim and the test code works just fine for me with glibc-2.3.5-r3/x86 and glibc-2.4/amd64
The manpage implicitly says that if you include those 2 includes, you can use the CRTSCTS constant (otherwise you would have no way how to actually turn on and off hardware flow control, and it would be pointless to describe meaning of CRTSCTS if it cannot be used). Now I tried the test code and found it works too. I analyzed what is causing it to not work and it's definition of #define _XOPEN_SOURCE 500 which is written in man usleep. I want the program to be written according to SuSV specification and not some unstandardized BSD way, therefore I define _XOPEN_SOURCE 500 before usleep. I don't know if it's a problem of Gentoo header installation that CRTSCTS doesn't work with _XOPEN_SOURCE 500 or if man tcsetattr is omitting some information regarding _XOPEN_SOURCE. The only thing I know is that if I install a gentoo system and write a program according to the manual pages, it doesn't compile. You assembled the Gentoo system from modules and you know how. I don't know how you did it. Because you know how you did it, you know boundaries of the individual modules (examples of possible modules: manual pages, headers, etc.) and you know where the interface lies. Then you can once again take specifications of the modules and see, whether one of the modules doesn't comply to it's own specification (bug in the module), or whether you put together two modules with unmatching specification (bug in gentoo). It's not possible to build a buggy system when two bugfree modules with matching interface specification are put together.
> The manpage implicitly says that if you include those 2 includes, you can use > the CRTSCTS constant fair enough > I analyzed what is causing it to not work and it's definition of > #define _XOPEN_SOURCE 500 > <snip> so the behavior you're seeing is not a bug
if the user makes no preference as to what standards he wants to build for, then BSD/SVID is enabled by default since you defined _XOPEN_SOURCE, that implies you know what features you want exactly, so it's up to you to list everything you want in this case, you need to add a define _BSD_SOURCE yourself
