Details

    • Type: Sub-task Sub-task
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 0.6
    • Fix Version/s: 0.7
    • Component/s: C++ Broker
    • Labels:
      None
    • Environment:

      Description

      I'm trying to build qpid c++ broker on FreeBSD.
      Problems found during the build process:
      --------------------------------------------------------------------8<--------------------------------------------------------------------
      g++ -DHAVE_CONFIG_H -I. -Igen -I./gen -I/usr/local/include -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual -g -O2 -MT qpid/sys/posix/Thread.lo -MD -MP -MF qpid/sys/posix/.deps/Thread.Tpo -c qpid/sys/posix/Thread.cpp -fPIC -DPIC -o qpid/sys/posix/.libs/Thread.o
      qpid/sys/posix/Thread.cpp: In member function 'long unsigned int qpid::sys::Thread::id()':
      qpid/sys/posix/Thread.cpp:64: error: invalid conversion from 'pthread*' to 'long unsigned int'

      I don't know whether it helps during the run, but allows to compile:
      return (unsigned long)impl->thread;
      --------------------------------------------------------------------8<--------------------------------------------------------------------
      g++ -DHAVE_CONFIG_H -I. -Igen -I./gen -I/usr/local/include -Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual -g -O2 -MT qpid/sys/posix/SystemInfo.lo -MD -MP -MF qpid/sys/posix/.deps/SystemInfo.Tpo -c qpid/sys/posix/SystemInfo.cpp -fPIC -DPIC -o qpid/sys/posix/.libs/SystemInfo.o
      In file included from qpid/sys/posix/SystemInfo.cpp:25:
      /usr/include/net/if.h:293: error: field 'ifru_addr' has incomplete type
      /usr/include/net/if.h:294: error: field 'ifru_dstaddr' has incomplete type
      /usr/include/net/if.h:295: error: field 'ifru_broadaddr' has incomplete type
      /usr/include/net/if.h:327: error: field 'ifra_addr' has incomplete type
      /usr/include/net/if.h:328: error: field 'ifra_broadaddr' has incomplete type
      /usr/include/net/if.h:329: error: field 'ifra_mask' has incomplete type
      /usr/include/net/if.h:427: error: field 'addr' has incomplete type
      /usr/include/net/if.h:428: error: field 'dstaddr' has incomplete type
      qpid/sys/posix/SystemInfo.cpp: In function 'void qpid::sys::SystemInfo::getLocalIpAddresses(uint16_t, std::vector<qpid::Address, std::allocator<qpid::Address> >&)':
      qpid/sys/posix/SystemInfo.cpp:63: error: 'PF_INET' was not declared in this scope
      qpid/sys/posix/SystemInfo.cpp:63: error: 'SOCK_STREAM' was not declared in this scope
      qpid/sys/posix/SystemInfo.cpp:63: error: 'socket' was not declared in this scope
      qpid/sys/posix/SystemInfo.cpp:66: error: 'struct ifreq' has no member named 'ifr_ifindex'
      qpid/sys/posix/SystemInfo.cpp:67: error: 'SIOCGIFNAME' was not declared in this scope
      qpid/sys/posix/SystemInfo.cpp:72: error: 'union ifreq::<anonymous>' has no member named 'ifru_addr'
      qpid/sys/posix/SystemInfo.cpp:73: error: invalid use of incomplete type 'struct qpid::sys::sockaddr_in'
      qpid/sys/posix/SystemInfo.cpp:72: error: forward declaration of 'struct qpid::sys::sockaddr_in'

      The "incomplete type" error can be fixed by including sys/socket.h before net/if.h.
      The "'struct ifreq' has no member named 'ifr_ifindex'" can be fixed by:
      #ifdef _FreeBSD_
      ifr.ifr_index = i;
      #else
      ifr.ifr_ifindex = i;
      #endif

      The "'SIOCGIFNAME' was not declared in this scope" is hopefully solved by:
      #ifdef SIOCGIFNAME
      if (::ioctl (s, SIOCGIFNAME, &ifr) < 0)
      #else
      if (!if_indextoname(ifr.ifr_index, ifr.ifr_name))
      #endif
      break;

      The "forward declaration of 'struct qpid::sys::sockaddr_in'" can be solved by including net/pfvar.h after if.h
      --------------------------------------------------------------------8<--------------------------------------------------------------------
      g++ Werror -pedantic -Wall -Wextra -Wno-shadow -Wpointer-arith -Wcast-qual -Wcast-align -Wno-long-long -Wvolatile-register-var -Winvalid-pch -Wno-system-headers -Woverloaded-virtual -DMODULE_DIR=\"/usr/local/lib/qpid/daemon\" -DCONF_FILE=\"/usr/local/etc/qpidd.conf\" -g -O2 -o .libs/qpidd qpidd-qpidd.o posix/qpidd-QpiddBroker.o -L/usr/local/lib -L/usr/lib/openais -L/usr/lib64/openais -L/usr/lib/corosync -L/usr/lib64/corosync ./.libs/libqpidbroker.so /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so ./.libs/libqpidcommon.so -lboost_program_options -lboost_filesystem -luuid -Wl,-rpath -Wl,/usr/local/lib
      /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to `qpid::sys::Poller::interrupt(qpid::sys::PollerHandle&)'
      /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to `typeinfo for qpid::sys::PollerHandle'
      ./.libs/libqpidbroker.so: undefined reference to `qpid::sys::Poller::shutdown()'
      /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to `qpid::sys::PollerHandle::~PollerHandle()'
      ./.libs/libqpidbroker.so: undefined reference to `qpid::sys::Poller::Poller()'
      /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to `qpid::sys::Poller::addFd(qpid::sys::PollerHandle&, qpid::sys::Poller::Direction)'
      /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to `qpid::sys::Poller::delFd(qpid::sys::PollerHandle&)'
      /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to `qpid::sys::PollerHandle::PollerHandle(qpid::sys::IOHandle const&)'
      /test/qpid/qpid/cpp/src/.libs/libqpidcommon.so: undefined reference to `qpid::sys::Poller::modFd(qpid::sys::PollerHandle&, qpid::sys::Poller::Direction)'

      This will be harder.
      I think it would be nice to have at least a standard select/poll interface. Going straight with (and only with) the specialised OS-dependent interfaces seem to be a bad idea for the poor people, not running Linux (or Solaris, or Windows, if they work correctly).
      BTW, shouldn't using libevent or libev would be more logical?

      1. qpidfbsdcompile.diff
        1 kB
        Attila Nagy
      2. freebsd.patch
        4 kB
        Andrey Kotrekhov
      3. sasl.diff
        1 kB
        Andrey Kotrekhov

        Issue Links

          Activity

          Hide
          Attila Nagy added a comment -

          Silly changes made so far, just to realize that there is no general poll or select support in the code.

          Show
          Attila Nagy added a comment - Silly changes made so far, just to realize that there is no general poll or select support in the code.
          Hide
          Carl Trieloff added a comment -

          probably find most of what you are needing in the windows port dir

          Carl.

          Show
          Carl Trieloff added a comment - probably find most of what you are needing in the windows port dir Carl.
          Hide
          Alan Conway added a comment -

          A POSIX compliant select() or poll() based implementation of the Poller would be great for Unix portability, as you say the current set of Pollers are all tied to OS-specific mechanisms. Look at qpid/cpp/src/qpid/sys/epoll/EpollPoller.cpp and qpid/cpp/src/qpid/sys/windows/IocpPoller.cpp for examples of how to implement a Poller.

          Show
          Alan Conway added a comment - A POSIX compliant select() or poll() based implementation of the Poller would be great for Unix portability, as you say the current set of Pollers are all tied to OS-specific mechanisms. Look at qpid/cpp/src/qpid/sys/epoll/EpollPoller.cpp and qpid/cpp/src/qpid/sys/windows/IocpPoller.cpp for examples of how to implement a Poller.
          Hide
          Bruno Matos added a comment -

          If the pthread_t structure depends on implementation, could we use the boost high level threading mechanisms instead of qpid/sys/posix/Thread.cpp?

          I'm trying to compile qpid in mac os x, I know this is a long road, but I'm trying one step at a time.

          Thank you.

          Show
          Bruno Matos added a comment - If the pthread_t structure depends on implementation, could we use the boost high level threading mechanisms instead of qpid/sys/posix/Thread.cpp? I'm trying to compile qpid in mac os x, I know this is a long road, but I'm trying one step at a time. Thank you.
          Hide
          Sam Hendley added a comment -

          I agree with you, we have been looking at this issue as well, trying to compile for cygwin and arm. I have been thinking of using boost threading and boost asio to make new target that matches the implict interface of the posix/solaris and windows "system" implementations. This is a pattern we have used for some of our own projects, we started writing platform specific code for the system specific stuff like threading and locks and then found we could replace it all with boost constructs. One nice thing about going that route is we were forced to treat the system specific stuff like a black box from the main code (as qpid has done) so it made the transition to boos/asio very easy. QPid may be similar, they allready are carrying all of the necessary boost dependecies for asio so thats a big plus.

          Show
          Sam Hendley added a comment - I agree with you, we have been looking at this issue as well, trying to compile for cygwin and arm. I have been thinking of using boost threading and boost asio to make new target that matches the implict interface of the posix/solaris and windows "system" implementations. This is a pattern we have used for some of our own projects, we started writing platform specific code for the system specific stuff like threading and locks and then found we could replace it all with boost constructs. One nice thing about going that route is we were forced to treat the system specific stuff like a black box from the main code (as qpid has done) so it made the transition to boos/asio very easy. QPid may be similar, they allready are carrying all of the necessary boost dependecies for asio so thats a big plus.
          Hide
          Bruno Matos added a comment -

          We just need someone of the core team to point us the way...

          Show
          Bruno Matos added a comment - We just need someone of the core team to point us the way...
          Hide
          Andrey Kotrekhov added a comment - - edited

          this patch isn't only for freebsd but may be any other posix OS.

          • saslpasswd2 may be placed in /usr/local/sbin or another alternate path. FreeBSD usually has it in /usr/local/sbin
          • rewrite method: void SystemInfo::getLocalIpAddresses (uint16_t port,
            std::vector<Address> &addrList)
            FreeBSD doesn't have SIOCGIFNAME ioctl. linux has it. I don't know about other xBSD. Method is rewritten to be be more generic and compile under FreeBSD and Linux.
          • change declaration pthread_t Thread::id() method.
            IMHO it is true that pthread ID has pthread_t type but not unsigned long.
            If in some OS these are equel typedef is a right way. Do you agree with me?
            the same is about logId() method.

            During compilation I see some finctions isn't implements in posix part of qpidc source at all.
            What is the main road, to do vedor specific epoll& kqueue & etc or to complit posix variant of code?
          Show
          Andrey Kotrekhov added a comment - - edited this patch isn't only for freebsd but may be any other posix OS. saslpasswd2 may be placed in /usr/local/sbin or another alternate path. FreeBSD usually has it in /usr/local/sbin rewrite method: void SystemInfo::getLocalIpAddresses (uint16_t port, std::vector<Address> &addrList) FreeBSD doesn't have SIOCGIFNAME ioctl. linux has it. I don't know about other xBSD. Method is rewritten to be be more generic and compile under FreeBSD and Linux. change declaration pthread_t Thread::id() method. IMHO it is true that pthread ID has pthread_t type but not unsigned long. If in some OS these are equel typedef is a right way. Do you agree with me? the same is about logId() method. — During compilation I see some finctions isn't implements in posix part of qpidc source at all. What is the main road, to do vedor specific epoll& kqueue & etc or to complit posix variant of code?
          Hide
          Andrew Stitcher added a comment -

          I really like the patch which uses getifaddrs() for portability - I will test and apply that.

          The patch for saslpasswd2 isn't IMO portable enough. Now we've just specified 2 possible locations it might occur in, I suggest 2 possibilities here: either look for saslpasswd2 in the configure phase (using a list of locations like /usr/sbin:/usr/local/sbin:/sbin etc.) so that adding a new location would be easy.

          And/or try to run it from the path (this should work on FreeBSD usually), then if that fails try /usr/sbin which is the specific location for Red Enterprise 5 where this is not on the default user PATH. For recent Fedoras it is on the path, for recent Debian it is too.

          As for exposing pthread_t, I am against this, as we have worked hard to isolate the threading (and other platform specific) libraries from the main code. Essentially the Id is not meant to be a reference to a thread (pthread_t) it is meant to be a (preferably low integer) id value that can be printed for the thread. Exposing pthread_t to the rest of qpid means making all the qpid code know about pthreads (At least from an include perspective) and means adding pointless typedefs or #defines for Windows which doesn't use pthreads. Another solution needed. Maybe the simplest would be simply to cast into an intptr_t would that work for FreeBSD?

          Show
          Andrew Stitcher added a comment - I really like the patch which uses getifaddrs() for portability - I will test and apply that. The patch for saslpasswd2 isn't IMO portable enough. Now we've just specified 2 possible locations it might occur in, I suggest 2 possibilities here: either look for saslpasswd2 in the configure phase (using a list of locations like /usr/sbin:/usr/local/sbin:/sbin etc.) so that adding a new location would be easy. And/or try to run it from the path (this should work on FreeBSD usually), then if that fails try /usr/sbin which is the specific location for Red Enterprise 5 where this is not on the default user PATH. For recent Fedoras it is on the path, for recent Debian it is too. As for exposing pthread_t, I am against this, as we have worked hard to isolate the threading (and other platform specific) libraries from the main code. Essentially the Id is not meant to be a reference to a thread (pthread_t) it is meant to be a (preferably low integer) id value that can be printed for the thread. Exposing pthread_t to the rest of qpid means making all the qpid code know about pthreads (At least from an include perspective) and means adding pointless typedefs or #defines for Windows which doesn't use pthreads. Another solution needed. Maybe the simplest would be simply to cast into an intptr_t would that work for FreeBSD?
          Hide
          Andrew Stitcher added a comment -

          Can't be a blocker as no regression of previous behaviour.

          Show
          Andrew Stitcher added a comment - Can't be a blocker as no regression of previous behaviour.
          Hide
          Andrey Kotrekhov added a comment -

          patch to find saslpasswd2 in $PATH on file system.
          Not all OS have saslpasswd2 exactly in /usr/sbin for example FreeBSD (see my prev. message).
          This patch adds portability.

          Show
          Andrey Kotrekhov added a comment - patch to find saslpasswd2 in $PATH on file system. Not all OS have saslpasswd2 exactly in /usr/sbin for example FreeBSD (see my prev. message). This patch adds portability.
          Hide
          Andrew Stitcher added a comment -

          I have now committed the portable version of getLocalIpAddresses()

          Some work for QPID-2527 should have fixed the Thread::id issue

          Show
          Andrew Stitcher added a comment - I have now committed the portable version of getLocalIpAddresses() Some work for QPID-2527 should have fixed the Thread::id issue
          Hide
          Andrew Stitcher added a comment - - edited

          FreeBsd and MacOS X have very similar low level APIs

          Show
          Andrew Stitcher added a comment - - edited FreeBsd and MacOS X have very similar low level APIs
          Hide
          Andrew Stitcher added a comment -

          Applied patch for saslpasswd issue on trunk at r938026.

          Show
          Andrew Stitcher added a comment - Applied patch for saslpasswd issue on trunk at r938026.
          Hide
          Sudip Kumar Panda added a comment -

          Can someone tell me if the poll or select support is provided in the latest version i.e. 0.8? I am still seeing the build errors in freebsd(amd64) though I see the status of the defect in "resolved" state.

          Show
          Sudip Kumar Panda added a comment - Can someone tell me if the poll or select support is provided in the latest version i.e. 0.8? I am still seeing the build errors in freebsd(amd64) though I see the status of the defect in "resolved" state.
          Hide
          Steve Huston added a comment -

          The supplied patches (or similar) were applied, which is why the jira was marked resolved. However, there were no patches supplied to provide a poller implementation that will work with FreeBSD. Such a poller implementation is required still in order to build on FreeBSD.

          Show
          Steve Huston added a comment - The supplied patches (or similar) were applied, which is why the jira was marked resolved. However, there were no patches supplied to provide a poller implementation that will work with FreeBSD. Such a poller implementation is required still in order to build on FreeBSD.
          Hide
          Sudip Kumar Panda added a comment -

          Thanks Steve. Since the defect was filed for failure on freebsd build and the defect is resolved, I thought all the issues are resolved. Probably, I can spend some of my time (when free) to write lower level poller code.

          Show
          Sudip Kumar Panda added a comment - Thanks Steve. Since the defect was filed for failure on freebsd build and the defect is resolved, I thought all the issues are resolved. Probably, I can spend some of my time (when free) to write lower level poller code.

            People

            • Assignee:
              Andrew Stitcher
              Reporter:
              Attila Nagy
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development