All,
Thanks for reply but its not working still. Things which I have done till now
is
On Linux machine
Installed libiconv-1.14 unded /usr/local/lib path.
-rw-r--r-- 1 root root 912 Sep 15 20:40 libiconv.la
lrwxrwxrwx 1 root root 17 Sep 15 20:40 libiconv.so ->
libiconv.so.2.5.1
lrwxrwxrwx 1 root root 17 Sep 15 20:40 libiconv.so.2 ->
libiconv.so.2.5.1
-rw-r--r-- 1 root root 1262349 Sep 15 20:40 libiconv.so.2.5.1
export LD_LIBRARY_PATH=/usr/local/lib:$LD_LIBRARY_PATH
on local machine I have installed msysgit and trying to clone
C:\Ankush Data\work\Test-GIT\trial_1>git clone
ssh://bea@<IP>:/home/ankush/GIT/sample_project
Cloning into 'sample_project'...
bea@<IP>:'s password:
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
-----Original Message-----
From: Jeff King [mailto:[email protected]]
Sent: Tuesday, September 18, 2012 1:51 AM
To: Erik Faye-Lund
Cc: Konstantin Khomoutov; Aggarwal, Ankush; [email protected]
Subject: Re: Unable to clone GIT project
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