Menu
▾
▴
hpoj-devel
|
From: <pa...@rc...> - 2001-03-11 03:57:27
|
Joe Piolunek wrote:
> The build fails with this output:
> ...
> gcc -I/home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd
> -I/home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd/transport -O -g -Wall
> -DEX_TRANSPORT_UNIX_PORT -DPAR_PLATFORM_LINUX -DUSB_PLATFORM_NONE -DJD_DEBUG
> -c -o ExMgr.o ExMgr.cpp
> In file included from
> /home/joe/hpoj_proj/CVS/hpoj_CVS_03-10-2001/mlcd/ParPort.h:396,
> from ExMgr.cpp:1981:
> /usr/include/sys/io.h: In function `void outb(unsigned char, short unsigned
> int)':
> /usr/include/sys/io.h:98: parse error before `::'
Hi, Joe. Thanks for the bug report. I just checked in a change to ParPort.h
to wrap "#include <sys/io.h>" with 'extern "C" { }'. Try it again after
doing a "cvs update" and see if that fixes the problem. Perhaps I should go
through and do this around most if not all #includes from C++ files, just to
be on the safe side.
> Can you hold off on checking in the patch I posted recently? I only sent it
> so you could look at the changes if you wanted to, and see if they work
> correctly.
>
> I'd like to modify some of the comments a little more to enable (but not
> necessarily include) document generation by Doxygen or a similar utility, so
> there will be at least one more patch, probably applied against the last
> official release (0.7).
I haven't had a chance to try it out since I pretty much pulled the rug out
from under it by removing ojlib, but I'll wait for your next drop and build
it with 0.7.
> Generated documentation can be a benefit. Would it be a good idea for the
> entire project?
It might be a good idea for PTAL at least, since other applications need to
be able to interface with it. I don't know if it's necessary to generate
separate documentation for individual components that don't export their own
interfaces, but of course, it doesn't hurt to have the information in there
one way or another.
David
|
|
From: <pa...@rc...> - 2001-03-12 08:09:54
|
Joe Piolunek wrote: > Unfortunately, the error still occurs. Bummer. :-) > A search for " /usr/include/sys/io.h:98: parse error before `::'" turned up a > few comments indicating that it may be related to a bug in gcc, which may be > fixed in ver. 2.96 . There was a report of the problem going away if using an > earlier version of glibc. Remind me again which version of RedHat you're using? Are these the stock versions of glibc and gcc that came with this version? > A suggested fix is to "change '::' to ' : : ' in > sys/io.h" . Does that work? Of course, that isn't a proper solution, since I don't want people to have to hack system include files in order to build hpoj. > I tried to use a #define ... #undef wrapper, but got errors about > using an improper macro name. I'm not surprised that that doesn't work. Generally #define only works with symbols, not operators. I'm wondering if this problem only affects C++ and not C code. Could you please try writing a simple "hello world" program compiled as C (not C++), and include this file? If it works OK for C code, then perhaps I could add a small C wrapper for the in/out functions to avoid including this file in a C++ file. Of course, it wouldn't be good for performance, since those functions would no longer be inlined. David |
|
From: Joe P. <joe...@sn...> - 2001-03-12 16:31:22
|
On Monday 12 March 2001 03:12 am, David Paschal wrote:
> Remind me again which version of RedHat you're using? Are these the stock
> versions of glibc and gcc that came with this version?
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.
My system doesn't seem to be broken. I've been building Qt and KDE2 from
source, as well as many C-only apps.
> > A suggested fix is to "change '::' to ' : : ' in
> > sys/io.h" .
>
> Does that work? Of course, that isn't a proper solution, since I don't
> want people to have to hack system include files in order to build hpoj.
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.
>
> I'm wondering if this problem only affects C++ and not C code. Could you
> please try writing a simple "hello world" program compiled as C (not C++),
> and include this file? If it works OK for C code, then perhaps I could add
> a small C wrapper for the in/out functions to avoid including this file in
> a C++ file. Of course, it wouldn't be good for performance, since those
> functions would no longer be inlined.
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);
}
Here is the output when attempting to compile the above code with g++.
]$ g++ -o test_including_io_h test_including_io_h.c
In file included from test_including_io_h.c:4:
/usr/include/sys/io.h: In function `void outb(unsigned char, short unsigned
int)':
/usr/include/sys/io.h:98: parse error before `::'
/usr/include/sys/io.h: In function `void outb_p(unsigned char, short unsigned
int)':
/usr/include/sys/io.h:104: parse error before `::'
/usr/include/sys/io.h: In function `void outw(short unsigned int, short
unsigned int)':
/usr/include/sys/io.h:111: parse error before `::'
/usr/include/sys/io.h: In function `void outw_p(short unsigned int, short
unsigned int)':
/usr/include/sys/io.h:118: parse error before `::'
/usr/include/sys/io.h: In function `void outl(unsigned int, short unsigned
int)':
/usr/include/sys/io.h:125: parse error before `::'
/usr/include/sys/io.h: In function `void outl_p(unsigned int, short unsigned
int)':
/usr/include/sys/io.h:131: parse error before `::'
--
Joe
|
|
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
|
|
From: Joe P. <joe...@sn...> - 2001-03-12 23:58:00
|
On Monday 12 March 2001 02:53 pm, PASCHAL,DAVID (HP-Roseville,ex1) wrote: <...> > 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. Done. > (regarding whether putting a space between the double colons fixes the > problem): > 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 changed io.h to include a space between every instance of '::'. The hpoj package built afterwards with no errors. I didn't want to leave the file like that, so it's back to the original now. If you find a good work-around for the problem, it would be great. I haven't tried to install or test the package yet. I'll probably wait until the io.h work-around arrives. -- Joe |
|
From: <pa...@rc...> - 2001-03-13 09:01:17
|
Hi, Joe. Joe Piolunek wrote in response to me: > > 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. > > Done. Got it. Thanks. It's exactly the same as the version on my 6.2 system, so it's obviously the difference in compilers that causes the problem. > I changed io.h to include a space between every instance of '::'. The hpoj > package built afterwards with no errors. I didn't want to leave the file like > that, so it's back to the original now. If you find a good work-around for > the problem, it would be great. Thanks for the info. > I haven't tried to install or test the package yet. I'll probably wait until > the io.h work-around arrives. I just checked it into CVS. Please do a "cvs update" and try it now. I decided to go with the C wrapper workaround method. It's only enabled when necessary, to avoid a performance penalty (however small) when the workaround isn't needed. If you're interested, you can try running the configure script with either the original or "fixed" version of io.h and see that configure enables or disables the workaround as necessary. On my system, I simulated the problem by adding the following three lines to create a "broken" version: #ifdef __cplusplus #error Simulating broken C++ compiler #endif Thanks for your patience while I fix all of the "but it works on my system" problems. :-) BTW, in case anybody has run into problems building without parallel port support (./configure --without-par), I fixed some compilation problems in that scenario also. David |
|
From: Joe P. <joe...@sn...> - 2001-03-13 17:18:08
|
On Tuesday 13 March 2001 04:03 am, David Paschal wrote: <...> > > I haven't tried to install or test the package yet. I'll probably wait > > until the io.h work-around arrives. > > I just checked it into CVS. Please do a "cvs update" and try it now. > David: The package builds for me now with no errors. -- Joe |
|
From: Joe P. <joe...@sn...> - 2001-03-18 00:01:06
|
On Tuesday 13 March 2001 04:03 am, David Paschal wrote: <...> > > I haven't tried to install or test the package yet. I'll probably wait > > until the io.h work-around arrives. > > I just checked it into CVS. Please do a "cvs update" and try it now. > > I decided to go with the C wrapper workaround method. It's only enabled > when necessary, to avoid a performance penalty (however small) when the > workaround isn't needed. If you're interested, you can try running the > configure script with either the original or "fixed" version of io.h and > see that configure enables or disables the workaround as necessary. On my > system, I simulated the problem by adding the following three lines to > create a "broken" version: #ifdef __cplusplus > #error Simulating broken C++ compiler > #endif David: The package I got from CVS on Mar. 14 builds without errors, but I can't seem to get it to print. The section below seems to indicate that it is working in some fashon. [root@tumbleweed joe]# /usr/local/sbin/ptal-mlcd par:0 -base 0x378 [root@tumbleweed joe]# /usr/local/sbin/ptal-printd mlc:par:0 -like /dev/lp0 [root@tumbleweed joe]# pidof ptal-printd ptal-mlcd 1124 1122 [root@tumbleweed joe]# ptal-devid mlc:par:0 MFG:Hewlett-Packard;MDL:OfficeJet Series 600;CMD:MLC,PCL,PML;CLASS:PRINTER;REV:4.03b; I may just be overlooking something, but with the earlier build problem due to compiler differences, this may have a similar cause. Has anyone yet been able to use gcc-2.95.2 sucessfully with the new code in CVS? Here are some of the messages that appeared on the command line at one point. I'm not sure what I was doing when they appeared (possibly trying to print), but maybe they'll mean something to you. Sorry if it doesn't help. ]$ ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>, pid=939, errno=11 Reply timer popped on port=0, count=1! ptal-mlcd: ERROR at ExMgr.cpp:783, dev=<par:0>, pid=939, errno=11 exClose(reason=4202) ptal-mlcd: ERROR at ParPort.cpp:163, dev=<par:0>, pid=939, errno=11 statusWaitSetClear(event=23) timed out! ]$ The install/print-howto instructions do seem like they could be simplified. -- Joe |
|
From: Alexander Z. <Ale...@fm...> - 2001-03-19 08:09:10
|
On 17 Mar, Joe Piolunek wrote: > Has anyone yet been able to use gcc-2.95.2 sucessfully with the new code in > CVS? Yes, I compiled with gcc-2.95.2 and everything works. > ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>, > pid=939, errno=11 I got similar error messages when I tried ptal-printd the first time, as I liked to test it, before installing it all. But in this case the runtime linker used the obsolete libptal-libraries from the prior installation instead of the new from CVS build. Or in short word's: make sure you're using the right libptal-libraries. -- Ale...@fm... / Girls who throw themselves at http://www.fmi.uni-passau.de/~zimmerma/ men, are actually taking very for PGP public key finger / careful aim. zim...@yo... / |
|
From: Joe P. <joe...@sn...> - 2001-03-19 16:16:09
|
On Monday 19 March 2001 03:11 am, Alexander Zimmermann wrote: > On 17 Mar, Joe Piolunek wrote: > > Has anyone yet been able to use gcc-2.95.2 sucessfully with the new code > > in CVS? > > Yes, I compiled with gcc-2.95.2 and everything works. > > > ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>, > > pid=939, errno=11 > > I got similar error messages when I tried ptal-printd the first time, as > I liked to test it, before installing it all. But in this case the > runtime linker used the obsolete libptal-libraries from the prior > installation instead of the new from CVS build. > > Or in short word's: make sure you're using the right libptal-libraries. Thanks for the reply, Alexander. That isn't the problem, though. I removed the previous installation before installing the new one. -- Joe |
|
From: <pa...@rc...> - 2001-03-14 08:06:59
|
Alexander Zimmermann wrote: > The current CVS code with ptal-mlcd compiles and works fine (printing > and scanning) on my system: > > RedHat 7.0, kernel 2.2.16 SMP, gcc 2.95.2, glibc 2.2 > G85 connected to parport 0 (in ECP mode) > > Color scanning of one A4 page at 75 dpi lasts about 1 minute. > (Is that a normal time?) Hi, Alexander. Thanks for the report. Parallel-port I/O with ptal-mlcd is slower in general than it was with the old kernel-mode drivers. (I too was disappointed when I discovered that.) I will do some optimization eventually to try to improve performace, but in any case at least it should be a lot more robust with SMP than the old drivers. In the meantime, if your system supports USB then you can get much better performance that way, but you'll need to upgrade drivers/usb/printer.c in the kernel. David |
|
From: <pa...@rc...> - 2001-03-18 00:29:07
|
Joe Piolunek wrote: > The package I got from CVS on Mar. 14 builds without errors, but I can't seem > to get it to print ... > Here are some of the messages that appeared on the command line at one point. > I'm not sure what I was doing when they appeared (possibly trying to print), > but maybe they'll mean something to you. Sorry if it doesn't help. > > ]$ > ptal-mlcd: ERROR at transport/ExMlcCommandChannel.cpp:186, dev=<par:0>, > pid=939, errno=11 > Reply timer popped on port=0, count=1! > > ptal-mlcd: ERROR at ExMgr.cpp:783, dev=<par:0>, pid=939, errno=11 > exClose(reason=4202) > > ptal-mlcd: ERROR at ParPort.cpp:163, dev=<par:0>, pid=939, errno=11 > statusWaitSetClear(event=23) timed out! > ]$ Hi, Joe. The reply timer pop probably happened 15 seconds after the first connection attempt was made to start up MLC, and indicates that there's some problem receiving a reply to an MLC command, probably due to a communication error. Please try the following test: - Run "script" in order to capture the following output. - Invoke ptal-mlcd as you normally do, but append the "-nofork" switch to the command line. This will bring up a debug console. - Issue the command "log" to turn on debug logging. - Issue the command "activate" to start the MLC conversation with the peripheral. - As soon as the initial log messages stop, issue the command "dump" to display all the internal state. - After about 15 seconds, you'll probably get some more log messages including the reply timer pop message. - Ctrl-C out of ptal-mlcd, Ctrl-D out of "script", and mail me the output. This will enable me to see how far it got before the error happened. > The install/print-howto instructions do seem like they could be simplified. OK, I'll look into that at some point. Thanks, David |
|
From: Joe P. <joe...@sn...> - 2001-03-11 18:17:51
|
On Saturday 10 March 2001 11:00 pm, David Paschal wrote:
> > /usr/include/sys/io.h:98: parse error before `::'
>
> Hi, Joe. Thanks for the bug report. I just checked in a change to
> ParPort.h to wrap "#include <sys/io.h>" with 'extern "C" { }'. Try it
> again after doing a "cvs update" and see if that fixes the problem.
> Perhaps I should go through and do this around most if not all #includes
> from C++ files, just to be on the safe side.
>
Unfortunately, the error still occurs.
A search for " /usr/include/sys/io.h:98: parse error before `::'" turned up a
few comments indicating that it may be related to a bug in gcc, which may be
fixed in ver. 2.96 . There was a report of the problem going away if using an
earlier version of glibc. A suggested fix is to "change '::' to ' : : ' in
sys/io.h" . I tried to use a #define ... #undef wrapper, but got errors about
using an improper macro name.
--
Joe
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X