Re: [Mingw-w64-public] Tapi.h and libtapi32
Am 7/11/2012 11:39 AM, Ozkan Sezer wrote: Pushed lib32/tapi32.def update to trunk at rev.5204, to stable/v1.x at rev. 5205 and to stable/v2.x at rev. 5206, so linkage should work fine now. -- O.S. Am 7/11/2012 1:21 PM, Ozkan Sezer wrote: trunk: r5212, stable/v1.x: r5213, stable/v2.x: r5214. -- O.S. Whoa, whoa - bug fixing with the speed of light! I feel space bending around me... :) Great job, thanks! Regards, Peter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Tapi.h and libtapi32
On 7/11/12, Peter Schaefer peter.schae...@gmx.de wrote: Hi! I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an application using TAPI, however tapi.h cannot be compiled: c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2074:107: error: declaration of C function 'LONG lineAddProviderW(LPCWSTR, HWND, LPDWORD)' conflicts with c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2072:1: error: previous declaration 'LONG lineAddProviderW(LPCSTR, HWND, LPDWORD)' here This is because the whole list of #define yadayada __MINGW_NAME_AW(yadayada) is located *before* the function declarations and the expansion of the __MINGW_NAME_AW macro leads to name clashes. This can be fixed by moving the macro block *after* the function declarations (see patch below). However, this problem solved just ends up with linker errors since it seems that many functions declared are not in the import lib libtapi32.a: C:\Code\tapiLine.cpp:24: undefined reference to `lineInitializeExW@28' C:\Code\tapiLine.cpp:38: undefined reference to `lineGetDevCapsW@20' I have a patch to update lib32/tapi32.def, so the linkage errors will go away. As for the header, others would review better. The program must be compiled with -D_UNICODE -DUNICODE. I'm now going to use the LoadLibrary-way and resolve the symbols dynamically, but wanted to have this issue reported. If i can help in some way, let me know. Regards, Peter - PATCH 8-8--8---SNIP-- *** tapi_1.h Fri Jun 15 17:45:13 2012 --- tapi_2.h Tue Jul 10 23:54:26 2012 *** *** 2007,2072 DWORD dwStringOffset; } VARSTRING,*LPVARSTRING; - #define lineAddProvider __MINGW_NAME_AW(lineAddProvider) - #define lineBlindTransfer __MINGW_NAME_AW(lineBlindTransfer) - #define lineConfigDialog __MINGW_NAME_AW(lineConfigDialog) - #define lineConfigDialogEdit __MINGW_NAME_AW(lineConfigDialogEdit) - #define lineCreateAgent __MINGW_NAME_AW(lineCreateAgent) - #define lineCreateAgent __MINGW_NAME_AW(lineCreateAgent) - #define lineDial __MINGW_NAME_AW(lineDial) - #define lineForward __MINGW_NAME_AW(lineForward) - #define lineGatherDigits __MINGW_NAME_AW(lineGatherDigits) - #define lineGenerateDigits __MINGW_NAME_AW(lineGenerateDigits) - #define lineGetAddressCaps __MINGW_NAME_AW(lineGetAddressCaps) - #define lineGetAddressID __MINGW_NAME_AW(lineGetAddressID) - #define lineGetAddressStatus __MINGW_NAME_AW(lineGetAddressStatus) - #define lineGetAgentActivityList __MINGW_NAME_AW(lineGetAgentActivityList) - #define lineGetAgentCaps __MINGW_NAME_AW(lineGetAgentCaps) - #define lineGetAgentGroupList __MINGW_NAME_AW(lineGetAgentGroupList) - #define lineGetAgentStatus __MINGW_NAME_AW(lineGetAgentStatus) - #define lineGetAppPriority __MINGW_NAME_AW(lineGetAppPriority) - #define lineGetCallInfo __MINGW_NAME_AW(lineGetCallInfo) - #define lineGetCountry __MINGW_NAME_AW(lineGetCountry) - #define lineGetDevCaps __MINGW_NAME_AW(lineGetDevCaps) - #define lineGetDevConfig __MINGW_NAME_AW(lineGetDevConfig) - #define lineGetGroupList __MINGW_NAME_AW(lineGetGroupList) - #define lineGetIcon __MINGW_NAME_AW(lineGetIcon) - #define lineGetID __MINGW_NAME_AW(lineGetID) - #define lineGetDevStatus __MINGW_NAME_AW(lineGetDevStatus) - #define lineGetProviderList __MINGW_NAME_AW(lineGetProviderList) - #define lineGetQueueList __MINGW_NAME_AW(lineGetQueueList) - #define lineGetRequest __MINGW_NAME_AW(lineGetRequest) - #define lineGetTranslateCaps __MINGW_NAME_AW(lineGetTranslateCaps) - #define lineHandoff __MINGW_NAME_AW(lineHandoff) - #define lineInitializeEx __MINGW_NAME_AW(lineInitializeEx) - #define lineMakeCall __MINGW_NAME_AW(lineMakeCall) - #define lineOpen __MINGW_NAME_AW(lineOpen) - #define linePark __MINGW_NAME_AW(linePark) - #define linePickup __MINGW_NAME_AW(linePickup) - #define linePrepareAddToConference __MINGW_NAME_AW(linePrepareAddToConference) - #define lineRedirect __MINGW_NAME_AW(lineRedirect) - #define lineSetAppPriority __MINGW_NAME_AW(lineSetAppPriority) - #define lineSetDevConfig __MINGW_NAME_AW(lineSetDevConfig) - #define lineSetTollList __MINGW_NAME_AW(lineSetTollList) - #define lineSetupConference __MINGW_NAME_AW(lineSetupConference) - #define lineSetupTransfer __MINGW_NAME_AW(lineSetupTransfer) - #define lineTranslateAddress __MINGW_NAME_AW(lineTranslateAddress) - #define lineTranslateDialog __MINGW_NAME_AW(lineTranslateDialog) - #define lineUnpark __MINGW_NAME_AW(lineUnpark) - - #define phoneConfigDialog __MINGW_NAME_AW(phoneConfigDialog) - #define phoneGetButtonInfo __MINGW_NAME_AW(phoneGetButtonInfo) - #define phoneGetDevCaps __MINGW_NAME_AW(phoneGetDevCaps) - #define phoneGetIcon __MINGW_NAME_AW(phoneGetIcon) - #define phoneGetID __MINGW_NAME_AW(phoneGetID) - #define phoneGetStatus __MINGW_NAME_AW(phoneGetStatus) - #define phoneInitializeEx
Re: [Mingw-w64-public] Tapi.h and libtapi32
2012/7/11 JonY jo...@users.sourceforge.net: On 7/11/2012 14:51, Peter Schaefer wrote: Hi! I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an application using TAPI, however tapi.h cannot be compiled: c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2074:107: error: declaration of C function 'LONG lineAddProviderW(LPCWSTR, HWND, LPDWORD)' conflicts with c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2072:1: error: previous declaration 'LONG lineAddProviderW(LPCSTR, HWND, LPDWORD)' here This is because the whole list of #define yadayada __MINGW_NAME_AW(yadayada) is located *before* the function declarations and the expansion of the __MINGW_NAME_AW macro leads to name clashes. No, it is fine to have those macros before. sure, I have no objections about this. Cheers, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Tapi.h and libtapi32
On 07/11/12 11:14, JonY wrote: On 7/11/2012 14:51, Peter Schaefer wrote: Hi! I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an application using TAPI, however tapi.h cannot be compiled: c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2074:107: error: declaration of C function 'LONG lineAddProviderW(LPCWSTR, HWND, LPDWORD)' conflicts with c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2072:1: error: previous declaration 'LONG lineAddProviderW(LPCSTR, HWND, LPDWORD)' here This is because the whole list of #define yadayada __MINGW_NAME_AW(yadayada) is located *before* the function declarations and the expansion of the __MINGW_NAME_AW macro leads to name clashes. No, it is fine to have those macros before. MSDN lists lineAddProviderW and lineAddProviderA, but not lineAddProvider, so IMHO the proper fix is to remove non-suffixed lineAddProvider. The non-suffixed ones will never be reached anyway if those macros are in effect. MSVC does have an unprefixed declaration (although I must admit that someone needs to try hard to use it, because macro will override its callers), so the patch is right IMO. Jacek -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Tapi.h and libtapi32
On 7/11/12, Kai Tietz ktiet...@googlemail.com wrote: 2012/7/11 JonY jo...@users.sourceforge.net: On 7/11/2012 14:51, Peter Schaefer wrote: Hi! I'm using the recent rubenvb-gcc-4.7.1 release and tried to compile an application using TAPI, however tapi.h cannot be compiled: c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2074:107: error: declaration of C function 'LONG lineAddProviderW(LPCWSTR, HWND, LPDWORD)' conflicts with c:\mingw32\bin\../lib/gcc/i686-w64-mingw32/4.7.1/../../../../i686-w64-mingw32/include/tapi.h:2072:1: error: previous declaration 'LONG lineAddProviderW(LPCSTR, HWND, LPDWORD)' here This is because the whole list of #define yadayada __MINGW_NAME_AW(yadayada) is located *before* the function declarations and the expansion of the __MINGW_NAME_AW macro leads to name clashes. No, it is fine to have those macros before. sure, I have no objections about this. Cheers, Kai Ok looked at the header and reproduced the error. The specific problem with tapi.h and the unicode macros is that some functions have their xxxA/xxxW variants _along_ with the ones without them: e.g. we have lineUnpark() _and_ lineUnparkA() and lineUnparkW() This is because the developer mayl target an older tapi version as is bare minimum, hence the TAPI_CURRENT_VERSION macro: If unicode: the name is supposed to be defined to as the W variant, if not: only if TAPI_CURRENT_VERSION=0x0x0002 then it is to be defined as the A variant, else left as is, i.e. lineUnpark() itself will be used and linked. In any case, the unicode macros must really be moved after the prototypes. Pushed lib32/tapi32.def update to trunk at rev.5204, to stable/v1.x at rev. 5205 and to stable/v2.x at rev. 5206, so linkage should work fine now. -- O.S. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Tapi.h and libtapi32
On 7/11/2012 17:39, Ozkan Sezer wrote: Ok looked at the header and reproduced the error. The specific problem with tapi.h and the unicode macros is that some functions have their xxxA/xxxW variants _along_ with the ones without them: e.g. we have lineUnpark() _and_ lineUnparkA() and lineUnparkW() This is because the developer mayl target an older tapi version as is bare minimum, hence the TAPI_CURRENT_VERSION macro: If unicode: the name is supposed to be defined to as the W variant, if not: only if TAPI_CURRENT_VERSION=0x0x0002 then it is to be defined as the A variant, else left as is, i.e. lineUnpark() itself will be used and linked. In any case, the unicode macros must really be moved after the prototypes. OK, good point, do you want to move it or should I? Pushed lib32/tapi32.def update to trunk at rev.5204, to stable/v1.x at rev. 5205 and to stable/v2.x at rev. 5206, so linkage should work fine now. Thanks. signature.asc Description: OpenPGP digital signature -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Tapi.h and libtapi32
On 7/11/12, JonY jo...@users.sourceforge.net wrote: On 7/11/2012 17:39, Ozkan Sezer wrote: Ok looked at the header and reproduced the error. The specific problem with tapi.h and the unicode macros is that some functions have their xxxA/xxxW variants _along_ with the ones without them: e.g. we have lineUnpark() _and_ lineUnparkA() and lineUnparkW() This is because the developer mayl target an older tapi version as is bare minimum, hence the TAPI_CURRENT_VERSION macro: If unicode: the name is supposed to be defined to as the W variant, if not: only if TAPI_CURRENT_VERSION=0x0x0002 then it is to be defined as the A variant, else left as is, i.e. lineUnpark() itself will be used and linked. In any case, the unicode macros must really be moved after the prototypes. OK, good point, do you want to move it or should I? I made a modified patch, respecting the version macro. See attached: - tapi-funcs.txt: list of problematic funcs revealed when including tapi.h and compiling with UNICODE defined - v1x.diff : patch against stable/v1.x - v2x-trunk.diff : patch against stable/v2.x and trunk Is this correct and OK to apply? -- O.S. lineAddProvider lineBlindTransfer lineConfigDialog lineConfigDialogEdit lineDial lineGatherDigits lineGenerateDigits lineGetAddressID lineGetAppPriority lineGetDevConfig lineGetIcon lineGetID lineHandoff lineMakeCall linePark linePickup lineRedirect lineSetAppPriority lineSetDevConfig lineSetTollList lineTranslateAddress lineTranslateDialog lineUnpark phoneConfigDialog phoneGetIcon phoneGetID tapiGetLocationInfo tapiRequestMakeCall tapiRequestMediaCall v1x.diff Description: Binary data v2x-trunk.diff Description: Binary data -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Tapi.h and libtapi32
Hi Ozkan, patches are looking ok to me. Please go ahead. Thanks, Kai 2012/7/11 Ozkan Sezer seze...@gmail.com: On 7/11/12, JonY jo...@users.sourceforge.net wrote: On 7/11/2012 17:39, Ozkan Sezer wrote: Ok looked at the header and reproduced the error. The specific problem with tapi.h and the unicode macros is that some functions have their xxxA/xxxW variants _along_ with the ones without them: e.g. we have lineUnpark() _and_ lineUnparkA() and lineUnparkW() This is because the developer mayl target an older tapi version as is bare minimum, hence the TAPI_CURRENT_VERSION macro: If unicode: the name is supposed to be defined to as the W variant, if not: only if TAPI_CURRENT_VERSION=0x0x0002 then it is to be defined as the A variant, else left as is, i.e. lineUnpark() itself will be used and linked. In any case, the unicode macros must really be moved after the prototypes. OK, good point, do you want to move it or should I? I made a modified patch, respecting the version macro. See attached: - tapi-funcs.txt: list of problematic funcs revealed when including tapi.h and compiling with UNICODE defined - v1x.diff : patch against stable/v1.x - v2x-trunk.diff : patch against stable/v2.x and trunk Is this correct and OK to apply? -- O.S. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Tapi.h and libtapi32
On 7/11/12, Kai Tietz ktiet...@googlemail.com wrote: Hi Ozkan, patches are looking ok to me. Please go ahead. Thanks, Kai trunk: r5212, stable/v1.x: r5213, stable/v2.x: r5214. -- O.S. 2012/7/11 Ozkan Sezer seze...@gmail.com: On 7/11/12, JonY jo...@users.sourceforge.net wrote: On 7/11/2012 17:39, Ozkan Sezer wrote: Ok looked at the header and reproduced the error. The specific problem with tapi.h and the unicode macros is that some functions have their xxxA/xxxW variants _along_ with the ones without them: e.g. we have lineUnpark() _and_ lineUnparkA() and lineUnparkW() This is because the developer mayl target an older tapi version as is bare minimum, hence the TAPI_CURRENT_VERSION macro: If unicode: the name is supposed to be defined to as the W variant, if not: only if TAPI_CURRENT_VERSION=0x0x0002 then it is to be defined as the A variant, else left as is, i.e. lineUnpark() itself will be used and linked. In any case, the unicode macros must really be moved after the prototypes. OK, good point, do you want to move it or should I? I made a modified patch, respecting the version macro. See attached: - tapi-funcs.txt: list of problematic funcs revealed when including tapi.h and compiling with UNICODE defined - v1x.diff : patch against stable/v1.x - v2x-trunk.diff : patch against stable/v2.x and trunk Is this correct and OK to apply? -- O.S. -- | (\_/) This is Bunny. Copy and paste | (='.'=) Bunny into your signature to help | ()_() him gain world domination -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
