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
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
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
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
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
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
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
> "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
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
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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,
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
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.
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
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
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.
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
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
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
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
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
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
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
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
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,
> "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
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
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
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
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
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,
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
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
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.
46 matches
Mail list logo
