#2041 Rename of Header Annotations to SAL__

OTHER
pending
None
Support
limbo
Waiting_User_Response
False
2016-02-12
2013-09-12
Praveen
No

Hi All,

I am trying to compile the perl DBD::DB2 driver using strawberry perl. When doing so I get a compiler error as below

C:/PROGRA~1/IBM/SQLLIB/include/sqlext.h:1747:5: error: unknown type name '__in_ecount'

This error is seen because Microsoft defines the header file sqlext.h with Header annotations as __in_ecount where as this is been renamed in MingW to SAL__in_ecount. Could you let me know why was this renaming done. Also how will I be able to get rid of this compiler error and proceed to build the DBD::DB2 driver [basically a C application using the DB2 ODBC driver] successfully.

A ticket is been opened as per request on the thread here

Thanks
Praveen

Discussion

  • Earnie Boyd

    Earnie Boyd - 2013-09-12
    • status: unread --> assigned
    • Resolution: none --> later
    • Category: Unknown --> Feature_in_WSL_4.1
     
  • Earnie Boyd

    Earnie Boyd - 2013-09-12

    A resolution might push to 5.0 but I'll take a look for 4.1.

     
    • RAHUL PRIYADARSHI

      Is there any update on this?
      could you update any timeline for this issue?

       
  • Earnie Boyd

    Earnie Boyd - 2013-09-13

    On Fri, Sep 13, 2013 at 7:52 AM, Andy Rushton wrote:

    I have followed this thread and tried out the various suggestions - changing
    winspool.dev to point to either winspool.drv or spoolss.dll, then rebuilding
    according to Earnie's instructions, but neither worked for me even though I
    have both on my system - winspool.drv is in SysWOW64 and spoolss.dll in
    System32. This is on a 64-bit Windows 7 machine, up to date and service packed.

    Linking against wxWidgets without the -lwinspool does give linker errors, so
    it is a wxWidgets dependency, not a mistake in the wxWidgets build system.

    Downloading winspool.dll from dll-files.com (yes, I know, risky) and
    dropping it into the same directory as the exe did work, so then I tried
    copying SysWOW64/winspool.drv to winspool.dll alongside the exe and that
    works too. So this is a workaround for now.

    The one experiment I haven't tried is reinstalling wxWidgets after
    reinstalling w32api - I'm assuming this is a link-time problem, but I
    suppose it might be a dependency of the wx DLLs. Anyone know?

    Andy

     
    • Keith Marshall

      Keith Marshall - 2013-09-13

      Is this relevant? It doesn't seem to be related. Did you, perhaps, paste it here by mistake?

       
      • Earnie Boyd

        Earnie Boyd - 2013-09-13

        Yes, my mistake, it should have gone to [#2037]. My eyesight is still blurred from surgery; but that didn't cause the mis-entry. ;p

         

        Related

        Issues: #2037

  • Praveen

    Praveen - 2014-02-10

    Hi Earnie,

    Any updates on this?

    Any link where we can see when mingW version releases scheduled?

    Thanks

    Praveen

     
  • WinOSS

    WinOSS - 2015-01-24

    It would be nice to have this fixed, same bug breaks compiling jxrlib ... after renaming changing either the mingw header (removing SAL) or the jxrlib source (adding SAL) it works just fine.

     
  • Marco

    Marco - 2016-01-26

    Hello, any news?

     
  • Keith Marshall

    Keith Marshall - 2016-01-26
    • Description has changed:

    Diff:

    --- old
    +++ new
    @@ -1,19 +1,13 @@
     Hi All,
    
    -         I am trying to compile the perl DBD::DB2 driver using strawberry
    - perl. When doing so I get a compiler error as below
    +I am trying to compile the perl DBD::DB2 driver using strawberry perl. When doing so I get a compiler error as below
    +~~~~
    +C:/PROGRA~1/IBM/SQLLIB/include/sqlext.h:1747:5: error: unknown type name '__in_ecount'
    +~~~~
    
    - C:/PROGRA~1/IBM/SQLLIB/include/sqlext.h:1747:5: error: unknown type name
    - '__in_ecount'
    +This error is seen because Microsoft defines the header file sqlext.h with Header annotations as `__in_ecount` where as this is been renamed in MingW to `SAL__in_ecount`. Could you let me know why was this renaming done. Also how will I be able to get rid of this compiler error and proceed to build the DBD::DB2 driver [basically a C application using the DB2 ODBC driver] successfully.
    
    -         This error is seen because Microsoft defines the header file
    - sqlext.h with Header annotations as __in_ecount where as this is been
    - renamed in MingW to SAL__in_ecount. Could you let me know why was this
    - renaming done. Also how will I be able to get rid of this compiler error and
    - proceed to build the DBD::DB2 driver [basically a C application using the
    - DB2 ODBC driver] successfully.
    -
    -    A ticket is been opened as per request on the thread here https://sourceforge.net/mailarchive/forum.php?thread_name=CA%2Bsc5mm0KFevf%3D39pbPV59x%2BiLcyV2F_FL%3D%3DDHPK-2NyL55O3g%40mail.gmail.com&forum_name=mingw-users
    +A ticket is been opened as per request on the [thread here](https://sourceforge.net/mailarchive/forum.php?thread_name=CA%2Bsc5mm0KFevf%3D39pbPV59x%2BiLcyV2F_FL%3D%3DDHPK-2NyL55O3g%40mail.gmail.com&forum_name=mingw-users)
    
     Thanks
     Praveen
    
     
  • Keith Marshall

    Keith Marshall - 2016-01-26

    I do not understand the issue here. Nowhere within my w32api source tree can mercurial find any reference to SAL__in_ecount ... it doesn't appear anywhere, in any version, past or present. Neither can it find any reference to __in_ecount, other than its definition as #define __in_ecount(size) (evaluating to an empty string), in specstrings.h.

    Is some client code, perhaps, (mis)using __in_ecode in a fashion which is not consistent with that definition?

     
  • Keith Marshall

    Keith Marshall - 2016-02-12
    • status: assigned --> pending
    • Resolution: later --> limbo
    • Category: Feature_in_WSL_4.1 --> Waiting_User_Response
     
  • Keith Marshall

    Keith Marshall - 2016-02-12

    As I've stated previously, I can see no evidence that this problem will arise with any version of the genuine APIs, as distributed by MinGW.org. Unless someone can post a SSCCE to confirm otherwise, I must conclude that those who are experiencing this issue are using some renegade 3rd party derivative of our APIs, (which, of course, we cannot be expected to support).

    If such a SSCCE isn't attached by the end of this month (Feb-2016), then I will close this ticket as "invalid", (because it doesn't appear to relate to any code which we distribute).

     

Log in to post a comment.