Useless failures reports/broken testers

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Useless failures reports/broken testers

Gennadiy Rozental-2
I've checked in some iffy code into Boost.Test and impatiently waiting
for regression results to appear here:

http://www.boost.org/development/tests/trunk/developer/test.html

to fix all regressions. What I see now is a bit unsettling (a lot
actually ;(). Number (majority) of testing setups/regression reports are
useless:

* Sandia-darwin-intel-11.0

Reports failure, but fail link leads to the message:

dyld: Library not loaded: libintlc.dylib
   Referenced from:
/private/tmp/kbelco/boost/results/boost/bin.v2/libs/test/test/algorithms_test.test/intel-darwin-11.0/debug/algorithms_test
   Reason: Incompatible library version: algorithms_test requires
version 1.0.0 or later, but libintlc.dylib provides version 0.0.0


* Sandia-darwin-intel-10.0
* HP-UX_ia64_gcc
* Sandia-pathscale
* Sandia-Linux-sun
* Sandia-intel-10.0
* CBIF-NetBSD-4.0-amd64
* CBIF-NetBSD-4.0-i386
* Sandia-sun in 2 incarnations (why are they not named differently BTW)
* siliconman (borland- 5.9.3)
* VeecoFTC (msvc-8.0~wm5~stlport5.1)

Reports failure in library build, but link to the library build output
shows success

* Huang-Vista-x64 (intel- vc9- win- 10.1_x86_64)

Reports failure in library build, but link to the library build output
shows nothing

* Huang-Vista-x64 (intel- vc9- win- 11.0_x86_64)

Reports failure in library build, but link to the library build output
shows:

     call "D:/Program Files
(x86)/Intel/Compiler/11.0/066/cpp/Bin/Intel64//iclvars.bat" > nul
icl
@"F:\bv64\results\boost\bin.v2\libs\test\build\intel-vc9-win-11.0_x86_64\debug\address-model-64\threading-multi\compiler_log_formatter.obj.rsp"


'"D:/Program Files
(x86)/Intel/Compiler/11.0/066/cpp/Bin/Intel64//iclvars.bat"' is not
recognized as an internal or external command,
operable program or batch file.
'icl' is not recognized as an internal or external command,
operable program or batch file.

* Huang-WinXP-x86_32

Reports failure in library build, but link to the library build output
shows:

     call "C:/Program
Files/Intel/Compiler/11.0/066/cpp/Bin/ia32//iclvars.bat" > nul
icl
@"G:\BoostRegressions\Head\results\boost\bin.v2\libs\test\build\intel-vc9-win-11.0\debug\threading-multi\compiler_log_formatter.obj.rsp"


'"C:/Program Files/Intel/Compiler/11.0/066/cpp/Bin/ia32//iclvars.bat"'
is not recognized as an internal or external command,
operable program or batch file.
'icl' is not recognized as an internal or external command,
operable program or batch file.

* siliconman (borland- 6.10.0)

Reports failure in library build, but link to the library build output
shows success with wierd content:

   "C:/BuildAgent/work/1ca5584b164649a6/cb2009/bin/bcc32" -j5 -g255 -q
-c -P -Ve -Vx -a8 -b- -v -Od -w-8080 -tWC -tWR -tWC -WM-
-DBOOST_ALL_NO_LIB=1 -I".."
-I"C:/BuildAgent/work/1ca5584b164649a6/cb2009/include/"
-o"C:\BuildAgent\work\1ca5584b164649a6\results\boost\bin.v2\libs\test\build\borland-6.10.0\debug\link-static\test_main.obj"
"..\libs\test\src\test_main.cpp"

..\libs\test\src\test_main.cpp:

test_main.cpp is not supposed to be build at all. I do not use test
execution monitor any more.

* steven_watanabe-como

Reports:

  call "C:/Program Files/Comeau/xp43101beta2/bin/setup"
  como --no_version --no_prelink_verbose  -o
"C:\regression\trunk\results\boost\bin.v2\libs\test\test\algorithms_test.test\como-win-4.3.10.1beta2\debug\link-static\algorithms_test"
@"C:\regression\trunk\results\boost\bin.v2\libs\test\test\algorithms_test.test\como-win-4.3.10.1beta2\debug\link-static\algorithms_test.exe.rsp"


Setting environment for using Microsoft Visual Studio 2008 x86 tools.
libboost_unit_test_framework-como43-d-1_38.lib(unit_test_parameters.obj)
: error LNK2005: std::basic_istream<T1, T2> &std::_M_get_num<T1, T2,
T3>(std::basic_istream<T1, T2> *, T3 &) [with T1=char,
T2=std::char_traits<char>, T3=unsigned int] already defined in
libboost_unit_test_framework-como43-d-1_38.lib(exception_safety.obj)
libboost_unit_test_framework-como43-d-1_38.lib(unit_test_parameters.obj)
: error LNK2005: T1 boost::detail::lexical_cast<T1, T2, N3,
T4>(boost::call_traits<T2>::param_type, T4 *, unsigned int) [with
T1=unsigned int, T2=boost::unit_test::basic_cstring<const char>,
N3=true, T4=char] already defined in
libboost_unit_test_framework-como43-d-1_38.lib(exception_safety.obj)
C:\regression\trunk\results\boost\bin.v2\libs\test\test\algorithms_test.test\como-win-4.3.10.1beta2\debug\link-static\algorithms_test

which essentially means that some of the STL symbols are multiply defined.

* Sandia-rh5-x86_64-intel

Reports:

Platform
     Linux Redhat 5.1 Server (Tikanga) on 16 x Quad-Core Opteron
(Processor 8354), 1.1Ghz, 32Gb
Compilers
     Intel(R) C Compiler for applications running on Intel(R) 64,
Version 10.1 Build 20080312 Package ID: l_cc_p_10.1.015
Options
     -j64 -l300
Schedule
     Full tests run nightly at 10:55pm, (Mountain Standard Time)
Contact
     Noel Belcourt
     kbelco at sandia.gov
Command Line

     regression.py invoked as follows (trailing carets are line
continuation characters)

     python regression.py --runner="Sandia-rh5-x86_64-intel"
--bjam-toolset=intel ^
       --pjl-toolset=intel --toolsets="intel-10.1" --bjam-options="-j64
-l300"


Notes
User-config.jam

     using python
       : 2.4
       ;

     using mpi
       :
/apps/x86_64/mpi/openmpi/intel-10.1-f015-c015/openmpi-1.2.7_ofed/bin/mpic++
       ;

     using intel
       : 10.1
       ;

and that's it

* Sandia-intel-11.0

Reports:


Platform
     Red Hat Enterprise Linux 2.6.9-34.0.2.ELsmp on Dual Duo-Core Intel
Xeon (3Ghz) with 8Gb RAM
Compilers
     Intel(R) C++ Intel(R) 64 Compiler Professional for applications
running on Intel(R) 64, Version 11.0 Build 20081105 Package ID:
l_cproc_p_11.0.074
Options
     -j8
Schedule
     Full tests run nightly at 10:55pm, (Mountain Standard Time)
Contact
     Noel Belcourt
     kbelco at sandia.gov
Command Line

     run.py invoked variously as follows

     python run.py --runner="Sandia-intel-11.0"
--bjam-toolset=intel-linux-11.0 \
       --pjl-toolset=intel-linux-11.0 --toolsets=intel-11.0
--bjam-options=-j8

and that's it

Can we fix these somehow?

Gennadiy

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Gubenko, Boris
Hi Gennadiy,

> I've checked in some iffy code into Boost.Test and impatiently waiting
> for regression results to appear here:
>
> http://www.boost.org/development/tests/trunk/developer/test.html
>
> to fix all regressions.

The results on HP-UX_ia64_aCC for rev. 50367 with your fix in impl/unit_test_parameters.ipp removing Windows.h are back to normal.

The same is true for HP-UX_pa_risc_gcc and HP-UX_ia64_gcc, but their results do not appear on the web yet.

> What I see now is a bit unsettling (a lot
> actually ;(). Number (majority) of testing setups/regression
> reports are
> useless:

I don't know what's causing this weirdness in reporting tests failures.

Boris
_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Beman Dawes
In reply to this post by Gennadiy Rozental-2
On Mon, Dec 22, 2008 at 9:54 PM, Gennadiy Rozental <[hidden email]> wrote:

> * Huang-Vista-x64 (intel- vc9- win- 11.0_x86_64)
>
> Reports failure in library build, but link to the library build output
> shows:
>
>    call "D:/Program Files
> (x86)/Intel/Compiler/11.0/066/cpp/Bin/Intel64//iclvars.bat" > nul
> icl
> @"F:\bv64\results\boost\bin.v2\libs\test\build\intel-vc9-win-11.0_x86_64\debug\address-model-64\threading-multi\compiler_log_formatter.obj.rsp"
>
> '"D:/Program Files
> (x86)/Intel/Compiler/11.0/066/cpp/Bin/Intel64//iclvars.bat"' is not
> recognized as an internal or external command,
> operable program or batch file.
> 'icl' is not recognized as an internal or external command,
> operable program or batch file.
>
> * Huang-WinXP-x86_32
>
> Reports failure in library build, but link to the library build output
> shows:
>
>    call "C:/Program Files/Intel/Compiler/11.0/066/cpp/Bin/ia32//iclvars.bat"
>> nul
> icl
> @"G:\BoostRegressions\Head\results\boost\bin.v2\libs\test\build\intel-vc9-win-11.0\debug\threading-multi\compiler_log_formatter.obj.rsp"
>
> '"C:/Program Files/Intel/Compiler/11.0/066/cpp/Bin/ia32//iclvars.bat"' is
> not recognized as an internal or external command,
> operable program or batch file.
> 'icl' is not recognized as an internal or external command,
> operable program or batch file.

Intel 11.0 on Windows changed its directory structure and the way that
iclvars.bat works. The toolset needs to be updated to reflect the
changes.

I guess we need a volunteer with access to this platform to work on the toolset.

--Beman
_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

David Deakins
In reply to this post by Gennadiy Rozental-2
Gennadiy Rozental wrote:
> I've checked in some iffy code into Boost.Test and impatiently waiting
> for regression results to appear here:

>
> * VeecoFTC (msvc-8.0~wm5~stlport5.1)
>
> Reports failure in library build, but link to the library build output
> shows success
>

I'm not sure if there was a hiccup in the report status previously, but
currently the VeecoFTC Windows Mobile results are correctly showing that
Boost.Test fails to build because putenv (used in putenv_impl in
boost/test/utils/runtime/config.hpp) does not exist on this platform.
Previously, runtime/config.hpp was not included as commonly in the
regression tests, but the recent changes to
boost/test/impl/unit_test_parameters.ipp now cause
boost/test/utils/runtime/env/variable.hpp to be included.  This
eventually draws in runtime/config.hpp and triggers the compiler error.
  Attached are proposed patches to

boost/test/utils/runtime/config.hpp,
boost/test/utils/runtime/env/environment.ipp, and
boost/test/utils/runtime/env/fwd.hpp

that I believe should resolve the WinCE problems.  Let me know if you
see any issues with them.

-Dave

Index: fwd.hpp
===================================================================
--- fwd.hpp (revision 50373)
+++ fwd.hpp (working copy)
@@ -35,7 +35,10 @@
 variable_data*  find_var_record( cstring var_name );
 
 cstring         sys_read_var( cstring var_name );
+
+#if !defined(UNDER_CE)
 void            sys_write_var( cstring var_name, format_stream& var_value );
+#endif
 
 }
 

Index: config.hpp
===================================================================
--- config.hpp (revision 50373)
+++ config.hpp (working copy)
@@ -71,7 +71,7 @@
     // !! this may actually fail. What should we do?
     setenv( name.begin(), value.begin(), 1 );
 }
-#else
+#elif !defined(UNDER_CE)
 inline void
 putenv_impl( cstring name, cstring value )
 {

Index: environment.ipp
===================================================================
--- environment.ipp (revision 50373)
+++ environment.ipp (working copy)
@@ -83,6 +83,7 @@
 }
 
 //____________________________________________________________________________//
+#if !defined(UNDER_CE)
 
 BOOST_RT_PARAM_INLINE void
 sys_write_var( cstring var_name, format_stream& var_value )
@@ -90,6 +91,8 @@
     BOOST_RT_PARAM_PUTENV( var_name, cstring( var_value.str() ) );
 }
 
+#endif
+
 //____________________________________________________________________________//
 
 } // namespace rt_env_detail

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Gennadiy Rozental-2
In reply to this post by Gubenko, Boris
Gubenko, Boris wrote:
>> What I see now is a bit unsettling (a lot
>> actually ;(). Number (majority) of testing setups/regression
>> reports are
>> useless:
>
> I don't know what's causing this weirdness in reporting tests failures.

Who is responsible for these scripts now?

Gennadiy

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Gennadiy Rozental-2
In reply to this post by Beman Dawes
Beman Dawes <bdawes <at> acm.org> writes:

> Intel 11.0 on Windows changed its directory structure and the way that
> iclvars.bat works. The toolset needs to be updated to reflect the
> changes.

Why not disable/remove this tester for now. It does not serve any purpose IMO.

Gennadiy

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Beman Dawes
On Wed, Dec 24, 2008 at 2:30 AM, Gennadiy Rozental <[hidden email]> wrote:
> Beman Dawes <bdawes <at> acm.org> writes:
>
>> Intel 11.0 on Windows changed its directory structure and the way that
>> iclvars.bat works. The toolset needs to be updated to reflect the
>> changes.
>
> Why not disable/remove this tester for now. It does not serve any purpose IMO.

We need to fix this tool problem, not just bury it.

--Beman
_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

John Maddock
Beman Dawes wrote:

>> On Wed, Dec 24, 2008 at 2:30 AM, Gennadiy Rozental
>> <[hidden email]> wrote:
>>> Beman Dawes <bdawes <at> acm.org> writes:
>>>
>>>> Intel 11.0 on Windows changed its directory structure and the way
>>>> that iclvars.bat works. The toolset needs to be updated to reflect
>>>> the changes.
>>>
>>> Why not disable/remove this tester for now. It does not serve any
>>> purpose IMO.
>>
>> We need to fix this tool problem, not just bury it.

I've just committed a fix for Intel-11 on windows, I'll try and do the Linux
compiler later, but I'll need someone to test changes to the intel-darwin
toolset.

Regards, John.

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

John Maddock
John Maddock wrote:
>> I've just committed a fix for Intel-11 on windows, I'll try and do
>> the Linux compiler later, but I'll need someone to test changes to
>> the intel-darwin toolset.

Ah, I'll take that back, Linux toolset looks OK, I'm not sure what the issue
with the Darwin one is, anyone any ideas?

John.

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Beman Dawes
In reply to this post by John Maddock
On Wed, Dec 24, 2008 at 11:38 AM, John Maddock <[hidden email]> wrote:

> Beman Dawes wrote:
>>>
>>> On Wed, Dec 24, 2008 at 2:30 AM, Gennadiy Rozental
>>> <[hidden email]> wrote:
>>>>
>>>> Beman Dawes <bdawes <at> acm.org> writes:
>>>>
>>>>> Intel 11.0 on Windows changed its directory structure and the way
>>>>> that iclvars.bat works. The toolset needs to be updated to reflect
>>>>> the changes.
>>>>
>>>> Why not disable/remove this tester for now. It does not serve any
>>>> purpose IMO.
>>>
>>> We need to fix this tool problem, not just bury it.
>
> I've just committed a fix for Intel-11 on windows, I'll try and do the Linux
> compiler later, but I'll need someone to test changes to the intel-darwin
> toolset.

Just tried it, and it worked out-of-the-box for me. Also verified that
10.1 builds still work.

Thanks!

--Beman
_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Gennadiy Rozental-2
In reply to this post by David Deakins
David Deakins <ddeakins <at> veeco.com> writes:

>
> Gennadiy Rozental wrote:
> > I've checked in some iffy code into Boost.Test and impatiently waiting
> > for regression results to appear here:
>
> >
> > * VeecoFTC (msvc-8.0~wm5~stlport5.1)
> >
> > Reports failure in library build, but link to the library build output
> > shows success
> >
>
> I'm not sure if there was a hiccup in the report status previously, but
> currently the VeecoFTC Windows Mobile results are correctly showing that
> Boost.Test fails to build because putenv (used in putenv_impl in
> boost/test/utils/runtime/config.hpp) does not exist on this platform.

> that I believe should resolve the WinCE problems.  Let me know if you
> see any issues with them.
 If I understand your changes correctly you simply ifdef-ed out references to
putenv. Am I to understand that there is no way to programmatically update an
environment?

Gennadiy

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

David Deakins
Gennadiy Rozental wrote:
> David Deakins <ddeakins <at> veeco.com> writes:
>
>> that I believe should resolve the WinCE problems.  Let me know if you
>> see any issues with them.
 >
>  If I understand your changes correctly you simply ifdef-ed out references to
> putenv. Am I to understand that there is no way to programmatically update an
> environment?
>

Actually, just a little bit different.  It is that Windows CE does not
have any concept of environment variables that are accessible from an
application.

-Dave

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Gennadiy Rozental-2
David Deakins <ddeakins <at> veeco.com> writes:

> Actually, just a little bit different.  It is that Windows CE does not
> have any concept of environment variables that are accessible from an
> application.
>
> -Dave
>

So, I can read, but I can't update? Or I can't do both. In later case I would
simply disable whole environment subsystem.

Gennadiy

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

David Deakins
Gennadiy Rozental wrote:

> David Deakins <ddeakins <at> veeco.com> writes:
>
>> Actually, just a little bit different.  It is that Windows CE does not
>> have any concept of environment variables that are accessible from an
>> application.
>>
>
> So, I can read, but I can't update? Or I can't do both. In later case I would
> simply disable whole environment subsystem.
>

No, you can't read or update.  If there is a simple way to disable the
environment-related classes when UNDER_CE is defined, that would
probably be the most correct.

-Dave

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

John Maddock
In reply to this post by Beman Dawes
Beman Dawes wrote:
>> Just tried it, and it worked out-of-the-box for me. Also verified
>> that
>> 10.1 builds still work.

Good, also added some fixes for Intel-11 on Linux and Darwin so that the
needed shared libraries can be found: these look to be running OK too now
:-)

John.

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Belcourt, Kenneth
In reply to this post by John Maddock

On Dec 24, 2008, at 10:20 AM, John Maddock wrote:

> John Maddock wrote:
>>> I've just committed a fix for Intel-11 on windows, I'll try and do
>>> the Linux compiler later, but I'll need someone to test changes to
>>> the intel-darwin toolset.
>
> Ah, I'll take that back, Linux toolset looks OK, I'm not sure what  
> the issue
> with the Darwin one is, anyone any ideas?

Sorry, been gone for a while.  We have intel-11.0 on both Tiger and  
Leopard.  Both machines exhibit stability problems when running tests  
compiled with intel-11.0 (i.e. both machines reboot every night  
during Boost testing).  We are trying to track this down.

-- Noel


_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

siliconman
In reply to this post by Gennadiy Rozental-2
In article <gipjtd$j66$[hidden email]>,
 Gennadiy Rozental <[hidden email]> wrote:

> * siliconman (borland- 6.10.0)
>
> Reports failure in library build, but link to the library build output
> shows success with wierd content:

   I can send you the bjam log if that will help you. You can email me
directly. (Sorry for not answering sooner. I was away for the holidays)
--
-David

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Gennadiy Rozental-2
siliconman <siliconman <at> spamcop.net> writes:

>
> In article <gipjtd$j66$1 <at> ger.gmane.org>,
>  Gennadiy Rozental <rogeeff <at> gmail.com> wrote:
>
> > * siliconman (borland- 6.10.0)
> >
> > Reports failure in library build, but link to the library build output
> > shows success with wierd content:
>
>    I can send you the bjam log if that will help you. You can email me
> directly. (Sorry for not answering sooner. I was away for the holidays)

I found an access to his compiler. Still no joy. I've made some fixes (checked
in last night), but I will need help to work around internal errors and other
issues this compiler has with using declarations.

It's a shame. We entered 2009 and closing in on new standard and still Borland
and Sun compilers are no better that they were 5 years ago.

Gennadiy


_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

siliconman
In article <[hidden email]>,
 Gennadiy Rozental <[hidden email]> wrote:

> but I will need help to work around internal errors and other
> issues this compiler has with using declarations.

   OK, let me know what you run into and I'll make sure that it gets
tracked in CodeGear's system.
--
-David

_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
Reply | Threaded
Open this post in threaded view
|

Re: Useless failures reports/broken testers

Gennadiy Rozental-2
siliconman <siliconman <at> spamcop.net> writes:

>
> In article <loom.20090105T205234-368 <at> post.gmane.org>,
>  Gennadiy Rozental <rogeeff <at> gmail.com> wrote:
>
> > but I will need help to work around internal errors and other
> > issues this compiler has with using declarations.
>
>    OK, let me know what you run into and I'll make sure that it gets
> tracked in CodeGear's system.

You can see the issues in your own logs.

Any help appreciated.

Gennadiy



_______________________________________________
Boost-Testing mailing list
[hidden email]
http://lists.boost.org/mailman/listinfo.cgi/boost-testing
12