"Shawn O'Shea" <sh...@eth0.net> writes: > The originators of psock were at cesnet.cz, there is a link to > the library at http://www.cesnet.cz/project/qosip > > The make doesn't finish. Several compile errors. I played > about a bit, but did not make much headway... > > I was curious and downloaded this. I'm working on CentOS 5.3 (32-bit). > > After untarring and doing a ./configure, when I try to make, very > early in the compile I got the following error (which I presume was > similar with your attempts): > > gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -MT pollall_cdrv.lo -MD -MP -MF .deps > /pollall_cdrv.Tpo -c ptransfer/pollall_cdrv.c -fPIC -DPIC -o .libs/ > pollall_cdrv.o > ptransfer/pollall_cdrv.c: In function 'ptransfer_pollall_send_block': > ptransfer/pollall_cdrv.c:119: error: invalid lvalue in assignment > make[2]: *** [pollall_cdrv.lo] Error 1 > make[2]: Leaving directory `/storage/home/shawn/psock-0.2a/psock' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/storage/home/shawn/psock-0.2a' > make: *** [all] Error 2 > > I googled: error: invalid lvalue in assignment > The first google result is this discussion thread: > http://www.tek-tips.com/viewthread.cfm?qid=1353180&page=12 > > It is noted by the original poster later in the thread "[...] we haven't had > issues with it compiling and working until we moved to gcc 4" > He later notes " I have found referrences where the developers of gcc dropped > support for 'casting an l-value', they called it a 'bogosity'."
Yes, that's right. The code in question is: (const void*)iov[1].iov_base = buf; And..., wow. That *does* look bogus. Even at the surface--if you need a cast to remedy a type-mismatch, just put the cast on the *other* side. Of course, if it's on the other side, the it the cast needs to be the `other type', too. Looking beyond the surface...: > So it would appear this code is not "gcc4 friendly", so it either needs to be > fixed (suggestions on how to do this are presented in the thread), or use a > gcc3.x compiler. RH/CentOS provide such in the compat-gcc-34 (and C++ in > compat-gcc-34-c++) packages. "not `gcc4 friendly'" is not the term I'd use. The term I'd use is probably more along the lines of... "wrong", but "bogosity" is also apropos ;) The problem becomes clear when you move the cast to the right (pun!) side: iov[1].iov_base = (void*) buf; See how the cast just /removes/ the `const' qualifier from the value? What that's saying is `this memory may be read-only, but we're going to pretend that we can write to it regardless'. So, the /actual/ fix is (presumably) to remove all of the `const' qualifiers leading up to `const void *buf', and make sure that there aren't actually any read-only buffes being passed along that path. This may be somewhat involved. Alternately, you can just add another level of indirection, e.g.: *((const void**) &iov[1].iov_base) = buf; This is much `simpler': it just circumvents the sanity-check that GCC4 is doing, so the code may not actually /work right/, but it will compile without complaint. There is a chance the the code's authors were right to do what they were doing. It doesn't smell right, though. -- Don't be afraid to ask (Lf.((Lx.xx) (Lr.f(rr)))). _______________________________________________ gnhlug-discuss mailing list gnhlug-discuss@mail.gnhlug.org http://mail.gnhlug.org/mailman/listinfo/gnhlug-discuss/