[test] Still having issues
I'm still having a lot of issues with the latest Boost.Test not building: On Win32 with Intel's 11.1 and 12.1 compilers I see: ..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler; And on Ubuntu Linux with gcc I see: gcc.compile.c++ /home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o In file included from ../../../libs/test/src/unit_test_main.cpp:16: ../../../boost/test/impl/unit_test_main.ipp: In function 'int boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int, char**), int, char**)': ../../../boost/test/impl/unit_test_main.ipp:97: error: 'getchar' is not a member of 'std' "/usr/local/gcc/4.4.3/bin/g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -pedantic -g -DBOOST_ALL_NO_LIB=1 -I"../../.." -c -o "/home/john/bin/boost/bin.v2/libs/test/build/gcc-4.4.3/debug/link-static/unit_test_main.o" "../../../libs/test/src/unit_test_main.cpp" Probably a missing <cstdio> include? John.
John Maddock <boost.regex <at> virgin.net> writes:
I'm still having a lot of issues with the latest Boost.Test not building:
On Win32 with Intel's 11.1 and 12.1 compilers I see:
..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler;
This was not changed. Is this new compiler?
And on Ubuntu Linux with gcc I see:
Probably a missing <cstdio> include?
This is resolved in trunk yesterday. Gennadiy
I'm still having a lot of issues with the latest Boost.Test not building:
On Win32 with Intel's 11.1 and 12.1 compilers I see:
..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler;
This was not changed. Is this new compiler?
12.1 is, but the same issue occurs on 11.1 which has been around for ages.
And on Ubuntu Linux with gcc I see:
Probably a missing <cstdio> include?
This is resolved in trunk yesterday.
Cheers, John.
John Maddock <boost.regex <at> virgin.net> writes:
I'm still having a lot of issues with the latest Boost.Test not building:
On Win32 with Intel's 11.1 and 12.1 compilers I see:
..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler;
This was not changed. Is this new compiler?
12.1 is, but the same issue occurs on 11.1 which has been around for ages.
Well, in might have never worked or something changed outside of Boost.Test cause this line was there since 2007 and nothing relevant change in a vicinity since. Gennadiy P.S. If you (or someone else) know what needs to be done to fix this I am open to patches
On 10/12/2011 11:21 AM, Gennadiy Rozental wrote:
John Maddock<boost.regex<at> virgin.net> writes:
I'm still having a lot of issues with the latest Boost.Test not building:
On Win32 with Intel's 11.1 and 12.1 compilers I see:
..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler;
This was not changed. Is this new compiler?
12.1 is, but the same issue occurs on 11.1 which has been around for ages.
Well, in might have never worked or something changed outside of Boost.Test cause this line was there since 2007 and nothing relevant change in a vicinity since.
Gennadiy
P.S. If you (or someone else) know what needs to be done to fix this I am open to patches
Just rename _invalid_parameter_handler to something else. As the error message says, that name is already defined in some Visual Studio headers. Names that start with an underscore in the global namespace are reserved by the implementation.
Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes:
Just rename _invalid_parameter_handler to something else. As the error message says, that name is already defined in some Visual Studio headers.
Really!? Such a simple solution. How come I never figured it out.
Names that start with an underscore in the global namespace are reserved by the implementation.
Maybe you should first look why this line was put there in a first place. Genandiy
On 13/10/2011 04:04, Gennadiy Rozental wrote:
Mathias Gaunard<mathias.gaunard<at> ens-lyon.org> writes:
Just rename _invalid_parameter_handler to something else. As the error message says, that name is already defined in some Visual Studio headers.
Really!? Such a simple solution. How come I never figured it out.
Names that start with an underscore in the global namespace are reserved by the implementation.
Maybe you should first look why this line was put there in a first place.
I don't care why your library does this, it is not my problem. The only thing I notice is that Boost is regularly impeded and held back by your library, and that it takes several iterations and several weeks to get you to revert things to how they were before. This is a major annoyance. You say you don't understand the error message, I tell you what it means. Clearly if something is already defined in a header, you can't redefine it. It could be that your header only works if it's included *before* stdlib.h. In which case, that's very fragile.
Mathias Gaunard <mathias.gaunard <at> ens-lyon.org> writes:
On 13/10/2011 04:04, Gennadiy Rozental wrote:
Mathias Gaunard<mathias.gaunard<at> ens-lyon.org> writes:
Just rename _invalid_parameter_handler to something else. As the error message says, that name is already defined in some Visual Studio headers.
Really!? Such a simple solution. How come I never figured it out.
Names that start with an underscore in the global namespace are reserved by the implementation.
Maybe you should first look why this line was put there in a first place.
I don't care why your library does this, it is not my problem.
Why are you commenting in this thread in this case?
This is a major annoyance.
I on my side might be annoyed that you comment without even trying to understand what the problem is.
You say you don't understand the error message, I tell you what it means. Clearly if something is already defined in a header, you can't redefine it.
You on the other hand do not know what you are talking about. This line was added specifically because this symbols was *absent* in msvc headers (some version of msvc specifically). It can't be anything else. It should be this particular symbol. Named in this particular way. Why this hack get's applied to this platform/compiler combination - that's the question. If you have anything to comment on actual issue feel free to weight in.
It could be that your header only works if it's included *before* stdlib.h. In which case, that's very fragile.
You did not even bothered to see that this is inside of implementation, not in header. Gennadiy
Chaps, please tone it down. Taking out your frustration on the list in public serves no purpose. Regards, John.
On 13/10/2011 04:04, Gennadiy Rozental wrote:
Mathias Gaunard<mathias.gaunard<at> ens-lyon.org> writes:
Just rename _invalid_parameter_handler to something else. As the error message says, that name is already defined in some Visual Studio headers.
Really!? Such a simple solution. How come I never figured it out.
Names that start with an underscore in the global namespace are reserved by the implementation.
Maybe you should first look why this line was put there in a first place.
I don't care why your library does this, it is not my problem.
Why are you commenting in this thread in this case?
This is a major annoyance.
I on my side might be annoyed that you comment without even trying to understand what the problem is.
You say you don't understand the error message, I tell you what it means. Clearly if something is already defined in a header, you can't redefine it.
You on the other hand do not know what you are talking about. This line was added specifically because this symbols was *absent* in msvc headers (some version of msvc specifically). It can't be anything else. It should be this particular symbol. Named in this particular way. Why this hack get's applied to this platform/compiler combination - that's the question. If you have anything to comment on actual issue feel free to weight in.
It could be that your header only works if it's included *before* stdlib.h. In which case, that's very fragile.
You did not even bothered to see that this is inside of implementation, not in header.
Gennadiy
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I'm still having a lot of issues with the latest Boost.Test not building:
On Win32 with Intel's 11.1 and 12.1 compilers I see:
..\..\..\boost/test/impl/execution_monitor.ipp(104): error: invalid redeclaration of type name "_invalid_parameter_handler" (declared at line 228 of "C:\Program Files\Microsoft Visual Studio 10.0\VC\INCLUDE\stdlib.h") typedef void* _invalid_parameter_handler;
This was not changed. Is this new compiler?
12.1 is, but the same issue occurs on 11.1 which has been around for ages.
Well, in might have never worked or something changed outside of Boost.Test cause this line was there since 2007 and nothing relevant change in a vicinity since.
Gennadiy
P.S. If you (or someone else) know what needs to be done to fix this I am open to patches
Here's the problem: In VC10, the declaration in stdlib.h is: typedef void (__cdecl *_invalid_parameter_handler)(const wchar_t *, const wchar_t *, const wchar_t *, unsigned int, uintptr_t); But then you redeclare as: typedef void* _invalid_parameter_handler; Now if the compiler is *really* VC10, then your workaround code isn't activated and everything is OK, but when the compiler is Intel sitting on top of MSVC, BOOST_MSVC is rightly not defined, so: # if (!BOOST_WORKAROUND(BOOST_MSVC, >= 1400 ) && \ !defined(BOOST_COMO)) || defined(UNDER_CE) Evaluates to true, and the problematic workaround occurs. Furthermore, I've just checked the headers on my HD and VC8, 9 and 10 all do define that symbol in stdlib.h in exactly the same way: #if !defined(_M_CEE_PURE) /* a invalid_arg handler procedure. */ typedef void (__cdecl *_invalid_parameter_handler)(const wchar_t *, const wchar_t *, const wchar_t *, unsigned int, uintptr_t); /* establishes a invalid_arg handler for the process */ _CRTIMP _invalid_parameter_handler __cdecl _set_invalid_parameter_handler(_In_opt_ _invalid_parameter_handler _Handler); _CRTIMP _invalid_parameter_handler __cdecl _get_invalid_parameter_handler(void); #endif So I suggest that: * You change the definition of _invalid_parameter_handler to the correct one, and, * Use _MSC_VER in place of BOOST_MSVC in the pp-test: # if (!BOOST_WORKAROUND(_MSC_VER, >= 1400 ) && \ !defined(BOOST_COMO)) || defined(UNDER_CE) John.
John Maddock <boost.regex <at> virgin.net> writes:
Now if the compiler is *really* VC10, then your workaround code isn't activated and everything is OK, but when the compiler is Intel sitting on top of MSVC, BOOST_MSVC is rightly not defined, so:
Is there any chance this was changed recently?
Furthermore, I've just checked the headers on my HD and VC8, 9 and 10 all do define that symbol in stdlib.h in exactly the same way:
Would that be the case, VC8 and VC9 showed up the same failures we observe with Intel, since the workaround is enabled for these compilers. And this is not the case. I do not remember all the details, but I believe the symbol only defined under some conditions we do not meet.
So I suggest that:
* You change the definition of _invalid_parameter_handler to the correct one, and,
This is not necessary and indeed may not be possible. I am not sure the type was always defined the same way on all platforms this workaround is intended to work on. In any case this is just a stop gap. Empty function right below the typedef does not care about the real type
* Use _MSC_VER in place of BOOST_MSVC in the pp-test:
# if (!BOOST_WORKAROUND(_MSC_VER, >= 1400 ) && \ !defined(BOOST_COMO)) || defined(UNDER_CE)
And _MSC_VER is defined for Intel toolset, right? Yes. I think this is the right move. At some point there was push to use BOOST_MSVC consistently instead of _MSC_VER, but not in this case apparently. Gennadiy
Now if the compiler is *really* VC10, then your workaround code isn't activated and everything is OK, but when the compiler is Intel sitting on top of MSVC, BOOST_MSVC is rightly not defined, so:
Is there any chance this was changed recently?
No it's always been that way: BOOST_MSVC indicates that the compiler is *really* msvc as opposed to some other compiler emulating it.
Furthermore, I've just checked the headers on my HD and VC8, 9 and 10 all do define that symbol in stdlib.h in exactly the same way:
Would that be the case, VC8 and VC9 showed up the same failures we observe with Intel, since the workaround is enabled for these compilers. And this is not the case. I do not remember all the details, but I believe the symbol only defined under some conditions we do not meet.
No, _MSC_VER == 1400 is VC8, so the workaround is only enabled for for VC7.1 and earlier. John.
Gennadiy Rozental <rogeeff <at> gmail.com> writes:
* Use _MSC_VER in place of BOOST_MSVC in the pp-test:
# if (!BOOST_WORKAROUND(_MSC_VER, >= 1400 ) && \ !defined(BOOST_COMO)) || defined(UNDER_CE)
And _MSC_VER is defined for Intel toolset, right?
Yes. I think this is the right move. At some point there was push to use BOOST_MSVC consistently instead of _MSC_VER, but not in this case apparently.
Ok. I looked through the history. In my original version and all the way to Nov 7th 2010 it was correct and we were using _MSC_VER. On Nov 7 someone with svn name "wash" (who is this by the way), checked in the change which switched to BOOST_MSVC. The comment was this: "Clang hand-holding, mostly for issues caused by Clang defining GCC macros." How this has anything to do with clang or GCC beats me. So it seems this toolset was broken for almost a year and no one noticed. I am going to revert to _MSC_VER tonight. If Mr. wash wants these changes back, he can get a permission from Mr. Gaunard first. Regards, Gennadiy
participants (3)
-
Gennadiy Rozental -
John Maddock -
Mathias Gaunard