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
Received on 2010-12-01