Phillip Wu wrote: > I am new to Visual Studio C++ development. Are you experienced with another C or C++ development environment? I find Visual Studio to be a difficult environment, so if you know something else then I would suggest starting with that.
> But from what I read dynamic linking means calls to the dll is > resolved at run time Yes, which means that the DLL must be available at run time. > and implicit/static linking is resolved at compile time. Yes, the linker will include all neccessary parts of the library in the program that it generates, which means that the DLL is not needed anymore, once the program has been linked. > Does this mean if I use implicit linking and the location of the > dll changes then I need to recompile my client program? See above. Further, on Windows I believe you will never need to recompile because of where a DLL is stored. You need to recompile your program if you upgrade the DLL to a version which is not backwards compatible. We make an effort to avoid breaking backwards compatibility in the library, so that this never happens. Still, if upgrading from a very old DLL then you may run into trouble with this, and have no choice but to recompile. As for location of DLLs, the part of the system that loads executables (called the loader) has a certain way to search for DLLs that programs require. This is a property of each system (Windows, Linux, Mac OS) and is not usually something that the program can/should change. On UNIX (including Mac OS X) it's possible to specify full paths to shared objects (platform-specific name for DLLs) but should be used mostly for dynamically loadable plugins, and the like. > 3. I wrote a very simple client program based on MSDN socket program: > sock=ssh_connection(host)); /* Creates socket to host */ > session = libssh2_session_init(); > if (status=libssh2_session_startup(session, sock)) exit(0); > userauthlist = libssh2_userauth_list(session, username, strlen(username)); > > However userauthlist is empty. If I run the same program (replacing > the socket creation part) on my Redhat Linux system with the same > user it works fine. This is the trace from openssh: .. > Connection from 10.1.8.1 port 5408 > Did not receive identification string from 10.1.8.1 Is this sshd output from when the client runs on Linux and succeeds, or from when running on Windows and failing to retrieve userauthlist? > 1. Can someone spot what is wrong? Not without further information. > 2. libssh2.dll calls routines in libgcrypt.dll which in turn calls > routines in libgpg-error.dll. > Do I need to do anything special with *.obj for libssh2 to tell > Windows about this? No, you just need to make sure to link your program with the correct libraries. If you are using dynamic linking I believe you'll only need to link with libssh2, since that is all you are making direct calls to. If you are using static linking you need to link with the union of all libraries required by all libraries that you require, so all of libssh2, libgcrypt and libgpg-error, because they will all be included in the program output from the linker. It may be good for you to look more into how compiling and linking works, preferably in the particular context of your development environment, before you continue with your project. //Peter _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
