Hi Laurent,
Op 26-05-11 13:26, Laurent Tarrisse schreef:
vcredist_x86 is fixed.
When a do a hg update, I still get the corrupted version of
vcredist_x86.exe,
but maybe that's caused by some kind of cache, or processing time of the
repository?
For now I downloaded the new exe file through the hg web interface.
Now, we use CPack+nsis to create installer : you should do "nmake
package" to create Windows installer.
There is a bug with Boost detection script with release target. This
the patch i use :
Ah, so the "nmake install" is just installing the application to the
local computer?
And nmake package is creating an installation exe with NSIS?
diff -r 671d362c0500 libs/3rdparty/boost/CMakeLists.txt
--- a/libs/3rdparty/boost/CMakeLists.txtThu May 26 13:20:52 2011 +0200
+++ b/libs/3rdparty/boost/CMakeLists.txtThu May 26 13:25:45 2011 +0200
@@ -10,11 +10,11 @@
)
set(boost_LIBRARIES
-${Boost_PROGRAM_OPTIONS_LIBRARY_DEBUG}
-${Boost_SERIALIZATION_LIBRARY_DEBUG}
-${Boost_SIGNALS_LIBRARY_DEBUG}
-${Boost_THREAD_LIBRARY_DEBUG}
-${Boost_DATE_TIME_LIBRARY_DEBUG}
+${Boost_PROGRAM_OPTIONS_LIBRARY_RELEASE}
+${Boost_SERIALIZATION_LIBRARY_RELEASE}
+${Boost_SIGNALS_LIBRARY_RELEASE}
+${Boost_THREAD_LIBRARY_RELEASE}
+${Boost_DATE_TIME_LIBRARY_RELEASE}
CACHE INTERNAL "${PROJECT_NAME} libraries"
)
I was already looking for this.
That's propably the cause of the difference between the
boost_thread-vc90-mt-1_46_1.dll and boost_thread-vc90-mt-gd-1_46_1.dll
Then I still missed the msvcr71.dll
I downloaded that one from
http://www.dll-files.com/dllindex/dll-files.shtml?msvcr71
this is a problem we should not rely anymore on msvcr71.dll
Do you know what's causing the dependency?
And how can I get rid of it?
Thnx,
Robert Verspuy
--
*Exa-Omicron*
Patroonsweg 10
3892 DB Zeewolde
Tel.: 088-OMICRON (66 427 66)
http://www.exa-omicron.nl
_______________________________________________
QuteCom-dev mailing list
[email protected]
http://lists.qutecom.org/mailman/listinfo/qutecom-dev
