Re: #pragma lib buggers everything up

Tech-Archive recommends: Speed Up your PC by fixing your registry

> But of course. EXE and DLL are two separate modules, they cannot share
> code. If both link against a static library and use the same function or
> class from said library, both end up with a copy of the code. This has
> nothing to do with #pragma lib. If you want two modules to share code, you
> have to factor this common code into yet another DLL, and link both
> modules against it.

The issue with this was lots of linker errors citing 'function xxx is
already defined in module yyy.obj', however this was due to the fact that
the static library was being compiled with /MDd while the application was
being compiled as /MTd, switching the class library to /MTd solved this.

>
> I'm not sure what any of this has to do with STL though.

It was all STL functions that were being multiply defined (when I had the
wrong switches), but like I say is resolved now.

>
>> Now tell me, what the bloody hell is wrong with the MS way of doing
>> things, which is to provide documentation which says "include xxx.h,
>> link with yyy.lib". I really hope the designers of the STL weren't
>> glib enough to think that people would be so inept as to fail to work
>> out why their project wouldn't build when they hadn't added the STL
>> libraries to linker input, and 'drift off and use someone else's
>> class library'? Idiots!
>
> Can you kindly point to a page in STL documentation that would instruct
> one to link against a .LIB file?

Exactly - there is none. It's obviously all done with #pragma lib (or more
precisely #pragma comment(lib,...) ) , but what I was initially saying was
that I'd rather have more control over the linking and have to add them to
the linker input manually rather than the compiler being told to do this
automatically by the STL headers.



.

Relevant Pages

  • Re: On runtimes, string wrapping and vs7 / vs8
    ... We have a dll with an api that use std::strings for a bunch of things. ... StringH(const StringH&) ... that gets fully compiled with the application compiler. ... the equivalent to working with static libraries for dependency purposes. ...
    (microsoft.public.vc.language)
  • Re: moving a AFX DLL from VS 2003 to either 2005 or 2008 causes issue at loadlibrary
    ... to make the same DLL work after changing the ... Even though its told in the compiler options to link MFC staticly, ... Is it a direct dependency of your DLL? ... have linked with some other static libraries that are dependent on the MFC ...
    (microsoft.public.vc.mfc)
  • Re: On runtimes, string wrapping and vs7 / vs8
    ... We have a dll with an api that use std::strings for a bunch of things. ... StringH(const StringH&) ... that gets fully compiled with the application compiler. ... the equivalent to working with static libraries for dependency purposes. ...
    (microsoft.public.vc.language)
  • Re: moving a AFX DLL from VS 2003 to either 2005 or 2008 causes issue at loadlibrary
    ... I have a DLL that if compiled under Visual Studio 2003, it will load fine with load library. ... Even though its told in the compiler options to link MFC staticly, depends told me it needed mfc90.dll and msvcr90.dll. ... is it possible that you have linked with some other static libraries that are dependent on the MFC and CRT DLLs? ... Let's have a gander inside that HH_CW.dll.intermediate.manifest to see what dependencies it may be mentioning. ...
    (microsoft.public.vc.mfc)
  • Re: DLL interface using STL vector/string/exception in .NET 2003
    ... > STL vectors of classes containing STL string and STL exception ... > Should there be any problem using the DLL in these ways? ... > compilation options or different RT library but I do not know for ... release are different runtime libraries, so you'd once again have multiple ...
    (microsoft.public.vc.stl)