How do you resolve "standard" DLLs?

[Jeff Lynn]

Help!

I recently upgraded my VS V6 to VS 2005 and was unable to build projects
that were perfectly ok under VS V6. Where VS 2005 fails was in the linker
resolving external DLLs, which are Open Source DLLs like "log4Cxx" and
"Xerces C++" DLL libraries.

VS 2005 converted my projects without any problem. Even the proper lib
includes and lib path were captured. But its linker just unable to resolve
the C++ function references.

I am aware of the mismatched calling convention between C-style and C++
style DLL. I thought I solve that problem when I created working project
under VC 6.0.

Do anyone have a very simple project that show how to configure the VS 2005
C++
project to link to these C++ DLLs?

Is there a simple way to use C++ DLLs, which is "not managed code" under
Microsoft's point of view?

Please help, I am desparate and may have to return the VS 2005 and keep
using the VS V6, which is ancient, I know, but what choice do I have if I
cannot call simple DLLs like "log4Cxx" functions?
JML

[Bruno van Dooren]

Help!

I recently upgraded my VS V6 to VS 2005 and was unable to build projects
that were perfectly ok under VS V6. Where VS 2005 fails was in the linker
resolving external DLLs, which are Open Source DLLs like "log4Cxx" and
"Xerces C++" DLL libraries.

VS 2005 converted my projects without any problem. Even the proper lib
includes and lib path were captured. But its linker just unable to resolve
the C++ function references.

I am aware of the mismatched calling convention between C-style and C++
style DLL. I thought I solve that problem when I created working project
under VC 6.0.

Do anyone have a very simple project that show how to configure the VS 2005
C++
project to link to these C++ DLLs?

Is there a simple way to use C++ DLLs, which is "not managed code" under
Microsoft's point of view?

Please help, I am desparate and may have to return the VS 2005 and keep
using the VS V6, which is ancient, I know, but what choice do I have if I
cannot call simple DLLs like "log4Cxx" functions?

Hi,

It would be helpful if you supplied the exact linker error messages.

Is it possible these dlls you speak of export classes that you use in your
app?
if so then you are out of luck. C++ 6.0 produces different code from c++8.0

that is the reason why C style interfaces are the only viable option for
building dlls that have to be used by different compilers.

However, if these dlls are open source you can download the sources, build
them using VC2005 and then link your application against those dlls. that way
the dlls are built with the same compiler version as your application.

--

Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"

[Carl Daniel [VC++ MVP]]

Jeff Lynn wrote:

Help!

I recently upgraded my VS V6 to VS 2005 and was unable to build
projects that were perfectly ok under VS V6. Where VS 2005 fails was
in the linker resolving external DLLs, which are Open Source DLLs
like "log4Cxx" and "Xerces C++" DLL libraries.

VS 2005 converted my projects without any problem. Even the proper
lib includes and lib path were captured. But its linker just unable
to resolve the C++ function references.

I am aware of the mismatched calling convention between C-style and
C++ style DLL. I thought I solve that problem when I created working
project under VC 6.0.

Do anyone have a very simple project that show how to configure the
VS 2005 C++
project to link to these C++ DLLs?

Is there a simple way to use C++ DLLs, which is "not managed code"
under Microsoft's point of view?

Please help, I am desparate and may have to return the VS 2005 and
keep using the VS V6, which is ancient, I know, but what choice do I
have if I cannot call simple DLLs like "log4Cxx" functions?

Code produced by VC6 and VC8 is laregly compatible at the binary level
(assuming the same source code is compiled), but there are a couple of
exceptions that may be tripping you up:

1. MFC, ATL or STL classes used in the interface won't work between VC6 and
VC8. I seriously doubt that any of those are used in log4cxx or Xerces C++.

2. The name decoration for template functions changed. VC6 didn't use the
actual template parameters in building the decorated name but rather used
only the argument types. This could result in a template function and a
non-template function with identical parameters having the same decorated
name. More likely in your case, the difference in handling wchar_t is to
blame. Under VC6, wchar_t is a typedef for unsigned short, while under VC8
it's a distinct type. This difference is reflected in differences in the
decorated names of any function that uses wchar_t in it's interface. You
*might* be able to use the VC6-compiled libraries if you compile your VC8
code with /Zc:forScope-, which disables the built-in wchar_t and uses the
typedef instead.

As Bruno already replied, the best solution is to get the source code to
those open source libraries and rebuild it using VC8.

-cd

[Jeff Lynn]

Thank you for both Bruno's and Carl's response. I will surely tried the /Zc
switch later on.

If this switch doesn't work, then surely Microsoft had made a unwise
decision because Microsoft cannot expect every avaiable library need to be
recompiled under VS 2005. Even in my case, I wouldn't want to recompile the
Open Source just because I want to use VS 2005. The choice is clear, if the
/Zc doesn't work, I will return the VS 2005 and stick with my VS V6.

I aware of the legacy baggage issue, but not having the backward
compaitility issue is a bit mistake.

I will report whether the suggested /Zc work for me or not. Thanks again
for the quick responses!

jml

[Jeff Lynn]

Yes, I specified the /Zc:wchar_t- option under Properties\Configuration
Properties\C/C++\Language\Treat wchar_t as Built-in Type and it works.

Thanks you fory your great support.

jml

[Jeff Lynn]

Now that I am able to link to Open Source "log4Cxx" and "Xerces C++" DLLs, I
now run into DLL created by me. I rebuild the DLL under VS C++ 2005, yet
when I build a test program to use a static method that return CString, I got
the following error during linking at the function "CppUtility::AsISODate()"
to return current date in "YYYY-MM-DD" fashion, just a wrapper to the
"formatted string" function:

Linking...
Test2.obj : error LNK2019: unresolved external symbol "__declspec(dllimport)
public: static class ATL::CStringT<unsigned short,class
StrTraitMFC_DLL<unsigned short,class ATL::ChTraitsCRT<unsigned short> > >
__cdecl CppUtility::AsISODate(void)"
(__imp_?AsISODate@CppUtility@@SA?AV?$CStringT@GV?$ StrTraitMFC_DLL@GV?$ChTraitsCRT@G@ATL@@@@@ATL@@XZ) referenced in function _wmain
X:\MLArch\Test2\Debug\Test2.exe : fatal error LNK1120: 1 unresolved externals

I experimented with specifying the ATL option to use (in both CppUtility DLL
and test2) the following options:
- do not use ATL
- use static link ATL
- use dynamic link ATL

get the same error.

Any suggestion here?

jml

[Carl Daniel [VC++ MVP]]

Jeff Lynn wrote:

Now that I am able to link to Open Source "log4Cxx" and "Xerces C++"
DLLs, I
now run into DLL created by me. I rebuild the DLL under VS C++ 2005,
yet
when I build a test program to use a static method that return
CString, I got
the following error during linking at the function
"CppUtility::AsISODate()"
to return current date in "YYYY-MM-DD" fashion, just a wrapper to the
"formatted string" function:

Linking...
Test2.obj : error LNK2019: unresolved external symbol
"__declspec(dllimport)
public: static class ATL::CStringT<unsigned short,class
StrTraitMFC_DLL<unsigned short,class ATL::ChTraitsCRT<unsigned short>

__cdecl CppUtility::AsISODate(void)"

(__imp_?AsISODate@CppUtility@@SA?AV?$CStringT@GV?$ StrTraitMFC_DLL@GV?$ChTraitsCRT@G@ATL@@@@@ATL@@XZ)
referenced in function _wmain X:\MLArch\Test2\Debug\Test2.exe : fatal
error LNK1120: 1 unresolved externals

I experimented with specifying the ATL option to use (in both
CppUtility DLL
and test2) the following options:
- do not use ATL
- use static link ATL
- use dynamic link ATL

get the same error.

Any suggestion here?

Unfortunately, that looks like the ATL library was built with /Zc:wchar_t
(not -), so you're getting undefined symbols when trying to use /Zc:wchar_t-
:(

In VS2003 the MFC dlls were built with some special secret sauce to make it
work both ways, I wonder if they didn't do that for 2005...

It looks like what you really want is #pragma conform(wchar_t, ...).
Unfortunately, it looks like #pragma conform can only toggle the for-loop
scope option and not the wchar_t option.

I suspect that in the end your only option to use both ATL/MFC and the
open-source libraries in the same project is to re-build those open source
libraries with VC8.

While it's inconvenient, this is nothing unexpected when moving to a new
compiler. VC++ has done a much better job over the years of maintaining
backwards compatibility than any other C++ compiler out there that I know
of. In this case though, you may have no choice but to recompile.

-cd

[Bruno van Dooren]

If this switch doesn't work, then surely Microsoft had made a unwise
decision because Microsoft cannot expect every avaiable library need to be
recompiled under VS 2005. Even in my case, I wouldn't want to recompile the
Open Source just because I want to use VS 2005. The choice is clear, if the
/Zc doesn't work, I will return the VS 2005 and stick with my VS V6.

I aware of the legacy baggage issue, but not having the backward
compaitility issue is a bit mistake.

to be honest, Microsoft has a much better track record for binary
compatibility than others. probably because their customers depend on it.
msvc is much more backwards compatible than gcc. try using class libraries
compiled with gcc 2.95 in an app that is compiled with gcc 4.0.3.

same story for linux versions.

the whole point of open source is that it gives you the freedom to recompile
and change things whenever needed. most open source project leaders
discourage binary compatibility since this would make things easier for
closed source projects. one could argue that recompiling your open source
libraries is the only 'politically' correct solution.

this is the reason for example that the nvidia display driver installer on
linux compiles wrapper functions for their core driver on the fly during
installation. otherwise they would have to distribute dozens of driver
packages, depending on ditribution and exact kernel versions.

that being said I am a believer in binary compatibility, but the problem is
that there is no definition of what a compiled C++ should look like (this is
one of the reasons COM was invented actually). that is the reason why I
export only C style interfaces in dlls.

--

Kind regards,
Bruno.
br**********************@hotmail.com
Remove only "_nos_pam"