I have a program which depends on MSVCR90.dll, library which I'm shipping with it alongside the main executable among other things:
ProgramFolder\Main.exe
ProgramFolder\MSVCR90.dll
I wanted to know if when a new update to it is available (fixing a security issue for example) the one I supply would take precedence over the updated file in System32 or SxS.
Is there a way to programatically know which version of the C runtime is being used?
You can check the executables import header to find which version of C runtime it has got references to. Removing it from system32 directory wont help, instead it will create a crash.
Related
On Linux (Ubuntu) what is the path and file name where I can see the C/C++ code used in the malloc() and new() implementations?
I have looked in /usr/include but started to lose my way around. Does it depend on which version of gcc/g++ I have installed?
If someone could also give a general answer which would help me understand how Linux stores all the "native" functions it would be most appreciated and I wouldnt ever have to ask again for a different function.
One thing: new is a C++ keyword that uses malloc.
The source for malloc is in the source for your version of libc, which is probably glibc. Look at their source.
Other built in functions that are system calls only have shell implementations in glibc that call the underlying syscall.
The GIT of the GNU standard C lib implementation can be found here.
From this point in the tree you should be able to find the rest as well.
The "implementation" is a library you can link (an "a" file or an "so" file) plus an header that contains the declaration (an "h" file).
The C and CPP files sits on the computer that created those libraries before they had been used to build-up your system. And since their source is not required for your programs to work (you just link the binaries, not the sources) they are not distributed together with the system build.
That's why you have to download those files from the source repositories, jut like if you want yourself to rebuild the system.
You find this in the implementation of the C Standard Library the compiler uses.
I'm not sure for Ubunta. Debian's gcc uses eglibc, which's sources could be found here.
I am using C++ with Visual Studio 2008 Express.
We are supplying a binary-only Windows library to a client, which itself uses a number of other libraries. Therefore we shipped both our dll file, along with the dll files that we use. Now the issue is that our client uses some of the libraries that we also use, but in another version. Therefore he can not use our library, since the libraries we both depend on are incompatible.
Technically I think it should be possible that both dependency versions are loaded into the process space. However, I am unsure how to do this, as both their application, as well as our dll look for the same dependency dll file name. Can anyone tell me what the best/cleanest way to deal with this problem is?
Thanks!
Generally speaking, it won't work. This is due to the fact that the third party DLL versions might interfere with each other when loaded into memory. One example could be if there is an exclusive resource like e.g. a file in a specific directory. Or a specific device. The problem is, nobody knows probably not even the manufacturer of the 3rd party DLLs - so extensive testing is necessary.
But maybe you're lucky and it works anyway. My recipe:
Put your DLL "DTAG.DLL" and all needed DLLs in a subdirectory of the applications directory with a fixed name e.g. "DTAG_LIB".
Write a import library by hand (there are other possibilities using DELAYLOAD). In that library load your DLL with LoadLibraryEx. Provide an absolute path ending with "DTAG_LIB\DTAG.DLL" and the flag LOAD_WITH_ALTERED_SEARCH_PATH. Windows will then load your DTAG.DLL from this directory and all needed DLLs from that directory also. Don't set the PATH to "DTAG_LIB"!
Your customer has to link against your manual import lib.
You could solve this kind of problem using a (new) additional DLL you would deliver and that would take care of handling the versions conflict (at runtime) - being a kind of proxy between your app and its dependencies.
An alternative would be to use the Windows Forwarded Libraries mechanism.
Forwarders are a handy way to accommodate functionality moving from one DLL to another
You can use several ways to declare forwarders, such as a module definition (.def) file and a #pragma:
#pragma comment(linker, "/export:function=otherdll.function")
I have a C++ applicatoin which uses dynamically linked libary. I have placed application and library on target and application is running. Now i have changed some thing in library and made the library and replaced old library on target with new library.
My questions is
Does application takes new libarary with out recompliing and relinking?
Thanks!
Yes, but only if your new library is ABI compatible with the older one.
You can find many info about it on the web. I'd suggest you to read this FAQ about binary compatibility.
Yes, so long as the interface hasn't changed. That's one advantage of dynamically-linked libraries.
Yes. The library is loaded at run-time by the dynamic linker. As long as the ABI is preserved (same compiler and version), your code will use the new code seamlessly without need for recompilation.
If you are just talking about binary compatibility and whether it is necessary to recompile and relink the application, then you should read the link provided in peoro's answer.
However, I am slightly confused by the "application is running" part of your question. If you mean that it is in fact running at the very moment when you replace the library, then it won't use the new version unless it's restarted first or another instance of the application is started (but then the old instance would still use the old version). Not every OS will allow you to just replace a library that is in use by an application, but there are workarounds. In Windows, you can't overwrite or delete the old library, but you can move or rename it before putting the new version there. Linux will allow you to delete the old version, and if you copy the new version using the install command, it will do it automatically for you. But the old version won't be deleted physically from the file system until the application finishes, it will just be invisible.
I'm having some strange issues building and running a project on another computer. It's a side-by-side error. Usually the cause is that c++ redistributable is not installed on the machine etc. However in this case the project is compiled on that machine. MSVC++ 2005 is installed, the runtimes should be there (I installed the runtime again for good measure anyway). Why is the linker referencing a runtime library that isn't available on the machine?
I'm dynamically linking to runtime library.
Any ideas on how to debug this issue?
Thanks.
EDIT
I didn't want to start another post because it's related. Because of this DLL version mess, is this a good reason to statically link to runtime? Will I avoid all these problems? I don't see any advantages to dynamically link to runtime any more. I was under the impression that with DLL runtime you get the benefit of updates/bug fixes with new DLLs. However because of the SxS and manifests it ensures that it loads the specific version (old version) of the DLL anyway? So what's the point of dynamic runtime at all? Maybe a few kb of space saved because you're not embedding the re-used functions in all the dependent libraries. But compare this to the cost of your app won't run because some ancient runtime version is removed from the machine, isn't it worth it?
Thanks again. Still tracing the original problems and will probably have to recompile every single library I'm using.
sxstrace will tell you exactly what is going on with respect to SxS. It will show what dlls are searched and how they are mapped to actual versions.
Now, which runtime is loaded is coming from the manifest file that gets included in your project. Looking at the one you mention, it looks like the one from Visual2005, with no service pack. SP1 changed the crt to 8.0.50727.762
Some details on sxstrace on vista and XP
Well, since you added a question to your question, let me add an answer to my answer:
SxS will not necessarily load the version you specify inside your manifest. The SxS system keeps track of security fixes made to specific versions, e.g. and will change which version it loads even when you ask for a specific version.
That said, if your program uses DLLs, and you want to share C objects (e.g. malloc'ed memory) between them, then your only option is the CRT DLL. It really depends what your constraints are.
It may happen when you compile along a third party library, or object files, that you compiled on another machine and the copied on the machine where the issue occurs.
Try to find such binary files on your machine, and recompile them on that machine.
Not an answer to the problem, but an answer to this question:
Why is the linker referencing a runtime library that isn't available on the machine?
The linker doesn't need the actual runtime library to link. It just needs (typically), the .lib file at link time. The .lib file tells the linker what the runtime library will provide (as in exported symbols) when the OS locates the dll at runtime.
Dependency Walker can be helpful in cases like this to help debug the problem.
EDIT: followup to the new question. Static linking does resolve these issues, however it also introduces some new issues. You can share dynamically allocated objects between dlls - however, whichever dll allocated the object must be the one to deallocate it. Any methods on the object that allocate/reallocate/deallocate member data/objects similarly must be governed in order to avoid heap corruption. Non-inline refcounting/shared pointers will be helpful. Alternatively, shared mem allocators can be helpful too.
Here's a possibly related forum post. Not sure if this is the problem, but it seems worth checking.
The summary is that MS updated the ATL, CRT, MFC, and a few other libraries on VS 2005 developer machines via an automatic update.
On machines without VS2005 installed, they only updated the ATL via an automatic update, causing SxS errors.
You can either uninstall the update on the dev machine, or upgrade the runtimes manually on the machine you're trying to run on. Details on the post.
My (C++, cross-platform) app is heavily using Boost libraries (say version 1.x), and I want to also link against a 3rd-party (vendor)'s SDK (no source), itself using Boost (but version 1.y).
So, we both link dynamically against our own version of Boost DLLs, CRT being identical. Consequently, at run-time my app would have to load both DLL of Boost 1.x & 1.y.
What are the potential issues & gotchas associated?
I can't change vendor's SDK, but I can change my app. Maybe I should try to link statically against my Boost 1.x?
PS: Name of Boost's DLL include their version, so no name collision, both are identifiable. Not the usual DLL-hell.
As far as using the DLLs for different versions there should be no problem. At least not on Windows.
This is true if the SDK is using boost internally. If the SDK uses boost constructs in its interface, for example: it has a function that returns a boost::optional, then having multiple versions can cause problems. It could still work fine, dependent on the changes between the versions, but that will definitely be a risk. I don't know of any good solution in that case. This is also true if you include a SDK header file that includes a boost header file.
This is a big problem.
Do a search on DLL hell.
Basically the DLL (or shared libs in Linux) are loaded but not all the names are resolved at load time. What happens is a lazy evaluation, so the names are evaluated on first use. The problem is that if 2 dll have the same name then the location where the name is resolved to depends on the what order the DLL are searched in (which depends on load order).
If you statically link then you will not have problems with method calls as yours will all be resolved at compile time and the third party will be resolved at runtime from the DLL. But what about structures that are created by version-1 boost. If you then pass these to the third party library that then passes it to the version-x boost. Are the structures layed out in the same way?
This is a very tricky area and when problems occur very hard to de-bug.
So try and use the same version.
If you write a function foo, and export it from F.dll, and another function foo exported from G.dll, would you expect problems?
When AF.exe is linked, the linker is told: put some code in there that loads the address of function foo from F.dll. Now BG.dll is linked to retrieve the foo address from G.dll. I still see no problem.
Now replace AF.exe with your app, BG.dll with your vendor's app, F.dll with your boost version, G.dll with the vendor's boost version.
Concluding: I see no problems if the dll names are different.