Re: No automake-1.9 on mingw/msys yet...
Enrico Forestieri wrote: Angus Leeming <[EMAIL PROTECTED]> writes: Oh, nice! I had no idea that ldd worked on Windows. Oh well, this isn't the real ldd ;-) $ cat /usr/local/bin/ldd #!/bin/sh # Emulate ldd FULL_WIN_PATH=`cygpath -w -a "$1"` cygcheck "$FULL_WIN_PATH" Magic! Thank you. Angus
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming <[EMAIL PROTECTED]> writes: > Oh, nice! I had no idea that ldd worked on Windows. Oh well, this isn't the real ldd ;-) $ cat /usr/local/bin/ldd #!/bin/sh # Emulate ldd FULL_WIN_PATH=`cygpath -w -a "$1"` cygcheck "$FULL_WIN_PATH" -- Enrico
Re: No automake-1.9 on mingw/msys yet...
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Jean-Marc Lasgouttes wrote: Remember to "configure Angus> --disable-stdlib-debug". Makes a huge difference to link times. >> Are you sure? That's weird... I thought the generated text was the >> same in all cases. Angus> Isn't that --disable-concept-checks ? Doesn't stdlib-debug Angus> create custom iterators containing masses of extra stuff? Yes, I meant to post a 'Oops!' answer to myself, but forgot. Oops! JMarc
Re: No automake-1.9 on mingw/msys yet...
Jean-Marc Lasgouttes wrote: > Angus> Remember to "configure --disable-stdlib-debug". Makes a huge > Angus> difference to link times. > > Are you sure? That's weird... I thought the generated text was the > same in all cases. Isn't that --disable-concept-checks ? Doesn't stdlib-debug create custom iterators containing masses of extra stuff? -- Angus
Re: No automake-1.9 on mingw/msys yet...
Enrico Forestieri wrote: >> If you were to do that, you'd probably want a third package containing >> only C:\Program Files\LyXxtras\bin >> dt2dv.exe >> dv2dt.exe >> libiconv-2.dll >> mingwm10.dll >> qt-mt3.dll >> >> and have the lyx.bat in the 1.3 and 1.4 versions of the LyX package add >> this directory to the PATH before launching lyx.exe. > > Angus, > no libiconv-2.dll in sight there: > $ ldd /c/Programmi/LyX/bin/lyx.exe Oh, nice! I had no idea that ldd worked on Windows. > C:/Programmi/LyX/bin/lyx.exe > C:/Programmi/LyX/bin\qt-mt3.dll > C:/Programmi/LyX/bin\mingwm10.dll Nice to know. Maybe it was a left over from some previous attempts to use the MinGW gettext. I seem to remember trying to do so and failing. -- Angus
Re: No automake-1.9 on mingw/msys yet...
> "Angus" == Angus Leeming <[EMAIL PROTECTED]> writes: Angus> Remember to "configure --disable-stdlib-debug". Makes a huge Angus> difference to link times. Are you sure? That's weird... I thought the generated text was the same in all cases. JMarc
Re: No automake-1.9 on mingw/msys yet...
Abdel <[EMAIL PROTECTED]> writes: > Hum, I'm no expert in that domain but maybe the linker has to "unique" > each and every methods that are defined in the duplicate headers. As > mingw gcc 3.4 has no support for precompiled header the linker has to do > this triage and this should take time, shouldn't it? (this is a > question, I'm really not knowledgeable in that field) > Maybe it's just that the mingw linker is not as optimized as the linux > one and tends to keep multiple instances of the same code in memory... > There is an experimental port of gcc 4 to mingw somewhere (thisiscoolgcc > IIRC). It might be worth a try to test if things are better with this > and precompiled header. See message 5 in http://lists.trolltech.com/qt-interest/2004-11/thread00516-0.html -- Enrico What follows is here only to convince the gmane interface to post my article. The following errors were found. Fix them, and submit again: 1. There's much more quoted text in your article than new. Prune quoted stuff.
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming <[EMAIL PROTECTED]> writes: > If you were to do that, you'd probably want a third package containing only > C:\Program Files\LyXxtras\bin > dt2dv.exe > dv2dt.exe > libiconv-2.dll > mingwm10.dll > qt-mt3.dll > > and have the lyx.bat in the 1.3 and 1.4 versions of the LyX package add > this directory to the PATH before launching lyx.exe. Angus, no libiconv-2.dll in sight there: $ ldd /c/Programmi/LyX/bin/lyx.exe C:/Programmi/LyX/bin/lyx.exe C:\WINNT\system32\KERNEL32.dll C:\WINNT\system32\ntdll.dll C:\WINNT\system32\msvcrt.dll C:\WINNT\system32\SHELL32.DLL C:\WINNT\system32\GDI32.dll C:\WINNT\system32\USER32.dll C:\WINNT\system32\ADVAPI32.dll C:\WINNT\system32\RPCRT4.dll C:\WINNT\system32\SHLWAPI.dll C:\WINNT\system32\COMCTL32.dll C:/Programmi/LyX/bin\qt-mt3.dll C:\WINNT\system32\COMDLG32.DLL C:/Programmi/LyX/bin\mingwm10.dll C:\WINNT\system32\OLE32.dll C:\WINNT\system32\OPENGL32.DLL C:\WINNT\system32\GLU32.dll C:\WINNT\system32\DDRAW.dll C:\WINNT\system32\DCIMAN32.dll C:\WINNT\system32\WINMM.DLL C:\WINNT\system32\WINSPOOL.DRV C:\WINNT\system32\MPR.DLL C:\WINNT\system32\WSOCK32.DLL C:\WINNT\system32\WS2_32.DLL C:\WINNT\system32\WS2HELP.DLL -- Enrico
Re: No automake-1.9 on mingw/msys yet...
Michael Gerz wrote: > Angus Leeming wrote: > >>Right. But almost the same time as the static build for both me and for >>Abdel. IMO, you just got lucky with your machine ;-) > Hmm I will check the link times this week. If you are right, I will > NEVER mention the term STATIC again :-) I suspect our milages will continue to vary. Phase of the moon and some strange dependence on latitude appear to be important. (Works in Germany, not in the UK.) Remember to "configure --disable-stdlib-debug". Makes a huge difference to link times. -- Angus
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming a écrit : Michael Gerz wrote: Note how the bar.h header file forward declares "class Foo;" rather than including foo.h (which it could have done instead). Qt3 tends to forward declare a lot less stuff than Qt4. However, that tends to increase compile times, not link times. The Qt4 link improvements probably lie elsewhere. Hum, I'm no expert in that domain but maybe the linker has to "unique" each and every methods that are defined in the duplicate headers. As mingw gcc 3.4 has no support for precompiled header the linker has to do this triage and this should take time, shouldn't it? (this is a question, I'm really not knowledgeable in that field) Maybe it's just that the mingw linker is not as optimized as the linux one and tends to keep multiple instances of the same code in memory... There is an experimental port of gcc 4 to mingw somewhere (thisiscoolgcc IIRC). It might be worth a try to test if things are better with this and precompiled header. Abdel. Angus
Re: No automake-1.9 on mingw/msys yet...
Michael Gerz a écrit : Beck, Andrew Thomas - BECAT001 wrote: Don't take it personally, but I actually prefer dynamic linking of stuff that is clearly an external library. Especially since it's used by a few things. What's the drama with linking it dynamically? I suspect it might improve link time/memory somewhat. Well, linking dynamically with qtwin and MinGW is so extraordinary slw. (takes hours and an infinite amount of memory) If Abdel is right You put doubt on my sincerity? :-) and qt 4.1 links very fast with MinGW, then qtwin is to blame. Abdel, what do you mean by forward declarations? Do you think we can improve link times by modifying the qtwin sources? I am asking because we had a very good cooperation with Christian Ehrlicher, the maintainer of qtwin, in the past. Maybe he can help us improving the situation. Angus has already explained that very well and I agree that it is not a valuable project. There might be a good side effect: push people in the Qt4.1 direction ;-) Abdel. Michael
Re: No automake-1.9 on mingw/msys yet...
Michael Gerz wrote: > Angus Leeming wrote: > >>Let's be clear: it's a kludge to get decent compile times using the MinGW >>compiler. Let's also be clear: compile times are better for you, but not >>significantly better for me. >> >>Uniting the scripts is a different issue. I'm sure that it's not beyond >>the wit of man to modify development/Win32/packaging/build_lyxwin.sh so >>that there are both static and dynamic routes. Usage: >> >> > Angus, I don't think we have to support both static and dynamic linking. > Maintaing one solution is enough. Let's keep it simple. Shrug. What's hard about it. A little refactoring of a shell script is all that's required. > My problem is that dynamic linking doesn't real work on my machine (at > least it didn't when I tried last time; I will check eventually whether > things have improved recently). If you are able to provide us with a > 1.4.X installer with a shared qtwin lib, I won't complain :-) I'm afraid that I won't able to provide you with anything other than advice. > BTW: What will happen if you install a 1.4 package on a machine that > already has 1.3 installed? Will your installer remove the old version or > can both versions live on the same machine (beside the fact that LyX > files are associated to one of the two versions). Does the > deinstallation routine cope with two versions? At the moment, you can't. As far as I can see, the only problem is the fact that ~\Application Data\LyX has the same name for both packages. If it were called ~\Application Data\LyX\1.3.x or ~\Application Data\LyX\1.4.x then you could install both painlessly. If you were to do that, you'd probably want a third package containing only C:\Program Files\LyXxtras\bin dt2dv.exe dv2dt.exe libiconv-2.dll mingwm10.dll qt-mt3.dll and have the lyx.bat in the 1.3 and 1.4 versions of the LyX package add this directory to the PATH before launching lyx.exe. Hey, wait a minute: isn't that a reason to have the Qt library linked dynamically? ;-) -- Angus
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming wrote: Right. But almost the same time as the static build for both me and for Abdel. IMO, you just got lucky with your machine ;-) Hmm I will check the link times this week. If you are right, I will NEVER mention the term STATIC again :-) As for, "what do you mean by forward declarations", here's an example: Note how the bar.h header file forward declares "class Foo;" rather than including foo.h (which it could have done instead). Qt3 tends to forward declare a lot less stuff than Qt4. However, that tends to increase compile times, not link times. The Qt4 link improvements probably lie elsewhere. I see. But you are right, forward declarations should have no impact on link times. Strange... Michael
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming wrote: Let's be clear: it's a kludge to get decent compile times using the MinGW compiler. Let's also be clear: compile times are better for you, but not significantly better for me. Uniting the scripts is a different issue. I'm sure that it's not beyond the wit of man to modify development/Win32/packaging/build_lyxwin.sh so that there are both static and dynamic routes. Usage: Angus, I don't think we have to support both static and dynamic linking. Maintaing one solution is enough. Let's keep it simple. My problem is that dynamic linking doesn't real work on my machine (at least it didn't when I tried last time; I will check eventually whether things have improved recently). If you are able to provide us with a 1.4.X installer with a shared qtwin lib, I won't complain :-) BTW: What will happen if you install a 1.4 package on a machine that already has 1.3 installed? Will your installer remove the old version or can both versions live on the same machine (beside the fact that LyX files are associated to one of the two versions). Does the deinstallation routine cope with two versions? Michael
Re: No automake-1.9 on mingw/msys yet...
Michael Gerz wrote:
> Beck, Andrew Thomas - BECAT001 wrote:
>
>> Don't take it personally, but I actually prefer dynamic linking of
>> stuff that is clearly an external library. Especially since it's
>> used by a few things. What's the drama with linking it dynamically? I
>> suspect it might improve link time/memory somewhat.
>>
> Well, linking dynamically with qtwin and MinGW is so extraordinary
> slw. (takes hours and an infinite amount of memory)
Right. But almost the same time as the static build for both me and for
Abdel. IMO, you just got lucky with your machine ;-)
> If Abdel is right and qt 4.1 links very fast with MinGW, then qtwin is
> to blame. Abdel, what do you mean by forward declarations? Do you think
> we can improve link times by modifying the qtwin sources? I am asking
> because we had a very good cooperation with Christian Ehrlicher, the
> maintainer of qtwin, in the past. Maybe he can help us improving the
> situation.
Not here I'm afraid. The goal of the Qt/Win project was to add the missing
foo_win.cpp files to the source tree in place of the foo_unix.cpp files
that they already had in the GPL-ed, official Qt3 library. There's no way
they would, or should, start hacking the header files. They'd no longer be
porting the GPL-ed Qt to Windows. They'd be writing a new library.
As for, "what do you mean by forward declarations", here's an example:
bar.h:
class Foo;
class Bar {
public:
Foo make_foo();
};
bar.cpp:
#include "bar.h"
#include "foo.h"
Foo Bar::make_foo()
{
return Foo();
}
Note how the bar.h header file forward declares "class Foo;" rather than
including foo.h (which it could have done instead). Qt3 tends to forward
declare a lot less stuff than Qt4. However, that tends to increase compile
times, not link times. The Qt4 link improvements probably lie elsewhere.
Angus
--
Angus
Re: No automake-1.9 on mingw/msys yet...
Beck, Andrew Thomas - BECAT001 wrote: Don't take it personally, but I actually prefer dynamic linking of stuff that is clearly an external library. Especially since it's used by a few things. What's the drama with linking it dynamically? I suspect it might improve link time/memory somewhat. Well, linking dynamically with qtwin and MinGW is so extraordinary slw. (takes hours and an infinite amount of memory) If Abdel is right and qt 4.1 links very fast with MinGW, then qtwin is to blame. Abdel, what do you mean by forward declarations? Do you think we can improve link times by modifying the qtwin sources? I am asking because we had a very good cooperation with Christian Ehrlicher, the maintainer of qtwin, in the past. Maybe he can help us improving the situation. Michael
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming a écrit : Michael Gerz wrote: I post it from time to time :-) If only I could convince Angus that static linking is much better than dynamic linking. Than the whole LyX/Win family would be united again :-) You can't convince me, because it's not ;-) Let's be clear: it's a kludge to get decent compile times using the MinGW compiler. FYI, dynamic linking with Qt4.1 with full debug (-g) is very quick so I guess it should be possible to reduce this compile times significantly by re-architecturing the Qt3win port (I mean the library, not the frontend) by using more forward declaration. But this is of course beyond the scope of the Lyx project. Let's also be clear: compile times are better for you, but not significantly better for me. Same here. It's unacceptable in both cases because I can't use the computer for many hours (Windows is not very good at multitasking). Abdel Uniting the scripts is a different issue. I'm sure that it's not beyond the wit of man to modify development/Win32/packaging/build_lyxwin.sh so that there are both static and dynamic routes. Usage: sh build_lyxwin.sh static '1.3.7pre9' or sh build_lyxwin.sh dynamic '1.3.7pre9' where '1.3.7pre9' is an optional extra (as now).
Re: No automake-1.9 on mingw/msys yet...
Michael Gerz wrote: > I post it from time to time :-) If only I could convince Angus that > static linking is much better than dynamic linking. Than the whole > LyX/Win family would be united again :-) You can't convince me, because it's not ;-) Let's be clear: it's a kludge to get decent compile times using the MinGW compiler. Let's also be clear: compile times are better for you, but not significantly better for me. Uniting the scripts is a different issue. I'm sure that it's not beyond the wit of man to modify development/Win32/packaging/build_lyxwin.sh so that there are both static and dynamic routes. Usage: sh build_lyxwin.sh static '1.3.7pre9' or sh build_lyxwin.sh dynamic '1.3.7pre9' where '1.3.7pre9' is an optional extra (as now). -- Angus
Re: No automake-1.9 on mingw/msys yet...
Beck, Andrew Thomas - BECAT001 wrote: I've tried this but configure (under mingw) is the failing when it's trying to detect libqt-mt. The test program it's using is linking with heaps of undefined references - to graphics related stuff which I beleive to be in libgdi32, which is being linked. Below is the start of the relevant section in config.log. To confirm, do I just start a cygwin bash shell and run autogen.sh? Yes, at least if you follow my recipe (which is based on static linking). After changing config/qt.m4, you switch to cygwin, execute ./autogen.sh, and return to MinGW. ps I've seen your mingw recipe posted several times. Does this live somewhere, or do you just post it from time to time? I post it from time to time :-) If only I could convince Angus that static linking is much better than dynamic linking. Than the whole LyX/Win family would be united again :-) Michael
Re: No automake-1.9 on mingw/msys yet...
Michael Gerz Wed, 04 Jan 2006 15:14:51 -0800 >Hi Angus, > > >I also noticed that MinGW no longer allows you to build 1.4.0cvs. As a >workaround, I use cygwin's automake >to generate the Makefiles. It works as expected but, of course, it isn't nice >to have to install and use >cygwin in addition to MinGW. Thank god, we ship the final 1.4.0 source >distribution with the auto-generated >files so that the users do not have to run automake by themselves. > >Michael I've tried this but configure (under mingw) is the failing when it's trying to detect libqt-mt. The test program it's using is linking with heaps of undefined references - to graphics related stuff which I beleive to be in libgdi32, which is being linked. Below is the start of the relevant section in config.log. To confirm, do I just start a cygwin bash shell and run autogen.sh? cheers, andrew ps I've seen your mingw recipe posted several times. Does this live somewhere, or do you just post it from time to time? configure:24732: checking for Qt library name configure:24777: g++ -o conftest.exe -g -O -mms-bitfields -I/c/src/qt-3//include -L/c/src/qt-3//lib -Wextra -Wall -L/c/src/qt-3/lib/ -lqt-mt -lqtmain -lglu32 -lkernel32 -luser32 -lgdi32 -lcomdlg32 -ladvapi32 -lshell32 -luuid -limm32 -lwinmm -lopengl32 -lwsock32 -lwinspool -no-undefined -Wl,--export-all-symbols conftest.cc -lm -lqt-mt >&5 c:/src/qt-3/lib/libqt-mt.a(qapplication.o):qapplication.cpp:(.text+0x5159): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication.o):qapplication.cpp:(.text+0x5177): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication.o):qapplication.cpp:(.text+0x51f5): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication.o):qapplication.cpp:(.text+0x5213): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication.o):qapplication.cpp:(.text+0x56b9): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication.o):qapplication.cpp:(.text+0x56d7): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication.o):qapplication.cpp:(.text+0x5755): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication.o):qapplication.cpp:(.text+0x5773): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qfont_win.o):qfont_win.cpp:(.text+0x17f): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qfont_win.o):qfont_win.cpp:(.text+0x31b): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qfont_win.o):qfont_win.cpp:(.text+0x849): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qfont_win.o):qfont_win.cpp:(.text+0x871): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qfont_win.o):qfont_win.cpp:(.text+0xd0e): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qfont_win.o):qfont_win.cpp:(.text+0xeec): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qdragobject.o):qdragobject.cpp:(.text+0x209b): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qdragobject.o):qdragobject.cpp:(.text+0x20ae): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qdragobject.o):qdragobject.cpp:(.text+0x20c1): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qdragobject.o):qdragobject.cpp:(.text+0xaaf0): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qdragobject.o):qdragobject.cpp:(.text+0xab03): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qdragobject.o):qdragobject.cpp:(.text+0xab16): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication_win.o):qapplication_win.cpp:(.text+0x2851): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication_win.o):qapplication_win.cpp:(.text+0x28bd): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication_win.o):qapplication_win.cpp:(.text+0x290a): undefined reference to [EMAIL PROTECTED]' c:/src/qt-3/lib/libqt-mt.a(qapplication_win.o):qapplication_win.cpp:(.text+0x31bb): undefined reference to [EMAIL PROTECTED]'
Re: No automake-1.9 on mingw/msys yet...
Michael Gerz <[EMAIL PROTECTED]> writes: > I also noticed that MinGW no longer allows you to build 1.4.0cvs. As a > workaround, I use cygwin's automake to generate the Makefiles. It works > as expected but, of course, it isn't nice to have to install and use > cygwin in addition to MinGW. Thank god, we ship the final 1.4.0 source > distribution with the auto-generated files so that the users do not have > to run automake by themselves. A MinGW version of both Qt and LyX can be built by using the cygwin g++ with the -mno-cygwin switch. If there is interest I'll post my howto. It is not for the faint-heart, though ;-) -- Enrico
Re: No automake-1.9 on mingw/msys yet...
Angus Leeming wrote: I find that running autogen.sh produces the attached output. Any clues? As things stand, I'm afraid that the port of automake 1.9 to Windows isn't yet ready for prime time. (Hence it isn't part of MSYS yet). That means I can build neither LyX 1.4 nor tex2lyx on Windows using mingw/msys. (This is with an otherwise pristine source tree.) Hi Angus, I also noticed that MinGW no longer allows you to build 1.4.0cvs. As a workaround, I use cygwin's automake to generate the Makefiles. It works as expected but, of course, it isn't nice to have to install and use cygwin in addition to MinGW. Thank god, we ship the final 1.4.0 source distribution with the auto-generated files so that the users do not have to run automake by themselves. Michael
No automake-1.9 on mingw/msys yet...
The latest version of automake available at
http://www.mingw.org/download.shtml
is
msys-automake-1.8.2.tar.bz2
There's also
automake-1.9.5-mingwPORT.tar.bz2
which is essentially a script that enables one to unpack, build and install
the official automake sources from
http://ftp.gnu.org/gnu/automake/
I've done that. Unfortunately, the result is rather sad :( Having removed
the old autom4te.cache, aclocal.m4 and acinclude.m4 from my LyX tree and
modified autogen.sh to point to the new aclocal, automake, so:
#!/bin/sh
ACLOCAL="aclocal-1.9 -I ${PWD}/m4"
AUTOHEADER="autoheader"
AUTOMAKE="automake-1.9 --add-missing --copy --force-missing --foreign"
I find that running autogen.sh produces the attached output.
Any clues?
As things stand, I'm afraid that the port of automake 1.9 to Windows isn't
yet ready for prime time. (Hence it isn't part of MSYS yet). That means I
can build neither LyX 1.4 nor tex2lyx on Windows using mingw/msys. (This is
with an otherwise pristine source tree.)
Angus
autogen.log.bz2
Description: Binary data
