threads / discuss / 11304

Windows binaries for qgit 2.0

Subject: Windows binaries for qgit 2.0

## tl;dr

19 messages between Dec 15, 2007 and Dec 17, 2007.

replies: 18people: 5as markdown or json

Marco Costalba· Dec 15, 2007, 15:02 UTC · lore
Due to a feature request on sourceforge qgit account:
http://sourceforge.net/tracker/index.php?func=detail&aid=1759403&group_id=139897&atid=744830

I have cooked and uploaded a qgit.exe file with Qt4.3.3 statically linked in so to let Windows users that just want to give a shot to qgit the possibility to try it easily.

Normally I use debug shared Qt libraries for development, so after some effort I finally managed to build the static ones and finally to build qgit.exe

Problem is that _this_ qgit.exe shows strange misbehaviour like 20X slower then the one I normally build for development, there is also some strange artifacts with file history graph.

I have a clue that is due to static Qt + mingw 3.4 problems, I have read something on it somewhere, but I would like to ask if someone has experienced the same problems when running qgit2.0 under Windows.

BTW if someone is interested, in the sourceforge thread above there is the link to download this zipped file, testing is very easy and quick, just extract files where git.exe is and start qgit.exe...

Thanks for any help Marco

Abdelrazak Younes· Dec 16, 2007, 07:26 UTC · re: Marco Costalba · lore

Re: Windows binaries for qgit 2.0

Marco Costalba wrote:
Show 7 quoted lines
> Due to a feature request on sourceforge qgit account:
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1759403&group_id=139897&atid=744830
> 
> I have cooked and uploaded a qgit.exe file with Qt4.3.3 statically
> linked in so to let Windows users that just want to give a shot to
> qgit the possibility to try it easily.

Sorry for the intrusion in this list but you don't need to compile Qt statically IMO. Just bundle the Qt dlls that you needs (most probably QtCore and QtGui) with you executable and be done with it.

Show 7 quoted lines
> Normally I use debug shared Qt libraries for development, so after
> some effort I finally managed to build the static ones and finally to
> build qgit.exe
> 
> Problem is that _this_ qgit.exe shows strange misbehaviour like 20X
> slower then the one I normally build for development,  there is also
> some strange artifacts with file history graph.

If you are using debug dlls, those are known to be slower because of the additional checking (like vector bundaries, etc). Beware also of stdlib-debug if you're using gcc. In any case, if you want to gain speed, you should compile with MSVC (MSVC2005Express is free as in beer).

Hope this helps, Abdel.

Marco Costalba· Dec 16, 2007, 07:55 UTC · re: Abdelrazak Younes · lore

Re: Windows binaries for qgit 2.0

On Dec 16, 2007 8:26 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
Show 5 quoted lines
>
> Sorry for the intrusion in this list but you don't need to compile Qt
> statically IMO. Just bundle the Qt dlls that you needs (most probably
> QtCore and QtGui) with you executable and be done with it.
>
Yes. That's another option, I will try that to see if things get better.
>
> If you are using debug dlls, those are known to be slower  because of

Actually I use debug dll for normal development and never experienced slowness. I switched to "release" library to create the qgit package and _now_ I have the thing much slower and also misbehaving. So for me are the release library that have problems, not the debug ones.

> In any case, if you want to gain
> speed, you should compile with MSVC (MSVC2005Express is free as in beer).
>

Yes, I was thinking about this, but Qt don't officially supports MSVC for the Qt4 GPL libraries, so that's the reason I was stick to mingw (although now it comes more and more clear to me that the shipped version has problems with release compiled libraries)

> Hope this helps,
> Abdel.
>

Yes, thanks a lot. Marco

Abdelrazak Younes· Dec 16, 2007, 08:52 UTC · re: Marco Costalba · lore

Re: Windows binaries for qgit 2.0

Marco Costalba wrote:
Show 14 quoted lines
> On Dec 16, 2007 8:26 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
>> Sorry for the intrusion in this list but you don't need to compile Qt
>> statically IMO. Just bundle the Qt dlls that you needs (most probably
>> QtCore and QtGui) with you executable and be done with it.
>>
> 
> Yes. That's another option, I will try that to see if things get better.
> 
>> If you are using debug dlls, those are known to be slower  because of
> 
> Actually I use debug dll for normal development and never experienced slowness.
> I switched to "release" library to create the qgit package and _now_ I
> have the thing much slower and also misbehaving. So for me are the
> release library that have problems, not the debug ones.

Hum, I can't imagine this is the reason, it might be for another reason, most certainly the static compiling.

Show 7 quoted lines
> 
>> In any case, if you want to gain
>> speed, you should compile with MSVC (MSVC2005Express is free as in beer).
>>
> 
> Yes, I was thinking about this, but Qt don't officially supports MSVC
> for the Qt4 GPL libraries,

Well, for the LyX project we used to use and distribute the patched version of Qt in order to compile it with MSVC. Now, since Qt4.3.2 the MSVC compilation support is enabled in the official release so you don't even have to patch it anymore. I can send you precompiled dll if you want. Or you can use the one bundled in the last lyx installer (www.lyx.org).

> so that's the reason I was stick to mingw
> (although now it comes more and more clear to me that the shipped
> version has problems with release compiled libraries)

The first reason why we went away from mingw was because it was way too slow to compile Qt and LyX. With MSVC the binaries are much faster.

Abdel.
Marco Costalba· Dec 16, 2007, 09:05 UTC · re: Abdelrazak Younes · lore

Re: Windows binaries for qgit 2.0

On Dec 16, 2007 9:52 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
>
> Hum, I can't imagine this is the reason, it might be for another reason,
> most certainly the static compiling.
>

Static compiling is indeed a highly suspect. I'm now compiling as shared libraries, we will see...

Show 6 quoted lines
>
> Well, for the LyX project we used to use and distribute the patched
> version of Qt in order to compile it with MSVC. Now, since Qt4.3.2 the
> MSVC compilation support is enabled in the official release so you don't
> even have to patch it anymore. I can send you precompiled dll if you
> want.
Sorry for the stupid question, but, what ddl ??
Marco
Abdelrazak Younes· Dec 16, 2007, 09:10 UTC · re: Marco Costalba · lore

Re: Windows binaries for qgit 2.0

Marco Costalba wrote:
Show 7 quoted lines
> On Dec 16, 2007 9:52 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
>> Hum, I can't imagine this is the reason, it might be for another reason,
>> most certainly the static compiling.
>>
> 
> Static compiling is indeed a highly suspect. I'm now compiling as
> shared libraries, we will see...

Another suspect is that under Windows, at least with MSVC, it is strongly advised to not mix debug and release libraries as they have different memory models. I am not sure to what extend this advice is valid for mingw compiled libraries.

Show 8 quoted lines
> 
>> Well, for the LyX project we used to use and distribute the patched
>> version of Qt in order to compile it with MSVC. Now, since Qt4.3.2 the
>> MSVC compilation support is enabled in the official release so you don't
>> even have to patch it anymore. I can send you precompiled dll if you
>> want.
> 
> Sorry for the stupid question, but, what ddl ??

The MSVC compiled Qt dlls :-) Sorry too, I guess I was not clear enough.

Abdel.
Marco Costalba· Dec 16, 2007, 10:42 UTC · re: Abdelrazak Younes · lore

Re: Windows binaries for qgit 2.0

On Dec 16, 2007 10:10 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
Show 9 quoted lines
> Marco Costalba wrote:
> > On Dec 16, 2007 9:52 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
> >> Hum, I can't imagine this is the reason, it might be for another reason,
> >> most certainly the static compiling.
> >>
> >
> > Static compiling is indeed a highly suspect. I'm now compiling as
> > shared libraries, we will see...
>

Ok. compiled shared libraries release version and qgit release version -> does not even starts!

After some more test I found that if I compile qgit release adding flag -O0 it starts, although there is some strange misbehavior sometime, so the suspect now is a broken O2 optimization for mingw.

To test this I could recompile (sigh!) Qt with shared release + O0 flag, but I'm not sure how to do it.

>
> The MSVC compiled Qt dlls :-)
> Sorry too, I guess I was not clear enough.
>
Yes please!

Thanks Marco

Abdelrazak Younes· Dec 16, 2007, 11:11 UTC · re: Marco Costalba · lore

Re: Windows binaries for qgit 2.0

Marco Costalba wrote:
> On Dec 16, 2007 10:10 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
Show 5 quoted lines
>> The MSVC compiled Qt dlls :-)
>> Sorry too, I guess I was not clear enough.
>>
> 
> Yes please!

Actually you might prefer to just use the LyX dependencies package that we provide for Windows developers, it contains Qt. I paste here the relevant part of our 'INSTALL.Win32':

6 Install the dependencies Download ftp://ftp.lyx.org/pub/lyx/contrib/lyx-windows-deps-msvc-qt4.zip and extract in the root directory of your LyX files (so you will get a directory called lyx-windows-deps-msvc-qt4 next to the other directories like src, development etc.).

I also attach the complete file, you might find some interesting items WRT compiling with MSVC.

Abdel.

Compiling LyX 1.5 for Win32 ===========================

LyX 1.5 can be compiled with Microsoft Visual C++ 2005 (recommended) or MinGW.

Compiling with MSVC 2005 ========================

1	Install MSVC 2005 SP1
	If you don't have MSVC 2005 installed, download and install the free
	Express edition from http://msdn.microsoft.com/vstudio/express/visualc/
	From this page you should also download and install Service Pack 1.
	A hotfix needs to be installed because of a bug in the compiler.
	Search for VS80sp1-KB930859-X86-ENU.exe on Google and install it.
2	Install the Windows Platform SDK
	see: http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/
	(You don't need to install the IIS, MDAC, and Tablet PC SDK that are
	 delivered with the Platform SDK.)
3	Configure MSVC
	Follow exactly the steps of
	http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/
	In Step 3 follow also the things noted as alternative.
	(If you later get an error message that "windows.h" cannot be found,
 	 create the global Windows environment variables "INCLUDE" and "LIB".
	 INCLUDE contains the paths to the "include" folders of the installed
	 platform SDK and of MSVC. LIB contains the corresponding "lib" folders.)
4	Install Python
	Get the latest Python 2.5 version at
	http://www.python.org/download/releases/2.5/
	Install in C:\Python25 and add this directory to the PATH environment
	variable (Start > Settings > Control Panel > System > Advanced >
	Environment Variables).
5	Install SCons
	Download and install SCons 0.96.92 (or newer, but not 0.96.1) from http://www.scons.org/download.php
6	Install the dependencies
	Download ftp://ftp.lyx.org/pub/lyx/contrib/lyx-windows-deps-msvc-qt4.zip
	and extract in the root directory of your LyX files (so you will get
	a directory called lyx-windows-deps-msvc-qt4 next to the other directories
	like src, development etc.).
7	Compile
	From MS Visual Studio command prompt (not the regular cmd.exe), 
	run 
	  > cd <lyx root directory>\development\Win32\packaging
	  > build_msvc.bat
8	First start of LyX
	To start the just compiled lyx.exe, it is necessary to copy the following
	files to the folder where the just compiled "lyx.exe" is:
	Aiksaurus.dll
	aspell.dll
	iconv.dll
	intl.dll
	Microsoft.VC80.CRT.manifest
	msvcp80.dll
	msvcr80.dll
	QtCore4.dll
	QtGui4.dll
	msvcp80.dll and msvcr80.dll are the C Runtime and C++ libraries
	supplied with MSVC 2005. They are freely redistributable.
	See http://msdn2.microsoft.com/en-us/library/8kche8ah(VS.80).aspx
	for details.
	All of the other .dlls above and the lyx executable are compiled
	from code released under the GPL which states (section 3) that
	GPL software may be linked against system files such as msvcp80.dll
	and msvcr80.dll.

Compiling with MinGW ====================

	These instructions allow you to create a basic LyX build with MinGW.
	To be able to use all LyX features, compiling with MSVC 2005 is recommended.
	Creating an installer for MinGW builds is no longer supported.
1	Install MinGW, and all the gcc-related stuff, and win32api. 
2	download qt-win-opensource-4.x.x-mingw.exe and install to c:\qt\4.2.2.
3	install python and scons as instructed above. Set $path for python
	   to make your life a bit easier.
4	Check out lyx svn to c:\lyx-devel\lyx-1.5.x
5	Download zlib binaries and developer files (zlib-1.2.3-bin.zip and
	   zlib-1.2.3-lib.zip) from http://gnuwin32.sourceforge.net/packages/zlib.htm
	   libiconv from http://gnuwin32.sourceforge.net/packages/libiconv.htm
	   gettext  from http://gnuwin32.sourceforge.net/packages/gettext.htm
	   unpack all of them to the same directory c:\lyx-devel\mingw_deps.
6	start a command window, run commands:
	   $ cd c:\lyx-devel\lyx-1.5.x
	   $ scons -f development\scons\SConstruct \
	       extra_lib_path=..\mingw_deps\lib  \
		   extra_inc_path=..\mingw_deps\include \
		   extra_bin_path=..\mingw_deps\bin \
		   qt_dir=c:\qt\4.2.2 \
		   DESTDIR=..\lyx-1.5-install \
		   install

Creating the Installer ======================

	To create an installer with LyX and all related components, download
	and install the latest NSIS from http://nsis.sourceforge.net
	Open development\Win32\packaging\installer\setttings.user.nsh and modify
	the settings depending on your build environment.
	Finally, go to development\Win32\packaging\installer
	(in a normal Windows Explorer), right-click on lyx.nsi and click
	"Compile NSIS Script".
	You can also use the installer target of scons. Namely, use a command like
	   $ scons -f development\scons\SConscript installer
	This will create $BUILDDIR\lyx-version-timestamp-Installer.exe for a devel version,
	and $BUILDDIR\lyx-version-Install.exe for a released version of lyx.
	If you also want to generate bundled installer, download 
	lyx-windows-bundle-deps.zip from http://www.lyx.org/~bpeng, unpack
	to lyx-windows-bundle-deps under the top source directory, and run
	  $ scons -f development\scons\SConstruct installer bundle=1
	If you prefer to use another directory, you can use option bundle_dir like
	  $ scons -f development\scons\SConstruct installer bundle=1 bundle_dir=c:\bundle
Marco Costalba· Dec 16, 2007, 22:26 UTC · re: Abdelrazak Younes · lore

Re: Windows binaries for qgit 2.0

On Dec 16, 2007 12:11 PM, Abdelrazak Younes <younes.a@free.fr> wrote:
Show 5 quoted lines
>
> Actually you might prefer to just use the LyX dependencies package that
> we provide for Windows developers, it contains Qt. I paste here the
> relevant part of our 'INSTALL.Win32':
>

Thanks, I've tried it but without success because I need MSVC 2005 installed, and currently is not.

Anyhow for now I have produced a version with mingw that seems more or less to work, when I have a bit of time I will install MSVC 2005 and try if with that compiler is better...

Thanks Marco

Abdelrazak Younes· Dec 17, 2007, 09:51 UTC · lore

Re: Windows binaries for qgit 2.0

Marco Costalba wrote:
Show 8 quoted lines
> On Dec 16, 2007 12:11 PM, Abdelrazak Younes <younes.a-GANU6spQydw@public.gmane.org> wrote:
>> Actually you might prefer to just use the LyX dependencies package that
>> we provide for Windows developers, it contains Qt. I paste here the
>> relevant part of our 'INSTALL.Win32':
>>
> 
> Thanks, I've tried it but without success because I need MSVC 2005
> installed, and currently is not.
Right.
> 
> Anyhow for now I have produced a version with mingw that seems more or
> less to work, when I have a bit of time I will install MSVC 2005 and
> try if with that compiler is better...
I would like to help you with that but I can't retrieve the repository:

$ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/ git.kernel.org[0: 130.239.17.7]: errno=Invalid argument git.kernel.org[1: 199.6.1.166]: errno=Bad file descriptor git.kernel.org[2: 204.152.191.8]: errno=Bad file descriptor git.kernel.org[3: 204.152.191.40]: errno=Bad file descriptor fatal: unable to connect a socket (Bad file descriptor) fetch-pack from 'git://git.kernel.org/pub/scm/qgit/qgit4.git' failed.

$ git clone http://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/ Cannot get remote repository information. Perhaps git-update-server-info needs to be run there?

$ git --version git version 1.5.3.6.1791.gfd264

'git clone ssh://...' seems to work but I guess I need a login and password?
Maybe I am doing something wrong here? Sorry, my first time ever with git...
Abdel.
PS: Sorry for the cross posting but I guess this issue is maybe of
interest to msysgit people.
Johannes Schindelin· Dec 17, 2007, 10:44 UTC · re: Abdelrazak Younes · lore

Re: [msysGit] Re: Windows binaries for qgit 2.0

Hi,
On Mon, 17 Dec 2007, Abdelrazak Younes wrote:
Show 44 quoted lines
> Marco Costalba wrote:
> > On Dec 16, 2007 12:11 PM, Abdelrazak Younes <younes.a@free.fr> wrote:
> > > Actually you might prefer to just use the LyX dependencies package that
> > > we provide for Windows developers, it contains Qt. I paste here the
> > > relevant part of our 'INSTALL.Win32':
> > > 
> > 
> > Thanks, I've tried it but without success because I need MSVC 2005
> > installed, and currently is not.
> 
> Right.
> 
> > 
> > Anyhow for now I have produced a version with mingw that seems more or
> > less to work, when I have a bit of time I will install MSVC 2005 and
> > try if with that compiler is better...
> 
> I would like to help you with that but I can't retrieve the repository:
> 
> $ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
> git.kernel.org[0: 130.239.17.7]: errno=Invalid argument
> git.kernel.org[1: 199.6.1.166]: errno=Bad file descriptor
> git.kernel.org[2: 204.152.191.8]: errno=Bad file descriptor
> git.kernel.org[3: 204.152.191.40]: errno=Bad file descriptor
> fatal: unable to connect a socket (Bad file descriptor)
> fetch-pack from 'git://git.kernel.org/pub/scm/qgit/qgit4.git' failed.
> 
> $ git clone http://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?
> 
> $ git --version
> git version 1.5.3.6.1791.gfd264
> 
> 'git clone ssh://...' seems to work but I guess I need a login and password?
> 
> Maybe I am doing something wrong here? Sorry, my first time ever with git...
> 
> Abdel.
> 
> PS: Sorry for the cross posting but I guess this issue is maybe of
> interest to msysgit people.

Why would anything that has to do with MSVC2005 be interesting to msysGit? Note the "msys" part of "msysGit".

FWIW a member of our team works on compiling/including qgit into msysGit. But definitely not using closed-source compilers. I would violently oppose that.

Ciao, Dscho

Abdelrazak Younes· Dec 17, 2007, 11:07 UTC · re: Johannes Schindelin · lore

Re: [msysGit] Re: Windows binaries for qgit 2.0

Johannes Schindelin wrote:
Show 47 quoted lines
> Hi,
> 
> On Mon, 17 Dec 2007, Abdelrazak Younes wrote:
> 
>> Marco Costalba wrote:
>>> On Dec 16, 2007 12:11 PM, Abdelrazak Younes <younes.a@free.fr> wrote:
>>>> Actually you might prefer to just use the LyX dependencies package that
>>>> we provide for Windows developers, it contains Qt. I paste here the
>>>> relevant part of our 'INSTALL.Win32':
>>>>
>>> Thanks, I've tried it but without success because I need MSVC 2005
>>> installed, and currently is not.
>> Right.
>>
>>> Anyhow for now I have produced a version with mingw that seems more or
>>> less to work, when I have a bit of time I will install MSVC 2005 and
>>> try if with that compiler is better...
>> I would like to help you with that but I can't retrieve the repository:
>>
>> $ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
>> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
>> git.kernel.org[0: 130.239.17.7]: errno=Invalid argument
>> git.kernel.org[1: 199.6.1.166]: errno=Bad file descriptor
>> git.kernel.org[2: 204.152.191.8]: errno=Bad file descriptor
>> git.kernel.org[3: 204.152.191.40]: errno=Bad file descriptor
>> fatal: unable to connect a socket (Bad file descriptor)
>> fetch-pack from 'git://git.kernel.org/pub/scm/qgit/qgit4.git' failed.
>>
>> $ git clone http://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
>> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
>> Cannot get remote repository information.
>> Perhaps git-update-server-info needs to be run there?
>>
>> $ git --version
>> git version 1.5.3.6.1791.gfd264
>>
>> 'git clone ssh://...' seems to work but I guess I need a login and password?
>>
>> Maybe I am doing something wrong here? Sorry, my first time ever with git...
>>
>> Abdel.
>>
>> PS: Sorry for the cross posting but I guess this issue is maybe of
>> interest to msysgit people.
> 
> Why would anything that has to do with MSVC2005 be interesting to msysGit?  
> Note the "msys" part of "msysGit".

Sorry, I meant the error I am facing trying to clone the qgit repository. MSVC2005 has of course nothing to do with MSYS (while one could imagine that MSys and for the matter git could be compiled with it instead of mingw).

> 
> FWIW a member of our team works on compiling/including qgit into msysGit.  
> But definitely not using closed-source compilers.  I would violently 
> oppose that.
Noted. I didn't meant to start a debate here.
Abdel.
Marco Costalba· Dec 17, 2007, 19:14 UTC · re: Johannes Schindelin · lore

Re: [msysGit] Re: Windows binaries for qgit 2.0

On Dec 17, 2007 11:44 AM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 8 quoted lines
>
> Why would anything that has to do with MSVC2005 be interesting to msysGit?
> Note the "msys" part of "msysGit".
>
> FWIW a member of our team works on compiling/including qgit into msysGit.
> But definitely not using closed-source compilers.  I would violently
> oppose that.
>

I would (violently) agree with you, but I also violently oppose to waste a week end fighting with Qt4 + mingw compilation. MSVC2005 is needed as a kind of "debug tool" to better understand if the problem is with Qt4 or with mingw (as I suspect).

Abdel is very kind to try to help in caming out with a qgit.exe more or less ready to be packaged. I'm not opposed, in this phase, to follow different _technically_ sound paths. Then when the dust settles down we could do our consideration regarding open source, in which I belive very firmly, so firmly that I'm not scared to _test_ different ways if this can be useful to shed some light on this issue.

Marco
Marco Costalba· Dec 17, 2007, 19:05 UTC · re: Abdelrazak Younes · lore

Re: Windows binaries for qgit 2.0

On Dec 17, 2007 10:51 AM, Abdelrazak Younes <younes.a-GANU6spQydw@public.gmane.org> wrote:
Show 12 quoted lines
>
> I would like to help you with that but I can't retrieve the repository:
>
> $ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
> git.kernel.org[0: 130.239.17.7]: errno=Invalid argument
> git.kernel.org[1: 199.6.1.166]: errno=Bad file descriptor
> git.kernel.org[2: 204.152.191.8]: errno=Bad file descriptor
> git.kernel.org[3: 204.152.191.40]: errno=Bad file descriptor
> fatal: unable to connect a socket (Bad file descriptor)
> fetch-pack from 'git://git.kernel.org/pub/scm/qgit/qgit4.git' failed.
>
This is very strange, I can clone without problems...someone has ideas?
Show 5 quoted lines
> $ git clone http://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
> Cannot get remote repository information.
> Perhaps git-update-server-info needs to be run there?
>
Well, perhaps, but to clone with git protocol you don't need that.
Marco
Johannes Schindelin· Dec 17, 2007, 19:13 UTC · re: Marco Costalba · lore

Re: Windows binaries for qgit 2.0

Hi,
On Mon, 17 Dec 2007, Marco Costalba wrote:
Show 12 quoted lines
> On Dec 17, 2007 10:51 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
> >
> > I would like to help you with that but I can't retrieve the repository:
> >
> > $ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
> > Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
> > git.kernel.org[0: 130.239.17.7]: errno=Invalid argument
> > git.kernel.org[1: 199.6.1.166]: errno=Bad file descriptor
> > git.kernel.org[2: 204.152.191.8]: errno=Bad file descriptor
> > git.kernel.org[3: 204.152.191.40]: errno=Bad file descriptor
> > fatal: unable to connect a socket (Bad file descriptor)
> > fetch-pack from 'git://git.kernel.org/pub/scm/qgit/qgit4.git' failed.

This looks familiar. It happens when there was no response to the 4 IPs of git.kernel.org. This might be due to a firewall which blocks git://

Show 6 quoted lines
> > $ git clone http://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git 
> > Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/ 
> > Cannot get remote repository information. Perhaps 
> > git-update-server-info needs to be run there?
> 
> Well, perhaps, but to clone with git protocol you don't need that.

It is generally a good idea to provide the server-info for dumb protocols, because not everybody is fortunate enough (like you, evidently, because you do not seem to care all that much...) to control her outbound firewall restrictions.

Ciao, Dscho

Abdelrazak Younes· Dec 17, 2007, 21:22 UTC · re: Johannes Schindelin · lore

Re: Windows binaries for qgit 2.0

Johannes Schindelin wrote:
Show 22 quoted lines
> Hi,
>
> On Mon, 17 Dec 2007, Marco Costalba wrote:
>
>   
>> On Dec 17, 2007 10:51 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
>>     
>>> I would like to help you with that but I can't retrieve the repository:
>>>
>>> $ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
>>> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
>>> git.kernel.org[0: 130.239.17.7]: errno=Invalid argument
>>> git.kernel.org[1: 199.6.1.166]: errno=Bad file descriptor
>>> git.kernel.org[2: 204.152.191.8]: errno=Bad file descriptor
>>> git.kernel.org[3: 204.152.191.40]: errno=Bad file descriptor
>>> fatal: unable to connect a socket (Bad file descriptor)
>>> fetch-pack from 'git://git.kernel.org/pub/scm/qgit/qgit4.git' failed.
>>>       
>
> This looks familiar.  It happens when there was no response to the 4 IPs 
> of git.kernel.org.  This might be due to a firewall which blocks git://
>   

Yes, I guess this is the issue. I'll try from home now and report back. In any case I managed to clone the qgit4 repository from http://repo.or.cz/r/qgit4.git already so I can work from here.

Abdel.
Marco Costalba· Dec 17, 2007, 19:17 UTC · lore

Re: Windows binaries for qgit 2.0

On Dec 17, 2007 8:13 PM, Johannes Schindelin <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> wrote:
Show 6 quoted lines
>
> It is generally a good idea to provide the server-info for dumb protocols,
> because not everybody is fortunate enough (like you, evidently, because
> you do not seem to care all that much...) to control her outbound firewall
> restrictions.
>
I have taken note of Peter suggestion's to do a
chmod +x foo.git/hooks/post-update

on kernel repository, I don't remember if I have already done it many months ago, but I'm planning to redo for safety as soon as I reach my development box.

Thanks Marco

Abdelrazak Younes· Dec 17, 2007, 21:20 UTC · lore

Re: Windows binaries for qgit 2.0

Marco Costalba wrote:
Show 11 quoted lines
> On Dec 17, 2007 10:51 AM, Abdelrazak Younes <younes.a-GANU6spQydw@public.gmane.org> wrote:
>   
>> $ git clone http://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
>> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
>> Cannot get remote repository information.
>> Perhaps git-update-server-info needs to be run there?
>>
>>     
>
> Well, perhaps, but to clone with git protocol you don't need that.
>   
Just for clarification, this is not my question, this is git asking.
Abdel.
Abdelrazak Younes· Dec 17, 2007, 21:40 UTC · lore

Re: Windows binaries for qgit 2.0

Marco Costalba wrote:
Show 24 quoted lines
> On Dec 17, 2007 11:44 AM, Johannes Schindelin
> <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> wrote:
>   
>> Why would anything that has to do with MSVC2005 be interesting to msysGit?
>> Note the "msys" part of "msysGit".
>>
>> FWIW a member of our team works on compiling/including qgit into msysGit.
>> But definitely not using closed-source compilers.  I would violently
>> oppose that.
>>
>>     
>
> I would (violently) agree with you, but I also violently oppose to
> waste a week end fighting with Qt4 + mingw compilation. MSVC2005 is
> needed as a kind of "debug tool" to better understand if the problem
> is with Qt4 or with mingw (as I suspect).
>
> Abdel is very kind to try to help in caming out with a qgit.exe more
> or less ready to be packaged. I'm not opposed, in this phase, to
> follow different _technically_ sound paths. Then when the dust settles
> down we could do our consideration regarding open source, in which I
> belive very firmly, so firmly that I'm not scared to _test_ different
> ways if this can be useful to shed some light on this issue.
>   
If you allow me to share my experience in the LyX project WRT mingw/msys 
versus MSVC: We tried very hard to use it, but at the end we faced many 
issues, so many issues that MSVC was the only pragmatic choice:
- autotools hell with msys: the automake version was simply too old and 
we had to mix cygwin and msys environment to get something done.
- linker hell: more than 500 megs of RAM was needed to link LyX with 
Qt3, the situation was better with Qt4 but still.
- compilation slowness. Mingw is just not good with C++.
- binary slowness: this is less of a problem with Qt4 but still, the 
MSVC compiled LyX is much faster.

In conclusion, I guess C-compilation is fine with Mingw and you should definitly stay with it for git, but for a heavy GUI oriented C++ program I strongly recommend MSVC.

Abdel.

← back to recent threads