From: MARTIN P. <hic...@gm...> - 2012-05-15 16:06:02
|
Hello list readers, i have successfully managed to compile Qt IFW with MinGW-w64. i will submit the set of patches to the maintainers, as they requested. However, once compiled, i have an error when starting any of the generated binary: "The procedure entry point _wsopen_s could not be located in the dynamic link library msvcrt.dll." i read on the internet that this can occur when replacing the msvcrt.dll file with a third-party one. So my question is, is MinGW-w64 having anything to do with this problem, or should i look somewhere else? Thank you, Pierre. |
From: Kai T. <kti...@go...> - 2012-05-15 16:20:08
|
2012/5/15 MARTIN Pierre <hic...@gm...>: > Hello list readers, > > i have successfully managed to compile Qt IFW with MinGW-w64. > i will submit the set of patches to the maintainers, as they requested. > However, once compiled, i have an error when starting any of the > generated binary: > "The procedure entry point _wsopen_s could not be located in the dynamic link library msvcrt.dll." This symbol isn't present for older msvcrt.dll versions. Means this issue can happen on OS versions of Windows, where the msvcrt.dll doesn't provide this export. What OS you were actual here using? Regards, Kai |
From: MARTIN P. <hic...@gm...> - 2012-05-15 16:24:56
|
Hi Kai, > This symbol isn't present for older msvcrt.dll versions. Means this > issue can happen on OS versions of Windows, where the msvcrt.dll > doesn't provide this export. What OS you were actual here using? Hm. This would make sense but note the following: when compiling the same program with MSVC, there is no error at all. i'm using Windows XP Pro (32 bits). Thanks Kai. Pierre. |
From: Ozkan S. <se...@gm...> - 2012-05-15 16:29:53
|
On 5/15/12, MARTIN Pierre <hic...@gm...> wrote: > Hi Kai, > >> This symbol isn't present for older msvcrt.dll versions. Means this >> issue can happen on OS versions of Windows, where the msvcrt.dll >> doesn't provide this export. What OS you were actual here using? > Hm. This would make sense but note the following: when compiling > the same program with MSVC, there is no error at all. i'm using With MSVC it won't error, because MSVC >= 2005 link to msvcr80.dll or newer which provides that export, whereas msvcrt.dll need not. > Windows XP Pro (32 bits). > > Thanks Kai. > Pierre. > -- O.S. |
From: Kai T. <kti...@go...> - 2012-05-15 16:30:59
|
2012/5/15 MARTIN Pierre <hic...@gm...>: > Hi Kai, > >> This symbol isn't present for older msvcrt.dll versions. Means this >> issue can happen on OS versions of Windows, where the msvcrt.dll >> doesn't provide this export. What OS you were actual here using? > Hm. This would make sense but note the following: when compiling > the same program with MSVC, there is no error at all. i'm using > Windows XP Pro (32 bits). > > Thanks Kai. > Pierre. Well, that isn't surprising, as VC doesn't use msvcrt.dll from OS. It provides its own msvcr??.dll version by of course contains this symbol. You can build your application with gcc also for different runtime-library, but you have to specify it manually. Also be aware that more modern runtimes need manifest-files to let the application start. Regards, Kai |
From: MARTIN P. <hic...@gm...> - 2012-05-15 18:15:30
|
Kai, > Well, that isn't surprising, as VC doesn't use msvcrt.dll from OS. It > provides its own msvcr??.dll version by of course contains this > symbol. Understood. > You can build your application with gcc also for different > runtime-library, but you have to specify it manually. Also be aware > that more modern runtimes need manifest-files to let the > application start. i will try to get it to compile against the 8.0 version then. There is something i don't understand tho: When compiling my application, let's say it calls _wsopen_s. The compiler looks in the .h, and finds the definition. Then, the linker looks in the .a of msvcrt, and here is my problem, why isn't it warning about anything? Would it mean that the msvcrt.a from MinGW-w64 has the _wsopen_s function, while in fact it is not present in the msvcrt DLL from the system? Also, when i usually ship the application to a customer, the only thing i give along with the installer is the VC++ runtimes. Would that also mean that the VC++ runtimes contains the required version of the msvcr80.dll? In this case, wouldn't be the job of the MinGW runtime to export the right fonctions at compile time, and warn with linker errors when they cannot be found? Thanks for explaining, this is very interesting. Pierre. |
From: MARTIN P. <hic...@gm...> - 2012-05-15 18:53:30
|
Dear list readers, Related to the msvcrXX.dll problem i have, i'm trying to understand how to tell my toolchan that i'll be willing to use msvcr80. So i found this page: http://www.mingw.org/wiki/SpecsFileHOWTO wich is talking about modifying the specs of gcc. However, something is unclear and really hardly findable on the net. As i'm compiling the Qt IFW project, i have to use the QMake build system for makefiles generation. Right now, i'm not sure if i would have to change the makefiles once they are generated by QMake, or if i would have to change something in Qt's mkspecs (i'm using the default win32-g++ one), or even if i would create a GCC-specific specs file that would override the defaults it uses. Clearly, i can see right now that GCC is using msvcrt thanks to the output of "gcc -dumpspecs": *libgcc: %{mthreads:-lmingwthrd} -lmingw32 %{shared-libgcc:-lgcc_s} %{!shared-libgcc:-lgcc_eh} -lgcc -lmoldname -lmingwex -lmsvcrt But now, let's say i dump the whole specs to a file, and then i change this file. The HOWTO page says that later when building a program, gcc can be invoked with the -specs="my_new_specs_path" option. Would that be the way that is the best for such case? The thing is, once i'll be done with this investigation, i would like to submit all the changes to the Qt IFW project, and i'm not sure if a GCC specs file is a good idea at all. So instead, is there a way to change specs on a value-basis? For instance, in the Qt IFW project files, i could say: GCC += "-specs=/mingw/msvcr80_specs", but this would involve an external file to be made. i would rather like to be able to do something like: GCC += "-specs-override-libgcc=-lmsvcr80" which would override the default msvcrt to msvcr80. Is there such per-value override, or anything allowing to change the specs "on-the-fly" without an external full specs file? Not sure if i'm being clear enough. Thanks for your guidance, Pierre. |
From: Kai T. <kti...@go...> - 2012-05-15 18:54:18
|
2012/5/15 MARTIN Pierre <hic...@gm...>: > Kai, > >> Well, that isn't surprising, as VC doesn't use msvcrt.dll from OS. It >> provides its own msvcr??.dll version by of course contains this >> symbol. > Understood. > >> You can build your application with gcc also for different >> runtime-library, but you have to specify it manually. Also be aware >> that more modern runtimes need manifest-files to let the >> application start. > i will try to get it to compile against the 8.0 version then. > > There is something i don't understand tho: > When compiling my application, let's say it calls _wsopen_s. > The compiler looks in the .h, and finds the definition. Then, > the linker looks in the .a of msvcrt, and here is my problem, > why isn't it warning about anything? Neither the linker nor the compiler can know on what OS this application might be executed. It is perfectly valid to build a Windows 64-bit application on a 32-bit Windows OS by using one of our cross-compilers. Also it is possible to build a 32-bit application by our toolchain on a Win2000 OS, but exectute it on Vista, etc. So there is no way to detect this and no valid way to warn about it. > Would it mean that the > msvcrt.a from MinGW-w64 has the _wsopen_s function, while > in fact it is not present in the msvcrt DLL from the system? Our import-library provides this export. For 64-bit OS this export is always present, so we didn't noticed this issue. But as this function is present at least beginning with VC 2005 it should be supported by XP's msvcrt.dll version. > Also, when i usually ship the application to a customer, the > only thing i give along with the installer is the VC++ runtimes. > Would that also mean that the VC++ runtimes contains the > required version of the msvcr80.dll? yes > In this case, wouldn't be the job of the MinGW runtime to export > the right fonctions at compile time, and warn with linker errors > when they cannot be found? Again, if this function is present on the final OS used to execute the built application isn't detectable and it is no good to check build OS, if there this export is present. If you want to make sure that export is always present you need to build you application against msvcr??.dll instead of msvcrt.dll. > Thanks for explaining, this is very interesting. > Pierre. Regards, Kai |
From: Kai T. <kti...@go...> - 2012-05-15 18:58:23
|
2012/5/15 MARTIN Pierre <hic...@gm...>: > Dear list readers, > > Related to the msvcrXX.dll problem i have, i'm trying to understand > how to tell my toolchan that i'll be willing to use msvcr80. > So i found this page: http://www.mingw.org/wiki/SpecsFileHOWTO > wich is talking about modifying the specs of gcc. > > However, something is unclear and really hardly findable > on the net. As i'm compiling the Qt IFW project, i have to > use the QMake build system for makefiles generation. Right > now, i'm not sure if i would have to change the makefiles once > they are generated by QMake, or if i would have to change > something in Qt's mkspecs (i'm using the default win32-g++ one), > or even if i would create a GCC-specific specs file that would > override the defaults it uses. > > Clearly, i can see right now that GCC is using msvcrt thanks to > the output of "gcc -dumpspecs": > *libgcc: > %{mthreads:-lmingwthrd} -lmingw32 %{shared-libgcc:-lgcc_s} %{!shared-libgcc:-lgcc_eh} -lgcc -lmoldname -lmingwex -lmsvcrt > > But now, let's say i dump the whole specs to a file, and then i change > this file. The HOWTO page says that later when building a program, > gcc can be invoked with the -specs="my_new_specs_path" option. > > Would that be the way that is the best for such case? The thing is, > once i'll be done with this investigation, i would like to submit all the > changes to the Qt IFW project, and i'm not sure if a GCC specs file > is a good idea at all. So instead, is there a way to change specs on > a value-basis? For instance, in the Qt IFW project files, i could say: > GCC += "-specs=/mingw/msvcr80_specs", but this would involve > an external file to be made. i would rather like to be able to do > something like: > GCC += "-specs-override-libgcc=-lmsvcr80" > which would override the default msvcrt to msvcr80. Is there such > per-value override, or anything allowing to change the specs "on-the-fly" > without an external full specs file? > > Not sure if i'm being clear enough. > > Thanks for your guidance, > Pierre. Well, you can use .spec file to change default link-library. This is for sure something for the advanced user of gcc. I would recomment that you just take care that on link-command the last user-specified library is '-lmsvcr??' (where ?? is the desired version number). Be aware that you might need now a manifest-file to launch your application. Of course it is better to use for one application everywhere the same C runtime-library. Therefore also the DLLs should be linked against the same msvcr??.dll, too. Regards, Kai |
From: MARTIN P. <hic...@gm...> - 2012-05-15 20:15:48
|
Dear Kai, Ozkan, and those reading regarding this msvcrt problem, As i was investigating more and more about the implications of tweaking the specs of GCC and then having to embed a manifest into the binaries generated by the Qt IFW project, i finally choosed to count the functions that were not present in msvcrt. The total was 5. So, i decided to use the (unsafe) older version of each function. wcsncpy_s became wcsncpy, _wsopen_s went back to the old wopen_w, and that was pretty much it for the whole changes. Thank you very much for your guidance, i now have the Qt IFW package compiling with the MinGW-w64 toolchain. i will submit them a list of changes i have made. Pierre. |
From: niXman <i.n...@gm...> - 2012-05-15 20:22:09
|
2012/5/16 MARTIN Pierre: > ... binaries generated by the Qt IFW project I apologize for my two cents, but tell me please, what 'Qt IFW' the project is? Thanks! -- Regards, niXman _______________________________________________ my MinGW builds: http://sourceforge.net/projects/mingwbuilds/ |
From: MARTIN P. <hic...@gm...> - 2012-05-15 20:25:11
|
> I apologize for my two cents, but tell me please, what 'Qt IFW' the project is? It is a very interesting project (Qt IFW stands for Installer Framweork). i'm able to build installer that can check for updates online against XML files that you craft with your different component information. |
From: MARTIN P. <hic...@gm...> - 2012-05-15 20:28:13
|
>> I apologize for my two cents, but tell me please, what 'Qt IFW' the project is? > It is a very interesting project (Qt IFW stands for Installer Framweork). i'm able > to build installer that can check for updates online against XML files that you > craft with your different component information. Sorry, i have sent the email unexpectedly. So you can get informations about Qt IFW here: http://doc.qt.nokia.com/qtifw-1.2/index.html It is under the same license Qt is (LGPL 2 i think), and it is of course part of the Nokia's (Old Trolltech) Qt projects. If you would like to know a bit more about it, i could send you my Qt IFW project files off-list. Bye, Pierre. |
From: JonY <jo...@us...> - 2012-05-15 22:06:34
Attachments:
signature.asc
|
On 5/16/2012 02:54, Kai Tietz wrote: > 2012/5/15 MARTIN Pierre <hic...@gm...>: >> Kai, >> >>> Well, that isn't surprising, as VC doesn't use msvcrt.dll from OS. It >>> provides its own msvcr??.dll version by of course contains this >>> symbol. >> Understood. >> >>> You can build your application with gcc also for different >>> runtime-library, but you have to specify it manually. Also be aware >>> that more modern runtimes need manifest-files to let the >>> application start. >> i will try to get it to compile against the 8.0 version then. >> Use MSVCR100, you don't need to deal with manifests there, MS finally dropped it. >> There is something i don't understand tho: >> When compiling my application, let's say it calls _wsopen_s. >> The compiler looks in the .h, and finds the definition. Then, >> the linker looks in the .a of msvcrt, and here is my problem, >> why isn't it warning about anything? > Neither the linker nor the compiler can know on what OS this > application might be executed. It is perfectly valid to build a > Windows 64-bit application on a 32-bit Windows OS by using one of our > cross-compilers. Also it is possible to build a 32-bit application by > our toolchain on a Win2000 OS, but exectute it on Vista, etc. So > there is no way to detect this and no valid way to warn about it. > >> Would it mean that the >> msvcrt.a from MinGW-w64 has the _wsopen_s function, while >> in fact it is not present in the msvcrt DLL from the system? > Our import-library provides this export. For 64-bit OS this export is > always present, so we didn't noticed this issue. But as this function > is present at least beginning with VC 2005 it should be supported by > XP's msvcrt.dll version. > XP msvcrt is equivalent to MSVC2003, so it's not there yet. >> Also, when i usually ship the application to a customer, the >> only thing i give along with the installer is the VC++ runtimes. >> Would that also mean that the VC++ runtimes contains the >> required version of the msvcr80.dll? > yes Likewise if you use msvcr100, look for the MSVC2010 runtime. |
From: MARTIN P. <hic...@gm...> - 2012-05-15 23:03:33
|
> Use MSVCR100, you don't need to deal with manifests there, MS finally > dropped it. Phew! Very good news. i will keep that in mind for my own projects, as i would like to avoid making Qt IFW change to their project files. Thanks JonY! Yet another good piece information :) Pierre. |