Menu

#146 Issues with MinGW and v1.1.0

v1.1.x
closed
5
2013-05-30
2012-11-06
No

I ran into some issues compiling the latest code with mingw. I've included a patch file to show the differences, though I am running it off a different SVN so it won't merge in correctly with the log4cplus trunk.

Anyway, my issues:

The define LOG4CPLUS_HAVE_INTRIN_H includes a header that isn't included in mingw (intrin.h). So I removed including that header as part of mingw.

The function LockFile::open (int open_flags) calls _tsopen_s which is not part of mingw. I modified this function to switch on the UNICODE define and call _wsopen or _sopen.

Discussion

  • Václav Haisman

    Václav Haisman - 2012-11-06

    Thank you for the patch. You seem to be using MinGW32 distribution. Is this correct? The intrin.h header is present in MinGW64 distribution that I am using. Also the *_s() functions are present there. I wonder if there is not some preprocessor symbol that could help to distinguish these two compilers/distributions.

     
  • Chris Steenwyk

    Chris Steenwyk - 2012-11-07

    It looks like the 64-bit version defines both __MINGW64__ AND __MINGW32__ where the 32-bit version only defines __MINGW32__

    So I think for the 64-bit specific stuff we could use __MINGW64__, and for all other mingw specific stuff we could use __MINGW32__

     
  • Chris Steenwyk

    Chris Steenwyk - 2012-11-07

    Update to use _tsopen which is in both VS and MinGW

     
  • Chris Steenwyk

    Chris Steenwyk - 2012-11-07

    Resolved an issue related to unicode strings

     
  • Chris Steenwyk

    Chris Steenwyk - 2012-11-07

    Updated some defines to use MINGW64, added a new define to resolve issues with vswprintf

     
  • Chris Steenwyk

    Chris Steenwyk - 2012-11-07

    I was able to modify a few files to use the __MINGW64__ define and did some more research on the vsnwprintf. With the updates I attached I was able to get the build to work in:
    VS2010
    MinGW
    GCC 4.6.3 on Ubuntu
    All with and without Unicode enabled.

     
  • Václav Haisman

    Václav Haisman - 2012-11-12

    For the snprintf.cxx change, I am applying one slightly different. TBH, I think this is a MinGW bug.

    === modified file 'src/snprintf.cxx'
    --- a/src/snprintf.cxx 2012-06-16 18:17:17 +0000
    +++ b/src/snprintf.cxx 2012-11-12 13:58:45 +0000
    @@ -127,8 +127,11 @@
    #if defined (UNICODE)
    # if defined (LOG4CPLUS_HAVE__VSNWPRINTF_S) && defined (_TRUNCATE)
    ret = _vsnwprintf_s (dest, dest_size, _TRUNCATE, fmt, args);
    +# elif defined (LOG4CPLUS_HAVE_VSNWPRINTF)
    + ret = vsnwprintf (dest, dest_size, fmt, args);
    # else
    - ret = std::vswprintf (dest, dest_size, fmt, args);
    + using namespace std;
    + ret = vswprintf (dest, dest_size, fmt, args);
    # endif
    #else
    # if defined (LOG4CPLUS_HAVE_VSNPRINTF_S) && defined (_TRUNCATE)

     
  • Václav Haisman

    Václav Haisman - 2012-11-13

    I have fixed some of the issues you have found. Please try building trunk, it should now compile ok.

    I have not yet fixed the sockets accept issue and the codecvt<> issue will need some more work as well.

     
  • Václav Haisman

    Václav Haisman - 2013-05-30
    • labels: Build --> Build, mingw, unicode
    • status: open --> closed
    • Group: --> v1.1.x
     
  • Václav Haisman

    Václav Haisman - 2013-05-30

    I believe this is already fixed. Please open a new bug report if you find any problem.

     

Log in to post a comment.

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.