- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi all,
I've started started working with the audo-video-codec in the ipp-samples. I want to generate both ia32 and em64t versions of the libraries under WinXP using Intel C++ Pro 11 which includes IPP 6.0 Update 1. I have this much working with the included batch and make files (even after.svn directories have been introduced - that was interesting). What I would like to know is if it's safe to specify /MT instead of /MD and if I can use the UNICODE preprocessor definition so that the wchar_t is used by default. Does anyone have experience with the UMC libs building with /MT and UNICODE?
Thanks,
Peter
I've started started working with the audo-video-codec in the ipp-samples. I want to generate both ia32 and em64t versions of the libraries under WinXP using Intel C++ Pro 11 which includes IPP 6.0 Update 1. I have this much working with the included batch and make files (even after.svn directories have been introduced - that was interesting). What I would like to know is if it's safe to specify /MT instead of /MD and if I can use the UNICODE preprocessor definition so that the wchar_t is used by default. Does anyone have experience with the UMC libs building with /MT and UNICODE?
Thanks,
Peter
Link Copied
2 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Peter,
it should be safe to build UMC libraries with UNICODE support and we actually do this for internal build. To be honest I'm surprised that it is not a case in released package. The reason might be that UMC applications were not designed for that purpose (but it should be easy to modify on your side).
I also do not expect troubles with using static multithreaded runtime for UMC libraries (you need just ensure that application you will link with also use that version of C run-time libs).
Regards,
Vladimir
it should be safe to build UMC libraries with UNICODE support and we actually do this for internal build. To be honest I'm surprised that it is not a case in released package. The reason might be that UMC applications were not designed for that purpose (but it should be easy to modify on your side).
I also do not expect troubles with using static multithreaded runtime for UMC libraries (you need just ensure that application you will link with also use that version of C run-time libs).
Regards,
Vladimir
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Quoting - Vladimir Dudnik (Intel)
Hi Peter,
it should be safe to build UMC libraries with UNICODE support and we actually do this for internal build. To be honest I'm surprised that it is not a case in released package. The reason might be that UMC applications were not designed for that purpose (but it should be easy to modify on your side).
I also do not expect troubles with using static multithreaded runtime for UMC libraries (you need just ensure that application you will link with also use that version of C run-time libs).
Regards,
Vladimir
it should be safe to build UMC libraries with UNICODE support and we actually do this for internal build. To be honest I'm surprised that it is not a case in released package. The reason might be that UMC applications were not designed for that purpose (but it should be easy to modify on your side).
I also do not expect troubles with using static multithreaded runtime for UMC libraries (you need just ensure that application you will link with also use that version of C run-time libs).
Regards,
Vladimir
Thanks Vladimir.
Peter
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page