Well, I do not consider myself a Windows expert. But when we converted from the old VC6 windows compiler to the VS2003 compilers, the C/C++ runtime changed. We discovered that the first runtime loaded wins, and if the exe loaded up the old runtime first, and a dll needed the new runtime, it would not work, crashed and burned.
But if you build the agent dll completely staticly linked so it has no dependence on any msvcr*dll runtimes, the runtime library issue should not be an issue. The additional issue is the security features in VS2005, and you will likely need to link your dll with bufferoverflowU.lib. I confess to not completely understanding it, but the code generated by default from VS2005 requires it. Welcome to a more secure world. With Linux and Solaris, building an agent library statically linked might be a little dangerous without using a mapfile because these library symbols might be externally visible, but with windows as I recall, by default the symbols are not external, you have to explicitly 'export' the symbols you want seen. So the static link will be safe, but you will have effectively baked in the system runtime into your dll, and bug fixes in the msvcr*dll files will not help you. -kto Jonathan Albrecht wrote:
I'm trying to build a jvmti agent with Visual Studio 2005 on x86 Windows XP. Specifically, the compiler is: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for 80x86 The agent runs without problem when built with Visual Studio 6 for x86 or when cross-compiled for x86_64 with Visual Studio 2005. When I try to run a Visual Studio 2005 for x86 build, it gets through our Agent_OnLoad function but, according to the debugger, it later segfaults in jvm code and it appears that none of our jvmti agent code is in the call stack. Would anyone know if it is possible to build a jvmti agent with VS2005? If it is possible, are there any known issues or compiler switches I need to look out for? Googling, I was only able to find one other person who was trying to build a jvmti agent with VS2005 and he appeared to get the same behaviour I am seeing. Thanks, Jonathan Albrecht
