Internal compiler errror
Johnny Willemsen
I get the following internal compiler error:
------ Build started: Project: ACE DLL, Configuration: Debug Win32 ------
Compiling...
Proactor.cpp
Proactor.cpp(38) : fatal error C1001: INTERNAL COMPILER ERROR
(compiler file 'msc1.cpp', line 2844)
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
It can be reproduced by downloading ACE/TAO from
http://deuce.doc.wustl.edu/Download.html
Johnny Willemsen
Jason Shirk [MSFT]
Here is the workaround. In ACE_wrappers\ace\Task_T.h, line 40, change:
class ACE_Task : public ACE_Task_Base
to
class ACE_Export ACE_Task : public ACE_Task_Base
Assuming this works for you (I only tested building ACE, nothing more), then
you should suggest the workaround to the ACE/TAO team.
We will certainly fix the bug, but you won't be the last person to hit this
issue.
Jason Shirk
VC++ Compiler Team
"Johnny Willemsen" <johnny_w...@planet.nl> wrote in message
news:OHPMsI$sBHA.2696@tkmsftngp05...
Johnny Willemsen
The fix you mention is not the solution. I am part of the ACE/TAO team and I
am looking more into this. The problem is with the fix that you propose that
the ace library compiles, but the test applications of ace don't compile
anymore. The same problem now appears in the string class of the newest ace
release (will be released in a few days). There we have a base class from
which a template is derived. When the ACE_Export isn't added to the strings
class, the compiler crashed on the ace library itself, when it is added the
ace library compiles, but we get the following errors when compiling the
test application:
_ctor' : definition of dllimport function not allowed
The same error we get when using the ACE_Task template class (the code you
give below is from a template definition).
Also when compiling the ACE library we get the following strange warnings:
l:\acelatest\ACE_wrappers\ace\Thread_Adapter.cpp(252): warning C4532:
'return' : jump out of __finally block has undefined behavior during
termination handling
l:\acelatest\ACE_wrappers\ace\OS_Thread_Adapter.cpp(178): warning C4532:
'return' : jump out of __finally block has undefined behavior during
termination handling
So could you please have a better look at it and build also the ace tests
(located in the tests directory at the same level of ACE). ACE is now
supported on a lot of problems and compilers but not with msvc7.
Johnny
"Jason Shirk [MSFT]" <jas...@online.microsoft.com> wrote in message
news:#vGMm4$sBHA.2112@tkmsftngp05...
Justin
easily corrected by the obvious solution. Just don't return from the SEH
finally block. Let the code drop through.
I spent quite a bit of time trying to figure out how to get TAO to compile
using VC.NET. I also tried to duplicate the problem with a simpler test
program, but couldn't reproduce it.
So far this problem is preventing me from using VC.NET, because almost
everything I work on is built with ACE, TAO, or both.
P.S. Can Microsoft please comment on the availability of the new VC which
can compile Loki, boost, etc. ? Is this planned as a new release, or will it
go out as a service pack for VC.NET?
Thanks,
Justin Michel
Software Engineer
OCI
Jason Shirk [MSFT]
news:u6l4gj9...@corp.supernews.com...
>
> P.S. Can Microsoft please comment on the availability of the new VC which
> can compile Loki, boost, etc. ? Is this planned as a new release, or will
it
> go out as a service pack for VC.NET?
>
> Thanks,
>
> Justin Michel
> Software Engineer
> OCI
>
>
I can't offer anything that hasn't been said publicly before.
Loki, Boost, etc. are on our radar, and we haven't commented on what the
release will look like or when it will happen. You can be certain we are
pushing hard to release quickly, 3 1/2 years is far too long to wait.
Jonathan Caves [MSFT]
__declspec(dllimport) ]
This "breakage" is due to a is change in behavior that we introduce in
Visual C++ 7.0 to make the application of dllexport more consistent between
regular classes and specializations of class templates.
If you apply dllexport to a regular class that has a base-class that it not
marked as dllexport you get a warning:
C4275: non dll-interface class 'B' used as base for dll-interface class 'D'
You get the same warning if the base-class is a specialization of a class
template. The work-around for this was to also mark the base-class with
dllexport. The problem with a specialization of a class template was were to
place the __declspec(dllexport) -- we do not allow you to mark the class
template itself as we thought it would be unlikely that anyone would want
all specializations of a class template to be marked with dllexport. So the
we advised users to explicitly instantiate the class template and to mark
this explicit instantiation with dllexport -- for example:
template class __declspec(dllexport) B<int>;
class __declspec(dllexport) D : public B<int> {
// ...
The problem with this work-around is that it fails if the template argument
is the deriving class - for example:
class __declspec(dllexport) D : public B<D> {
// ...
Not an uncommon "pattern" with templates.
So we decided to change the semantics of dllexport when it is applied to a
class that has a one or more base-classes and one or more of the
base-classes are a specialization of a class template. In this case we
implicitly apply the dllexport to the specializations of class templates. So
Visual C++ 7.0 a user can do the following and they will not get a warning:
class __declspec(dllexport) D : public B<D> {
// ...
Unfortunately there is a bug in the implementation :-( -- it requires
multiple inheritance and virtual functions something which TAO/ACE exposes.
There are several work-arounds for this problem
1) Revert to explicit marking the base-class as dllexport.
2) If this is not possible: then mark only those function you want to export
with dllexport.
Note: the 2nd work-around is what you should use if you really do not want
any of the methods of the base-classes to be exported. For the warning
message you get below it seems that maybe you do not intend any of the
base-class methods to be exported -- if this is the case then you should
look into explicitly exporting only those methods you need to have exported.
If you have any questions please feel free to get in touch with me.
--
Jonathan Caves
Microsoft Corporation
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use. © 2002 Microsoft Corporation. All rights
reserved.
http://www.microsoft.com/info/cpyright.htm.
"Johnny Willemsen" <johnny_w...@planet.nl> wrote in message
news:ugcmUAGtBHA.2012@tkmsftngp04...
Johnny Willemsen
Thanks for the explanation. First tests with ace/tao look good. We got rid
of the compiler errors and probably the next version of ace/tao will have
vc7 support.
Johnny
"Jonathan Caves [MSFT]" <no_spam_...@microsoft.com> wrote in message
news:#2a3l5LtBHA.1600@tkmsftngp07...