From: PASCHAL,DAVID (HP-Roseville,ex1) <dav...@hp...> - 2001-03-12 19:51:12
|
Joe Piolunek wrote: > I'm using a RedHat 6.1 system, but I built the compiler (gcc > 2.95.2) from > source. The glibc version (2.1.3-22) is the redhat-supplied > rpm update that I > installed because of the reported security vulnerability in > earlier packages. > I wouldn't go back to an earlier version. Good to know. I suppose that reduces the exposure of this problem compared to if this combination were provided out-of-the-box. But don't worry; I'll fix this one way or another. I wouldn't want you to have to upgrade or downgrade anything for this. I don't think changing glibc would fix it anyway, since probably all versions have the double colons that confuse the C++ compiler you currently have installed. Could you send your version of sys/io.h to my non-HP address? I'd like to diff it against what I have on my system at home. > My system doesn't seem to be broken. I've been building Qt > and KDE2 from > source, as well as many C-only apps. I would expect that QT and KDE don't do any low-level I/O port access from user space. :-) (regarding whether putting a space between the double colons fixes the problem): > I don't know. I didn't try it, though I will if I need to. > The comments I > found were from gcc, glibc or redhat development mailing > lists, so they may > not be useful advice for many other people. It would be helpful if you tried it in at least one place, just to see if it makes the error in that place go away. If so, then perhaps I could include a "fixed" version as a workaround, although it might not be optimal to ship __asm__ statements with a package I want to be as platform independent as possible. :-) > I tried to compile a file containing the code below calling > both gcc and g++ > as the compiler. The filename ending was '.c' in both cases. > gcc had no > trouble compiling it, but when I attempted to compile it with > g++, it barfed > (possibly on the '::') causing the same errors I reported earlier. > > If the file is resaved with a .cpp suffix and gcc is called > to compile it, > it barfs. > > > /* > filename: test_including_io_h.c > */ > #include </usr/include/sys/io.h> > #include <stdio.h> > > int main(){ > printf("Hello World\n"); > exit(0); > } Thanks for trying that. Since it works in C, the cleanest workaround may be to detect the problem in the configure script, and in that case compile in a C wrapper that includes sys/io.h and re-exports the inb/outb functions. David |