On Sun, Sep 16, 2012 at 09:48:43PM +0200, Erik Faye-Lund wrote: > >> git-upload-pack: error while loading shared libraries: libiconv.so.2: > >> cannot open shared object file: No such file or directory > >> fatal: The remote end hung up unexpectedly > > [...] > > No. This is not a Git for Windows issue. The remote end is the one who > isn't able to load libiconv, you can tell from the fact that it > complains about "libiconv.so.2", not "libiconv-2.dll", and from the > fact that the client informs us that the remote end hung up.
Yeah, it is definitely a problem on the remote system. > Ankush: There's something wrong with the setup on your Linux machine; > most likely something related to the library path set up. What > protocol are you cloning over? If I had to guess, I'd say it was ssh, the library is installed in a non-standard place (e.g., because he built them as a regular user and put them in his home directory), and LD_LIBRARY_PATH does not get set properly by ssh for the incoming ssh session. If that is the case, you can fix it with an entry in ~/.ssh/environment, or by telling git that the remote side needs to do more than just run git-upload-pack, like: git clone -u '. $HOME/.profile && git-upload-pack' ... But I am just guessing. We need more information on how the remote system is set up to really know. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
