Prev: warning LNK4099: PDB 'mfcm80d.i386.pdb' was not found
Next: SetupDiGetDeviceInfoListDetail() buffer problem
From: Pieter on 9 Feb 2007 17:58
We noticed a strange problem with VC8 SP1 that does not happen with VC 7.1
SP1.

If you include <new> in stdafx.h, and you use new(std::nothrow) the release
EXE will export this function:
class std::_Init_locks & std::_Init_locks::operator=(class std::_Init_locks
const &)

Reproduce:
- VC8 SP1
- Create new console application using the wizard.
- Add "#include <new>" to main CPP file.
- Add "char * pData = new(std::nothrow) char[100];" to the main CPP file.
- Compile release mode.
- Notice there is no export lib and if you use Dependency Walker
(http://www.dependencywalker.com/) there are no exports from the EXE.

- Now delete "#include <new>" from the CPP file and add "#include <new>" to
stdafx.h.
- Compile release mode.
- Notice that the linker now generated an export lib and if you open the EXE
with depends the EXE exports "class std::_Init_locks &
std::_Init_locks::operator=(class std::_Init_locks const &)"

Any ideas how to prevent or fix this?

Test app available at:
http://www.insanegenius.com/download/testnew.rar

Regards
Pieter


From: Alex Blekhman on 10 Feb 2007 06:54
"Pieter" wrote:
> We noticed a strange problem with VC8 SP1 that does not
> happen with VC 7.1 SP1.
>
> If you include <new> in stdafx.h, and you use
> new(std::nothrow) the release EXE will export this
> function:
> class std::_Init_locks & std::_Init_locks::operator=(class
> std::_Init_locks const &)
>
> [...]
>
> Any ideas how to prevent or fix this?

First of all, why do you consider it to be a problem? This
benign export doesn't have any impact on anything and
program runs correctly with or without it.

I'm not 100% sure as of why this exports appears. After
playing a little bit with test project I noticed following:

1. `_Init_locks' class doesn't define operator=, so it's
generated by compiler. `_Init_locks::operator=' is exported
because whole class is exported by default (in case you
compile with /MD switch).

2. `_Init_locks::operator=' function comes from
"msvcprt.lib" (DUMPBIN /exports msvcprt.lib), however it
exported from "msvcp80.dll" like this:

??4_Init_locks(a)std@@QAEAAV01(a)ABV01@@Z =
??4_Num_float_base(a)std@@QAEAAU01(a)ABU01@@Z

where "??4_Num_float_base(a)std@@QAEAAU01(a)ABU01@@Z" is

public: struct std::_Num_float_base & __thiscall
std::_Num_float_base::operator=(struct std::_Num_float_base
const &)

Probably this is the source of the problem.

3. Also, linker reorders some of functions even if /ORDER
switch isn't specified. If you enable verbose linker output,
then you'll find that following processing occurs:

....
External code objects not listed in the /ORDER file:
...
??4_Init_locks(a)std@@QAEAAV01(a)ABV01@@Z ;
msvcprt.lib(nothrow.obj)
...

So, it seems that `_Init_locks::operator=' is in predefined
linker order list (whatever it means). Considering all this,
I think that exporting `_Init_locks::operator=' from EXE is
some harmless linker quirk. Call it a bug, if you like. I
tried to reproduce it with simple EXE/DLL project, however
without success.

While searching for solution I noticed that static
multithread Standard C++ Library (libcpmt.lib) doesn't
contain `_Init_locks::operator=' among its symbols. So, by
adding `_STATIC_CPPLIB' to project's preprocessor
definitions you can eliminate `_Init_locks::operator='
export from EXE. CRT code still will be used from dynamic
library, but Standard C++ Library code will be linked
statically.

HTH
Alex

From: Pieter on 11 Feb 2007 13:30
Alex, thank you for the reply.

Alex wrote:
> First of all, why do you consider it to be a problem? This benign export
> doesn't have any impact on anything and program runs correctly with or
> without it.
Umm, I guess we have diferrent standards of what constitutes a bug.

Alex wrote:
> some harmless linker quirk. Call it a bug, if you like. I tried to
> reproduce it with simple EXE/DLL project, however without success.
That is strange, the repro case works on all machines I tried.
Did you try my little sample app?

Alex wrote:
> contain `_Init_locks::operator=' among its symbols. So, by adding
> `_STATIC_CPPLIB' to project's preprocessor definitions you can eliminate
> `_Init_locks::operator=' export from EXE. CRT code still will be used from
> dynamic library, but Standard C++ Library code will be linked statically.
Static linking is not an option.



"Alex Blekhman" <xfkt(a)oohay.moc> wrote in message
news:O6bvuoQTHHA.192(a)TK2MSFTNGP04.phx.gbl...
> "Pieter" wrote:
>> We noticed a strange problem with VC8 SP1 that does not happen with VC
>> 7.1 SP1.
>>
>> If you include <new> in stdafx.h, and you use new(std::nothrow) the
>> release EXE will export this function:
>> class std::_Init_locks & std::_Init_locks::operator=(class
>> std::_Init_locks const &)
>>
>> [...]
>>
>> Any ideas how to prevent or fix this?
>
> First of all, why do you consider it to be a problem? This benign export
> doesn't have any impact on anything and program runs correctly with or
> without it.
>
> I'm not 100% sure as of why this exports appears. After playing a little
> bit with test project I noticed following:
>
> 1. `_Init_locks' class doesn't define operator=, so it's generated by
> compiler. `_Init_locks::operator=' is exported because whole class is
> exported by default (in case you compile with /MD switch).
>
> 2. `_Init_locks::operator=' function comes from "msvcprt.lib" (DUMPBIN
> /exports msvcprt.lib), however it exported from "msvcp80.dll" like this:
>
> ??4_Init_locks(a)std@@QAEAAV01(a)ABV01@@Z =
> ??4_Num_float_base(a)std@@QAEAAU01(a)ABU01@@Z
>
> where "??4_Num_float_base(a)std@@QAEAAU01(a)ABU01@@Z" is
>
> public: struct std::_Num_float_base & __thiscall
> std::_Num_float_base::operator=(struct std::_Num_float_base const &)
>
> Probably this is the source of the problem.
>
> 3. Also, linker reorders some of functions even if /ORDER switch isn't
> specified. If you enable verbose linker output, then you'll find that
> following processing occurs:
>
> ...
> External code objects not listed in the /ORDER file:
> ...
> ??4_Init_locks(a)std@@QAEAAV01(a)ABV01@@Z ; msvcprt.lib(nothrow.obj)
> ...
>
> So, it seems that `_Init_locks::operator=' is in predefined linker order
> list (whatever it means). Considering all this, I think that exporting
> `_Init_locks::operator=' from EXE is some harmless linker quirk. Call it a
> bug, if you like. I tried to reproduce it with simple EXE/DLL project,
> however without success.
>
> While searching for solution I noticed that static multithread Standard
> C++ Library (libcpmt.lib) doesn't contain `_Init_locks::operator=' among
> its symbols. So, by adding `_STATIC_CPPLIB' to project's preprocessor
> definitions you can eliminate `_Init_locks::operator=' export from EXE.
> CRT code still will be used from dynamic library, but Standard C++ Library
> code will be linked statically.
>
> HTH
> Alex
>


From: Alex Blekhman on 12 Feb 2007 02:57
"Pieter" wrote:
>> some harmless linker quirk. Call it a bug, if you like. I
>> tried to reproduce it with simple EXE/DLL project,
>> however without success.
> That is strange, the repro case works on all machines I
> tried.
> Did you try my little sample app?

Sorry, I was unclear. I can reproduce it with your sample,
of course. What I tried to do is to re-create it with simple
DLL, which exports a class and EXE, which uses this class.
Compiler generated `operator=' was never exported from EXE.

>> contain `_Init_locks::operator=' among its symbols. So,
>> by adding `_STATIC_CPPLIB' to project's preprocessor
>> definitions you can eliminate `_Init_locks::operator='
>> export from EXE. CRT code still will be used from dynamic
>> library, but Standard C++ Library code will be linked
>> statically.
> Static linking is not an option.

If you worry about memory allocations and other CRT stuff,
then you shouldn't: it will be linked dynamically. Only C++
Library classes will be linked statically. Otherwise, you're
out of luck. BTW, you didn't say how this export interferes
with program's flow.

Alex


From: Charles Wang[MSFT] on 12 Feb 2007 03:33
Hi Alex,
Per my understanding, you are concerned with the issue that the exports
were produced when you put the "#include <new>" statement in the "stdafx.h"
file however no exports when "#include <new>" was in the main CPP file.
If I have misunderstood, please let me know.

I reproduced your issue (actually VS8.0 without SP1 also has the same
behavior), but I did not find any document regarding this topic. I will
consult the product team to get the confirmation and let you know the
response as soon as possible. The process may need a long time. Appreciate
your patience.

Also, could you please let me know why you want to prevent the exports if
they did not impact your application?

If you have any other questions or concerns, please feel free to let me
know. It is my pleasure to be of assistance.

Best regards,
Charles Wang
Microsoft Online Community Support

======================================================
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
======================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
======================================================

 |  Next  |  Last
Pages: 1 2 3 4
Prev: warning LNK4099: PDB 'mfcm80d.i386.pdb' was not found
Next: SetupDiGetDeviceInfoListDetail() buffer problem