[winapi] [thread] Conflicting declarations on MinGW

older
[qvm] deduce_xx traits wouldn't...

Antony Polukhin

31 Dec 2015 31 Dec '15

10:40 a.m.

Hi, Some of the Boost.DLL tests produce following warnings: ../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()' Andrey, Vicente what's the best way to resolve such issues? -- Best regards, Antony Polukhin

Show replies by date

Andrey Semashev

31 Dec 31 Dec

10:59 a.m.

On 2015-12-31 13:40, Antony Polukhin wrote:

...

Hi,

Some of the Boost.DLL tests produce following warnings:

../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()'

Andrey, Vicente what's the best way to resolve such issues?

IMO, Boost.Thread needs to be ported to Boost.WinAPI. boost/thread/win32/thread_primitives.hpp declares extern "C" functions in its own namespace, while Windows SDK and Boost.WinAPI declare them in the global namespace. This is forbidden by the standard since the functions are considered distinct by the language but mangle to the same name. As an immediate solution you could define BOOST_USE_WINDOWS_H when building your code. Both libraries should use Windows SDK directly then.

Agustín K-ballo Bergé

12:47 p.m.

On 12/31/2015 7:59 AM, Andrey Semashev wrote:

...

On 2015-12-31 13:40, Antony Polukhin wrote:

...
Hi,

Some of the Boost.DLL tests produce following warnings:

../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()'

Andrey, Vicente what's the best way to resolve such issues?

IMO, Boost.Thread needs to be ported to Boost.WinAPI. boost/thread/win32/thread_primitives.hpp declares extern "C" functions in its own namespace, while Windows SDK and Boost.WinAPI declare them in the global namespace.

Declaring extern "C" functions in a namespace is perfectly fine. Frankly, I'm surprised and disappointed that Boost.WinAPI does not do it, and that it will litter the global namespace instead.

...

This is forbidden by the standard since the functions are considered distinct by the language but mangle to the same name.

The standard is perfectly clear in that both declarations refer to the same function (7.5 [dcl.link]/6), and there's no potential for ambiguity since they both denote the same entity. The warning comes from the use of different arguments and/or return type in the declarations. I'm guessing Boost.WinAPI is using winapi's typed handles, while we can see in the warning message that Boost.Thread uses just `void`. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

Andrey Semashev

2:32 p.m.

On 2015-12-31 15:47, Agustín K-ballo Bergé wrote:

...

On 12/31/2015 7:59 AM, Andrey Semashev wrote:

...
On 2015-12-31 13:40, Antony Polukhin wrote:

...
Hi,

Some of the Boost.DLL tests produce following warnings:

../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()'

Andrey, Vicente what's the best way to resolve such issues?

IMO, Boost.Thread needs to be ported to Boost.WinAPI. boost/thread/win32/thread_primitives.hpp declares extern "C" functions in its own namespace, while Windows SDK and Boost.WinAPI declare them in the global namespace.

Declaring extern "C" functions in a namespace is perfectly fine. Frankly, I'm surprised and disappointed that Boost.WinAPI does not do it, and that it will litter the global namespace instead.

It did, until it caused problems with clang - similar to the ones quoted by Antony above.

...

The warning comes from the use of different arguments and/or return type in the declarations. I'm guessing Boost.WinAPI is using winapi's typed handles, while we can see in the warning message that Boost.Thread uses just `void`.

The types in Boost.WinAPI are the same as the ones in Windows SDK (sans the typedefs, which I assume are not essential). There are no structs in the mentioned functions, and as far as I can see the types in Boost.Thread are also the same. So the only difference seems to be the namespace in which the functions are declared.

Andrey Semashev

2:44 p.m.

On 2015-12-31 17:32, Andrey Semashev wrote:

...

On 2015-12-31 15:47, Agustín K-ballo Bergé wrote:

...
On 12/31/2015 7:59 AM, Andrey Semashev wrote:

...
On 2015-12-31 13:40, Antony Polukhin wrote:

...
Hi,

Some of the Boost.DLL tests produce following warnings:

../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()'

Andrey, Vicente what's the best way to resolve such issues?

IMO, Boost.Thread needs to be ported to Boost.WinAPI. boost/thread/win32/thread_primitives.hpp declares extern "C" functions in its own namespace, while Windows SDK and Boost.WinAPI declare them in the global namespace.

Declaring extern "C" functions in a namespace is perfectly fine. Frankly, I'm surprised and disappointed that Boost.WinAPI does not do it, and that it will litter the global namespace instead.

It did, until it caused problems with clang - similar to the ones quoted by Antony above.

...
The warning comes from the use of different arguments and/or return type in the declarations. I'm guessing Boost.WinAPI is using winapi's typed handles, while we can see in the warning message that Boost.Thread uses just `void`.

The types in Boost.WinAPI are the same as the ones in Windows SDK (sans the typedefs, which I assume are not essential). There are no structs in the mentioned functions, and as far as I can see the types in Boost.Thread are also the same. So the only difference seems to be the namespace in which the functions are declared.

Oh, you meant HINSTANCE/HMODULE? Yes, you're right, this type may be diffrent, depending on whether STRICT is defined or not. In any case, I still think that porting Boost.Thread to Boost.WinAPI is the right solution. WinAPI is a mess, so let's keep this mess in one place.

Agustín K-ballo Bergé

2:59 p.m.

On 12/31/2015 11:44 AM, Andrey Semashev wrote:

...

In any case, I still think that porting Boost.Thread to Boost.WinAPI is the right solution. WinAPI is a mess, so let's keep this mess in one place.

I completely agree with this, and as this thread shows it's not a particularly easy task to get right. However, for Boost.Thread to start dumping stuff in the global namespace sounds like a regression to me. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

Rob Stewart

7:56 p.m.

On December 31, 2015 9:59:43 AM EST, "Agustín K-ballo Bergé" wrote:

...

However, for Boost.Thread to start dumping stuff in the global namespace sounds like a regression to me.

Doesn't using extern "C" mean the name is in the global namespace? Did I miss something? IOW, putting the declaration in a namespace or not has no effect on the generated symbols or name lookup. ___ Rob (Sent from my portable computation engine)

Agustín K-ballo Bergé

8:07 p.m.

On 12/31/2015 4:56 PM, Rob Stewart wrote:

...

On December 31, 2015 9:59:43 AM EST, "Agustín K-ballo Bergé" wrote:

...
However, for Boost.Thread to start dumping stuff in the global namespace sounds like a regression to me.

Doesn't using extern "C" mean the name is in the global namespace? Did I miss something?

IOW, putting the declaration in a namespace or not has no effect on the generated symbols or name lookup.

No, extern "C" affects linking, not name lookup. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

Andrey Semashev

8:12 p.m.

On 2015-12-31 22:56, Rob Stewart wrote:

...

On December 31, 2015 9:59:43 AM EST, "Agustín K-ballo Bergé" wrote:

...
However, for Boost.Thread to start dumping stuff in the global namespace sounds like a regression to me.

Doesn't using extern "C" mean the name is in the global namespace? Did I miss something?

IOW, putting the declaration in a namespace or not has no effect on the generated symbols or name lookup.

Name lookup is not affected by the linkage type, so you still have to qualify the call to extern "C" functions with the namespace(s) they're declared in. The linkage type may affect name mangling and calling conventions, but that is almost outside of the scope of the standard.

Rob Stewart

10:45 p.m.

On December 31, 2015 3:12:35 PM EST, Andrey Semashev wrote:

...

...
On December 31, 2015 9:59:43 AM EST, "Agustín K-ballo Bergé" wrote:

...
However, for Boost.Thread to start dumping stuff in the global namespace sounds like a regression to me.

Doesn't using extern "C" mean the name is in the global namespace? Did I miss something?

IOW, putting the declaration in a namespace or not has no effect on

On 2015-12-31 22:56, Rob Stewart wrote: the generated symbols or name lookup.

Name lookup is not affected by the linkage type, so you still have to qualify the call to extern "C" functions with the namespace(s) they're

declared in. The linkage type may affect name mangling and calling conventions, but that is almost outside of the scope of the standard.

http://stackoverflow.com/a/1041880 ___ Rob (Sent from my portable computation engine)

Agustín K-ballo Bergé

2:50 p.m.

On 12/31/2015 11:32 AM, Andrey Semashev wrote:

...

On 2015-12-31 15:47, Agustín K-ballo Bergé wrote:

...
On 12/31/2015 7:59 AM, Andrey Semashev wrote:

...
On 2015-12-31 13:40, Antony Polukhin wrote:

...
Hi,

Some of the Boost.DLL tests produce following warnings:

../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()'

Andrey, Vicente what's the best way to resolve such issues?

IMO, Boost.Thread needs to be ported to Boost.WinAPI. boost/thread/win32/thread_primitives.hpp declares extern "C" functions in its own namespace, while Windows SDK and Boost.WinAPI declare them in the global namespace.

Declaring extern "C" functions in a namespace is perfectly fine. Frankly, I'm surprised and disappointed that Boost.WinAPI does not do it, and that it will litter the global namespace instead.

It did, until it caused problems with clang - similar to the ones quoted by Antony above.

I made a little experiment to try to understand what you are saying: http://melpon.org/wandbox/permlink/ncVqjnyzuTlepx2F As you can see, this reproduces both the gcc warning and a clang error, but only for the conflicting declaration of `bar`. The difference in namespace for `foo` is irrelevant, as the standard says.

...

...
The warning comes from the use of different arguments and/or return type in the declarations. I'm guessing Boost.WinAPI is using winapi's typed handles, while we can see in the warning message that Boost.Thread uses just `void`.

The types in Boost.WinAPI are the same as the ones in Windows SDK (sans the typedefs, which I assume are not essential). There are no structs in the mentioned functions, and as far as I can see the types in Boost.Thread are also the same. So the only difference seems to be the namespace in which the functions are declared.

The Windows SDK uses dummy structs to bring some sort of type safety to the otherwise untyped handles. As you can see in the warning, Boost.Thread is using plain `void*` instead, probably coming from here https://github.com/boostorg/thread/blob/develop/include/boost/thread/win32/t... That is the source of the problem, not the namespaces in which the extern "C" functions are declared. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

Andrey Semashev

2:58 p.m.

On 2015-12-31 17:50, Agustín K-ballo Bergé wrote:

...

On 12/31/2015 11:32 AM, Andrey Semashev wrote:

...
On 2015-12-31 15:47, Agustín K-ballo Bergé wrote:

...
On 12/31/2015 7:59 AM, Andrey Semashev wrote:

...
On 2015-12-31 13:40, Antony Polukhin wrote:

...
Hi,

Some of the Boost.DLL tests produce following warnings:

../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()'

Andrey, Vicente what's the best way to resolve such issues?

IMO, Boost.Thread needs to be ported to Boost.WinAPI. boost/thread/win32/thread_primitives.hpp declares extern "C" functions in its own namespace, while Windows SDK and Boost.WinAPI declare them in the global namespace.

Declaring extern "C" functions in a namespace is perfectly fine. Frankly, I'm surprised and disappointed that Boost.WinAPI does not do it, and that it will litter the global namespace instead.

It did, until it caused problems with clang - similar to the ones quoted by Antony above.

I made a little experiment to try to understand what you are saying:

http://melpon.org/wandbox/permlink/ncVqjnyzuTlepx2F

As you can see, this reproduces both the gcc warning and a clang error, but only for the conflicting declaration of `bar`. The difference in namespace for `foo` is irrelevant, as the standard says.

Ok, but it doesn't really matter. Boost.WinAPI does re-define some of the Windows SDK structs, so it has to duplicate affected functions as well. The declarations in the global namespace are mirroring the real declarations in Windows SDK; these names are considered reserved anyway because including Windows SDK headers may result in these names being used. boost::detail::winapi::* symbols are considered the interface for Boost libraries.

Vicente J. Botet Escriba

1 Jan 1 Jan

8:48 p.m.

Le 31/12/2015 11:40, Antony Polukhin a écrit :

...

Hi,

Some of the Boost.DLL tests produce following warnings:

../boost/thread/win32/thread_primitives.hpp:175:83: warning: declaration of 'void* boost::detail::win32::GetModuleHandleA(const char*)' with C language linkage ../boost/detail/winapi/dll.hpp:47:1: warning: conflicts with previous declaration 'HINSTANCE__* GetModuleHandleA(boost::detail::winapi::LPCSTR_)' ../boost/thread/win32/thread_primitives.hpp:195:94: warning: declaration of 'int (__attribute__((__stdcall__)) * boost::detail::win32::GetProcAddress(void*, const char*))()' with C language linkage ../boost/detail/winapi/dll.hpp:82:1: warning: conflicts with previous declaration 'int (__attribute__((__stdcall__)) * GetProcAddress(boost::detail::winapi::HMODULE_, boost::detail::winapi::LPCSTR_))()'

Andrey, Vicente what's the best way to resolve such issues?

Hi, I have no access to a Windows machine. Any patch is welcome. Vicente

3236

Age (days ago)

3237

Last active (days ago)

List overview

Download

12 comments

5 participants

participants (5)

Agustín K-ballo Bergé
Andrey Semashev
Antony Polukhin
Rob Stewart
Vicente J. Botet Escriba