> -----Original Message----- > From: Alan Conway [mailto:acon...@redhat.com] > > Manuel Teira Paz wrote: > > Alan Conway escribió: > >> Manuel Teira Paz wrote: > >> > >>> Hello again. > >>> > >>> During the compilation stage of the trunk, I run into this error: > >>> > >>> > >>> source='qpid/broker/Bridge.cpp' object='qpid/broker/Bridge.lo' > >>> libtool=yes \ > >>> DEPDIR=.deps depmode=dashXmstdout /bin/bash ../build-aux/depcomp \ > >>> /bin/bash ../libtool --tag=CXX --mode=compile CC -g -m64 > >>> -DHAVE_CONFIG_H -I. -Igen -I./gen -I/opt/qpid/include > >>> -library=stlport4 -mt -c -o qpid/broker/Bridge.lo > qpid/broker/Bridge.cpp > >>> CC -g -m64 -DHAVE_CONFIG_H -I. -Igen -I./gen -I/opt/qpid/include
> >>> -library=stlport4 -mt -c qpid/broker/Bridge.cpp -KPIC -DPIC -o > >>> qpid/broker/.libs/Bridge.o > >>> "./qpid/sys/Socket.h", line 96: Error: socklen_t is not defined. > >>> "qpid/broker/Bridge.cpp", line 170: Warning: id hides > >>> qpid::broker::Bridge::id. > >>> 1 Error(s) and 1 Warning(s) detected. > >>> > >>> I started looking in my Solaris system, where socklen_t > is defined, > >>> and the place was sys/socket.h. Nevertheless, I see that the way > >>> integer types are intended to be imported now regardless > the platform > >>> is: > >>> qpid/sys/IntegerTypes.h > >>> > >>> that relies on a platform dependent file. > >>> > >>> The question here is, where exactly the socklen_t is > suposed to be > >>> defined in linux or a posix compliant system? The posix > >>> IntegerTypes.h in qpid is just including <stdint.h>, but > after a fast > >>> look in an Ubuntu system, I didn't find there any declaration for > >>> socklen_t. Another curious thing about socklen_t is what > I've found > >>> here: > >>> > >>> > http://portabilityblog.com/blog/archives/7-socklen_t-confusion.html > >>> > >>> Also, the declaration for solaris is not trivial: > >>> > >>> > >>> #if defined(_XPG4_2) && !defined(_XPG5) && !defined(_LP64) > >>> typedef size_t socklen_t; > >>> #else > >>> typedef uint32_t socklen_t; > >>> #endif /* defined(_XPG4_2) && !defined(_XPG5) && > !defined(_LP64) */ > >>> > >>> > >>> Anyway, it seems to rely to uint32_t on normal cases. > >>> > >>> > >>> What do you think is the best way to proceed here? Just add a > >>> #include <sys/socket.h> in the posix IntegerTypes.h? > >> > >> I would only #include socket.h in network-related files that need > >> socklen_t, it's not really a generic integer type it's specific to > >> sockets. Where is it being used that we're not already including > >> socket.h? > >> > >> > > In qpid/sys/Socket.h. > > > > Furthermore, socklen_t is defined for the windows platform in their > > specific IntegerTypes.h, that was what led me to think that perhaps > > including socket.h in the posix counterpart, could be a (somewhat) > > coherent move. > > > > Another posibility would be to include sys/socket.h in > > qpid/sys/Socket.h. But since this is not posix specific, > perhaps the > > windows port could get damaged. > > That would be my preference, check with Steve if it's OK on > windows. I'm fairly > sure it is. If not you could add a sys/socklen.h with an > #ifdef to include the > appropriate file and include that in Socket.h. Adding a #include <sys/socket.h> would require a platform-specific ifdef, which I thought were highly frowned on. The approach taken in similar situations is to add a platform-specific header file (qpid/sys/posix/sys_socket.h or similar) and include that from qpid/sys/Socket.h. I put the socklen_t typedef for Windows in IntegerTypes.h because Windows doesn't define socklen_t anywhere. -Steve --------------------------------------------------------------------- Apache Qpid - AMQP Messaging Implementation Project: http://qpid.apache.org Use/Interact: mailto:dev-subscr...@qpid.apache.org
