6 replies to this topic

[Icebone1000]

I never paid much attention to this, so I dont know if it started all of suddem or if it was doing that since the begining...but I dont know why those are being generated.

Searching google a bit looks like its because my project have stuff with __declspec(dllexport), but I didnt wrote any of those, nor I can find any of those using vs find entire solution..

Im afraid my project config files may be glitched or my compilation times can be greater than theyd need to be due the generation of those annoying files..

The only external stuff Im using on my project is boost, and Im using the boost serialization stuff, witch requires a lib linkage..perhaps is boost the guilt one? anything should I do or care about?

[InvalidPointer]

I would imagine Boost does some stuff, and it's also very likely the Microsoft CRT does some futzing too, especially if you use the run-time-linked libraries.


With that said this will have very, very negiligible impact on final compile time and you're making a mountain out of a molehill. Sometimes things need to be exported for stuff to Just Work and VIsual Studio is mature enough that basic kinks like this would have been worked out.

[adeyblue]

If you add
dumpbin /exports $(TargetPath)
as a post-build event for the dll/exe project generating the lib & exp, the build output will tell you what functions are being exported.

I know VS 2008 has a bug where certain build options will cause the project to export std::_Init_locks which in turn will generate an exp & lib for otherwise non-exporting projects. I don't know if they fixed it though.

[Icebone1000]

If you add
dumpbin /exports $(TargetPath)
as a post-build event for the dll/exe project generating the lib & exp, the build output will tell you what functions are being exported.

I know VS 2008 has a bug where certain build options will cause the project to export std::_Init_locks which in turn will generate an exp & lib for otherwise non-exporting projects. I don't know if they fixed it though.

Im getting this:

Dump of file C:\Users\Gateway\Documents\Visual
1>LINK : fatal error LNK1181: cannot open input file 'C:\Users\Gateway\Documents\Visual'
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: The command "dumpbin /exports C:\Users\Gateway\Documents\Visual Studio 2010\Projects\Astar\Debug\Astar.exe
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" exited with code 1181.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

"Dump of file C:\Users\Gateway\Documents\Visual" -> from where this come from? theres no such thing, off course it will not open
i just copy and pasted the line from your post on the post build command line, in the project properties

[Brother Bob]

You need to put the $(TargetPath) in quotes if it contains spaces to ensure that the spaces are parsed as a single file name and not as argument separators.

dumpbin /exports "$(TargetPath)"

Edited by Brother Bob, 16 November 2012 - 11:12 AM.

[Icebone1000]

0.00 version
1> 1 ordinal base
1> 132 number of functions
1> 132 number of names

.. 132 lines of weirdo giant strings, looks all of them have "boost" on it

4000 .data
1> 3000 .idata
1> 2B000 .rdata
1> 7000 .reloc
1> 1000 .rsrc
1> B6000 .text
1> 54000 .textbss

normal?
thanks for the help

[ApochPiQ]

This is totally normal and nothing to worry about.


If you're curious about the cause of this, here's the short-ish technical explanation (may be slightly inaccurate in places, in the interests of making it legible): In Windows, you can dynamically link to not just DLL files but also EXE files. That is to say, you can use functions exported from an EXE from within a loaded DLL, rather than only being able to use DLL functions from within the EXE. (This is actually extremely handy.) When you set up certain configurations of the runtime library (and also some Boost libraries) they are designed to share the implementation between appropriately built DLLs and the base EXE. This means that if you load a DLL that uses the library, and the EXE uses the same version, they can share the library implementation instead of duplicating it.

So basically what you're seeing is a shortcut to allow you to save compile time and link time. It's a good thing.