Qpid
  1. Qpid
  2. QPID-2905

Fixes for mingw cross-compilation (C++)

    Details

      Description

      In attempting to cross-compile the Qpid trunk in the MinGW environment, a number of build errors were seen. Attached to this issue is a patch that fixes the errors and builds cleanly on Linux/gcc and MS Visual Studio as well.

      The classes of error discovered are:

      1) Case-sensitivity of file names (i.e. Secure32.lib => secure32.lib)
      2) Syntax issues where MSVC is too lenient (semicolon after the closing brace of a template function)
      3) *_EXTERN on DLL APIs. MinGW doesn't like externs on in-line functions, requires externs on class names.
      4) const_case<char*>() needed on LPTSTR arguments in the Windows API
      5) Unused function arguments need to be commented out
      6) the *_s variants of ::localtime, ::strncpy, ::strerror can't be used

      Before I commit, I would appreciate some review and feedback on this patch.

      1. cross2.diff
        65 kB
        Ted Ross

        Issue Links

          Activity

          Hide
          Steve Huston added a comment -

          Overall the patch looks good. I have two concerns:

          1. Importing code from LGPL... IANAL but this looks scary to me. Maybe run this by Apache legal to be sure it's not opening up Qpid to license problems.

          2. Is there a substantive long-term user that's going to maintain the MinGW stuff? My limited exposure to open source projects and MinGW is that people are quick to jump up and say they want a project to build on MinGW but are not willing to put up any resources to keep it up to date over time.

          Show
          Steve Huston added a comment - Overall the patch looks good. I have two concerns: 1. Importing code from LGPL... IANAL but this looks scary to me. Maybe run this by Apache legal to be sure it's not opening up Qpid to license problems. 2. Is there a substantive long-term user that's going to maintain the MinGW stuff? My limited exposure to open source projects and MinGW is that people are quick to jump up and say they want a project to build on MinGW but are not willing to put up any resources to keep it up to date over time.
          Hide
          Carl Trieloff added a comment -


          I looked at the case for use of LGPL, and I believe it is fine based on the ASF rules. It is an include for a compiler, and if not a dependency being brought into the project. Thus there is no need to use or distribute a component under LGPL or to use it and the project still remain intact and useful without it.

          Show
          Carl Trieloff added a comment - I looked at the case for use of LGPL, and I believe it is fine based on the ASF rules. It is an include for a compiler, and if not a dependency being brought into the project. Thus there is no need to use or distribute a component under LGPL or to use it and the project still remain intact and useful without it.
          Hide
          Carl Trieloff added a comment -

          Note I did not look at patch for content, (code) just for the legal question.

          Carl.

          Show
          Carl Trieloff added a comment - Note I did not look at patch for content, (code) just for the legal question. Carl.
          Hide
          Chuck Rolke added a comment -

          This patch does a decent job of the MinGW port.

          The only question I have is on patch line 992: Why does the cpp/CMakeLists file need a Boost_COMPILER setting? Further, is there any down side to setting the value to -gcc44 when compiling under MSVC? Could this be made conditional on MinGW builds (unless, of course, it's harmless)?

          It's almost time for a Conditional Variable Scoreboard. CMake uses MSVC, WIN32, and MSVC80. C++ uses _MSC_VER, _WINDOWS, and WIN32. Exactly how these are used and overloaded becomes less clear with this patch.

          Show
          Chuck Rolke added a comment - This patch does a decent job of the MinGW port. The only question I have is on patch line 992: Why does the cpp/CMakeLists file need a Boost_COMPILER setting? Further, is there any down side to setting the value to -gcc44 when compiling under MSVC? Could this be made conditional on MinGW builds (unless, of course, it's harmless)? It's almost time for a Conditional Variable Scoreboard. CMake uses MSVC, WIN32, and MSVC80. C++ uses _MSC_VER, _WINDOWS, and WIN32. Exactly how these are used and overloaded becomes less clear with this patch.
          Hide
          Andrew Beekhof added a comment -

          The Boost_COMPILER setting was needed, at least on Fedora, because the CMake was reporting the error below.
          I don't think there would be any problem making it conditional on !MSVC but IIRC Ted tested that MSVC compilation was unaffected.

          As for a long-term user, the Matahari project (of which I'm the lead) is looking to ship qpid based guest agents for Linux and Windows.
          Cross-compilation allows us to use existing distro build chains and ultimately include the agents in the distros (rather than host them separately).
          This is why we worked with Ted to create this patch.

          CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:894 (message):
          Unable to find the requested Boost libraries.

          Boost version: 1.41.0

          Boost include path: /usr/i686-pc-mingw32/sys-root/mingw/include

          The following Boost libraries could not be found:

          boost_filesystem
          boost_program_options
          boost_date_time
          boost_thread
          boost_regex
          boost_unit_test_framework

          No Boost libraries were found. You may need to set Boost_LIBRARYDIR to the
          directory containing Boost libraries or BOOST_ROOT to the location of
          Boost.

          Show
          Andrew Beekhof added a comment - The Boost_COMPILER setting was needed, at least on Fedora, because the CMake was reporting the error below. I don't think there would be any problem making it conditional on !MSVC but IIRC Ted tested that MSVC compilation was unaffected. As for a long-term user, the Matahari project (of which I'm the lead) is looking to ship qpid based guest agents for Linux and Windows. Cross-compilation allows us to use existing distro build chains and ultimately include the agents in the distros (rather than host them separately). This is why we worked with Ted to create this patch. CMake Error at /usr/share/cmake/Modules/FindBoost.cmake:894 (message): Unable to find the requested Boost libraries. Boost version: 1.41.0 Boost include path: /usr/i686-pc-mingw32/sys-root/mingw/include The following Boost libraries could not be found: boost_filesystem boost_program_options boost_date_time boost_thread boost_regex boost_unit_test_framework No Boost libraries were found. You may need to set Boost_LIBRARYDIR to the directory containing Boost libraries or BOOST_ROOT to the location of Boost.
          Hide
          Robbie Gemmell added a comment -

          Updating 'Fix For' to Unknown on issues not targeted for 0.8

          Show
          Robbie Gemmell added a comment - Updating 'Fix For' to Unknown on issues not targeted for 0.8
          Hide
          Chuck Rolke added a comment -

          I believe that checkin r1104662 has an error that breaks Solaris builds.
          File qpid/cpp/src/qpid/sys/alloca.h has unreachable code at line 38.

          To repair this I propose moving lines

          1. if !defined _WINDOWS && !defined WIN32
          2. include <alloca.h>
          3. endif
            #endif

          outside of the conditional block in which they are now contained.

          Show
          Chuck Rolke added a comment - I believe that checkin r1104662 has an error that breaks Solaris builds. File qpid/cpp/src/qpid/sys/alloca.h has unreachable code at line 38. To repair this I propose moving lines if !defined _WINDOWS && !defined WIN32 include <alloca.h> endif #endif outside of the conditional block in which they are now contained.

            People

            • Assignee:
              Ted Ross
              Reporter:
              Ted Ross
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development