Can I apply this patch? We (Enrico and me) have verified it improves
linking time considerably and makes no harm for those platform:
- cygwin/Qt3
- cygwin-X11/Qt3
- mingw-win32/Qt3
- mingw-win32/Qt4
Abdel.
PS: my libiconv/libtool problem was not related to this but to my mixed
cygwin/mingw setting. I have verified that everything is OK with
Msys/Mingw. The only drawback is that we have to distribute libiconv.dll
with lyx. Actually, I think this is a good thing to link dynamically
wherether we can.
Abdelrazak Younes a écrit :
Abdelrazak Younes a écrit :
Enrico Forestieri a écrit :
On Wed, Apr 12, 2006 at 02:45:00PM +0200, Abdelrazak Younes wrote:
Enrico Forestieri a écrit :
That's -Wl,--export-all-symbols and simply passes
--export-all-symbols
to the linker. It does no good and simply will increase your linking
time. I suggest that you get rid of it.
[..]
I was not talking about the warnings, sorry for the confusion.
What I said only applies to the final link step. I observed that
with -Wl,--export-all-symbols, the linking time noticeably increases.
Removing that option shortens the linking time for me without any
side effect.
This is a sed command you can use to modify configure in order to
avoid "-Wl,--export-all-symbols" in LDFLAGS:
sed ' # Omit -Wl,--export-all-symbols in LDFLAGS
/LDFLAGS=\"\$LDFLAGS
\$WIN32_LD_EXPORT_ALL_SYMBOLS\"/s/LDFLAGS/true\t\#LDFLAGS/' \
./configure > ./configure-new
Wouldn't it be better to integrate that fix in the m4 macros? If in
there that is...
Perhaps... But I am not going to propose that, as I have to save
energy for other battles... ;-)
Well, if it can help the production of lyx dynamically linked with Qt3
that would be great because as it is now the linking time is close to
unbearable. I'll try to test if there's any improvement.
It seems to :-)
ar+ranlib libqt2 was done in 10 minutes and less than 400 Megs.
final exe linking took less than 10 minutes and less than 400 Megs
But, I had to modify the finale linking command because for whatever
reason it tried to link with "/usr/lib/libiconv.dll.a" which of course
does not exists. Correcting that to d:/mingw/lib/iconv.lib did the
trick! I am sure this is due to this patch or to something else.
The resulting qt3 executable seems to work as usual, I can see no
difference. No need to say that this is a _huge_ improvement!
As cited below, Enrico tested on cygwin and cygwin/X11 that this patch
does not cause any problem. So I would like to ask Angus principally his
opinion on this. If Kayvan could also tell us his reason for putting
that at the first place, that would be great.
Abdel.
Then, I don't know if this flag is going to help when dynamically
linking Qt, as I must link statically to it. For sure it doesn't
help when dinamically linking the X11 libs or any other library
(I just finished successfully building an X11 version of LyX/Cygwin
without that option and dynamically linking to libAiksaurus,
libaspell, libiconv, libXrandr, libXcursor, libXft, libXrender,
libfontconfig, libfreetype, libexpat, libXext, libSM, libICE,
libX11: The gain in linking time is awesome).
------------------------------------------------------------------------
Index: config/cygwin.m4
===================================================================
--- config/cygwin.m4 (revision 13592)
+++ config/cygwin.m4 (working copy)
@@ -7,16 +7,6 @@
cygwin* | mingw* | pw32* )
# Export all symbols to Win32 DLL using MinGW 2.0 ld.
WIN32_LD_EXPORT_ALL_SYMBOLS=''
- AC_MSG_CHECKING([whether ld accepts --export-all-symbols])
- if $LD --help 2>&1 | egrep 'export-all-symbols' > /dev/null; then
- WIN32_LD_EXPORT_ALL_SYMBOLS='-Wl,--export-all-symbols'
- AC_MSG_RESULT([yes])
- else
- AC_MSG_RESULT([no])
- fi
- if test x"$WIN32_LD_EXPORT_ALL_SYMBOLS" != x; then
- LDFLAGS="$LDFLAGS $WIN32_LD_EXPORT_ALL_SYMBOLS"
- fi
;;
esac
])
