SourceForge has been redesigned. Learn more.

#97 [wxJSON][v1.1] Build errors and warnings with gcc

wxJSON (16)

I've put comments in the patch.


  • catalin

    catalin - 2009-11-17

    p.s. when compiling with wxW 2.9.1

  • Luciano Cattani

    Luciano Cattani - 2009-11-18

    Hi catalin,
    thanks for your feedback. Are you using wxGTK 2.9.1 on a linux machine?
    I use it, too but I encontered no compile errors; many warnings on the test application but most of them are of no interest for wxJSON users.

    --- include/wx/json_defs.h (revision 1093)
    +++ include/wx/json_defs.h (working copy)
    #if wxCHECK_VERSION(2, 9, 0 )
    #define WXWIN_COMPATIBILITY_2_8 1

    OK. The code will be removed from wxJSON sources. I understand now what the macro is for, many thanks


    @@ -200,13 +206,14 @@
    // force use of STL-style implementation of wxHashMap container
    // this is needed for compiling on MinGW
    // wxJSON_USE_MINGW //+what is this for?

    wxJSON does not compile on MinGW. The problem is the redefinition of wxJSONInternalMap when the JSON object type is implemented as a wxHashMap, the wxWdiget's own implementation of a std::map container. To know the details of this failure look at wxCode's bug tracker ID 2807075 and ID 2735592.


    --- src/jsonwriter.cpp (revision 1093)
    +++ src/jsonwriter.cpp (working copy)

    @@ -861,7 +861,11 @@
    wxASSERT( data );

    #if defined( wxJSON_64BIT_INT )
    - snprintf( buffer, 32, "%lli", data->m_value.m_valInt64 );
    +//These are to make it compile with gcc.
    +//"ll" is MS speciffic.
    +//But (!) to make it work you need to compile using wxW rev >= 62562
    +//- also see
    + snprintf( buffer, 32, "%" wxLongLongFmtSpec "d",
    +data->m_value.m_valInt64 );
    snprintf( buffer, 32, "%ld", data->m_value.m_valLong ); #endif @@ -898,7 +902,7 @@

    Well, wxJSON _has_ to be compatible with 2.8
    The only solution I found is to use conditional compilation like the following:

    #if wxCHECK_VERSION(2, 9, 0 ) || !defined( wxJSON_USE_UNICODE )
    // this is fine for wxW 2.9 and for wxW 2.8 ANSI
    snprintf( buffer, 32, "%" wxLongLongFmtSpec "d",
    data->m_value.m_valInt64 );
    // this is for wxW 2.8 Unicode: in order to use the cross-platform
    // format specifier, we use the wxString's sprintf() function and then
    // convert to UTF-8 before writing to the stream
    wxString s = wxString::Sprintf( "%" wxLongLongFmtSpec "d",
    data->m_value.m_valInt64 );
    wxCharBuffer cb = s.ToUTF8();
    wxASSERT( cb.GetDataLen() <= 32 );
    memcpy( buffer,, cb.GetDataLen());
    // now we can write 'buffer'

  • catalin

    catalin - 2009-11-18

    Oh, I didn't actually say it.. :-s : I used mingw-gcc 3.4.5 and it does compile fine, with the patch applied, even without the need of WXWIN_COMPATIBILITY_2_8 set to 1 in setup.h.

    For point nr.2: maybe that comment has a purpose but could it be in the wrong place? I just could not relate it to any code surrounding it, but maybe I just didn't see the relevant part.

    For point nr 3: sorry, I do think now that what I sent you broke compilation for 2.8.x Unicode, but I did not intend that.
    If your solution works it is ok with me. :)

  • Luciano Cattani

    Luciano Cattani - 2009-12-05

    Fixed bugs in the SVN repo. Will also be fixed in the next 1.1.1 release (coming soon)

  • Luciano Cattani

    Luciano Cattani - 2009-12-05
    • status: open --> closed
  • Luciano Cattani

    Luciano Cattani - 2009-12-07

    Sorry for not seeing the enclosed patch file.
    I reopen the bug report and will fix all warnings in the next days. A new file release will be uploaded to SF when done

  • Luciano Cattani

    Luciano Cattani - 2009-12-07
    • status: closed --> open

Log in to post a comment.