From: MARTIN P. <hic...@gm...> - 2012-04-15 10:50:11
|
Hello list users, i have tried posting this week to this list via the web tool, but the message did get rejected (The original message is below). i have been searching to make myself able to use delay-loaded libraries under windows, compiled with MinGW. My problem is that upon link, i get the message that __delayLoadHelper2@8 isn't defined. i understand that i am supposed to provide a delay-loading function to the linker, which would be defined in a delayimp static library (man dlltool). However and as far as i understand the problem, i'm unable to find where this implementation is, or if it even exists yet. i remember using "DelayImp.lib" with the microsoft cl compiler, but i have no idea what would be the equivalent with MinGW. Is there anyone here who can help me finding an implementation of the "static library" dlltool makes reference too please? From the man page: "If the -y option is specified, dlltool generates a delay-import library that can be used instead of the normal import library to allow a program to link to the dll only as soon as an imported function is called for the first time. The resulting executable will need to be linked to the static delayimp library containing __delayLoadHelper2(), which in turn will import LoadLibraryA and GetProcAddress from kernel32." Thanks a lot for your help, Pierre. ------ Original message: Hello everyone, i'm very to new to this forum. The reason is that until a few days ago, i was only using vanilla GCC / LLVM on my Mac, and MS compilers on windows. Until i got bored of the microsoft compiler, and gave mingw toolchain a try :) So far, i'm very happy with Mingw toolchain! It is doing it's job very nicely, and i must say, it is clearly more performant than MS counterpart when it comes to "minimal rebuilding" of projects. There is one point however which is very embarrassing for me. On Mac / Linux, i used to use the linker's -lazy-liconv" for instance, to avoid loading libraries that were not being called. On the microsoft compiler, just adding a /DELAYLOAD:libiconv.dll was sufficient. Now i'm a bit confused, because i am at the point that i have searched everywhere on the internet, and i'm afraid to understand that such functionality doesn't exist "out-of-the-box" with MinGW. Is that true? i have seen an option of dlltool (-y switch), but i'm not sure if it's related, and i find myself unable to seek any more documentation and examples on the matter. Would it be here a kind-enough mate to point me to the right direction to either use existing tools to achieve this goal, or to help me find educative simple source-code about all those delay helper loaders for my libraries? Thanks a lot for your time! Pierre. |
From: Kai T. <kti...@go...> - 2012-04-15 15:00:37
|
Hi Pierre, 2012/4/15 MARTIN Pierre <hic...@gm...>: > Hello list users, > > i have tried posting this week to this list via the web tool, but the > message did get rejected (The original message is below). > i have been searching to make myself able to use delay-loaded libraries > under windows, compiled with MinGW. > My problem is that upon link, i get the message that __delayLoadHelper2@8 > isn't defined. > i understand that i am supposed to provide a delay-loading function to the > linker, which would be defined in a delayimp static library (man dlltool). > However and as far as i understand the problem, i'm unable to find where > this implementation is, or if it even exists yet. > i remember using "DelayImp.lib" with the microsoft cl compiler, but i have > no idea what would be the equivalent with MinGW. > > Is there anyone here who can help me finding an implementation of the > "static library" dlltool makes reference too please? From the man page: > "If the -y option is specified, dlltool generates a delay-import library > that can be used instead of the normal import library to allow a program to > link to the dll only as soon as an imported function is called for the first > time. The resulting executable will need to be linked to the > static delayimp library containing __delayLoadHelper2(), which in turn will > import LoadLibraryA and GetProcAddress from kernel32." > > Thanks a lot for your help, > Pierre. > > > ------ Original message: > Hello everyone, > > i'm very to new to this forum. The reason is that until a few days ago, i > was only using vanilla GCC / LLVM on my Mac, and MS compilers on windows. > Until i got bored of the microsoft compiler, and gave mingw toolchain a try > :) > > So far, i'm very happy with Mingw toolchain! It is doing it's job very > nicely, and i must say, it is clearly more performant than MS counterpart > when it comes to "minimal rebuilding" of projects. > > There is one point however which is very embarrassing for me. On Mac / > Linux, i used to use the linker's -lazy-liconv" for instance, to avoid > loading libraries that were not being called. On the microsoft compiler, > just adding a /DELAYLOAD:libiconv.dll was sufficient. > > Now i'm a bit confused, because i am at the point that i have searched > everywhere on the internet, and i'm afraid to understand that such > functionality doesn't exist "out-of-the-box" with MinGW. Is that true? i > have seen an option of dlltool (-y switch), but i'm not sure if it's > related, and i find myself unable to seek any more documentation and > examples on the matter. > > Would it be here a kind-enough mate to point me to the right direction to > either use existing tools to achieve this goal, or to help me find educative > simple source-code about all those delay helper loaders for my libraries? MinGW.org toolchain doesn't provide this feature. You need to use mingw-w64's runtime for having an implementation for it. Regards, Kai |
From: MARTIN P. <hic...@gm...> - 2012-04-15 20:25:51
|
Hello Kai, and thank you for your help, > MinGW.org toolchain doesn't provide this feature. You need to use > mingw-w64's runtime for having an implementation for it. Very interesting. the thing is, i'm building on Windows XP Pro 32 bits. Would there be any kind of trick to make the 64 bit version of the toolchain to work on this system? The other possibility would be to set up a cross-compilation toolchain directly on my Mac, but i'm not sure if it would be doable. Is there anyone successfull on any of those possibilities? Or is there anything else i can do that i'm missing? Again, thank you! Best regards, Pierre. |
From: Kai T. <kti...@go...> - 2012-04-15 20:43:57
|
2012/4/15 MARTIN Pierre <hic...@gm...>: > Hello Kai, and thank you for your help, > >> MinGW.org toolchain doesn't provide this feature. You need to use >> mingw-w64's runtime for having an implementation for it. > Very interesting. the thing is, i'm building on Windows XP Pro 32 bits. Would there be any kind of trick to make the 64 bit version of the toolchain to work on this system? The other possibility would be to set up a cross-compilation toolchain directly on my Mac, but i'm not sure if it would be doable. > Is there anyone successfull on any of those possibilities? Or is there anything else i can do that i'm missing? The mingw-w64 toolchain supports 64-bit and 32-bit. Windows XP is supported. So you just need to download a 32-bit targetting version. Regards, Kai |
From: MARTIN P. <hic...@gm...> - 2012-04-15 21:00:35
|
Hello again Kai, > The mingw-w64 toolchain supports 64-bit and 32-bit. Windows XP is supported. > So you just need to download a 32-bit targetting version. Ok. So right now the best entry point i have found is this one: http://stellarium.org/wiki/index.php/CompileWithMinGW-w64 Would you recommend it as accurate? It says to get a MSYS copy ready (Which i actually already have from my previous MinGW install), and then get MinGW-w64 working on top of it. It sounds very easy, i just hope the virtual machine i'm using will have enough RAM to compile Qt with MinGW-w64, as i read in a few places that this version of ld can be memory-hungry. Thanks a lot, i'll post back when i'll be successful, or if i find any gotchas. Pierre. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 12:18:40
|
Hello Kai, > The mingw-w64 toolchain supports 64-bit and 32-bit. Windows XP is supported. > So you just need to download a 32-bit targetting version. i've been trying real hard to get things up and running, with really no luck. So far, what i have done is: - Downloaded and untarred the mingw-w64 package compiled by SeZero to C:\MinGW - Download the msys binary package (As described here: http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS), then ran the postinstall script. My MinGW installation is mounted in /mingw without problem. - Then, and as (one of) the software i'm trying to build requires aclocal / autoconf / automake / libtool, i headed to http://gnuwin32.sourceforge.net/packages.html and downloaded each of them (i tried both the binary version, which has C:/Progra~1/* hard-coded paths, so it's not working for me, as well as the sources versions, but most of them just won't compile). My question is now, is there a "ready-to-use" MSys package for mingw-w64 with more unix tools than the regular one offered in the wiki page, allowing me to use automake, autoconf etc? PS: i believe my mingw-w64 install itself has no problem at all, because i was able to compile Qt 4.8.1 without much problems, except that the makefiles were using the findutils package which isn't in the mingw-w64 MSys package, and it was using the windows FIND binary without success because of the very different parameters it was passing to it. So i directly installed the findutils into my MSys/bin folder. Then, i tried again to compile Qt, but it didn't work because of invalid symlinks paths. So i just compiled Qt without MSys, just using the regular windows command line. Thank you, Pierre. |
From: JonY <jo...@us...> - 2012-04-16 12:34:59
Attachments:
signature.asc
|
On 4/16/2012 20:18, MARTIN Pierre wrote: > Hello Kai, > >> The mingw-w64 toolchain supports 64-bit and 32-bit. Windows XP is supported. >> So you just need to download a 32-bit targetting version. > i've been trying real hard to get things up and running, with really no luck. > So far, what i have done is: > - Downloaded and untarred the mingw-w64 package compiled by SeZero to C:\MinGW > - Download the msys binary package (As described here: http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS), then ran the postinstall script. My MinGW installation is mounted in /mingw without problem. > - Then, and as (one of) the software i'm trying to build requires aclocal / autoconf / automake / libtool, i headed to http://gnuwin32.sourceforge.net/packages.html and downloaded each of them (i tried both the binary version, which has C:/Progra~1/* hard-coded paths, so it's not working for me, as well as the sources versions, but most of them just won't compile). > Don't use gnuwin32 if you can help it, most of the packages are very old and have hard coded paths as you have seen. > My question is now, is there a "ready-to-use" MSys package for mingw-w64 with more unix tools than the regular one offered in the wiki page, allowing me to use automake, autoconf etc? > > PS: i believe my mingw-w64 install itself has no problem at all, because i was able to compile Qt 4.8.1 without much problems, except that the makefiles were using the findutils package which isn't in the mingw-w64 MSys package, and it was using the windows FIND binary without success because of the very different parameters it was passing to it. So i directly installed the findutils into my MSys/bin folder. Then, i tried again to compile Qt, but it didn't work because of invalid symlinks paths. So i just compiled Qt without MSys, just using the regular windows command line. > You can use mingw-get to install MSYS (with autoconf/automake/libtool), I'm not sure if you can skip the regular mingw parts. If you don't mind using Cygwin, there is already a mingw-w64 cross compiler in the Cygwin setup.exe, likewise for autoconf/automake/libtool, you don't need to do any extra configuration. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 12:53:08
|
Hello again JonY, > Don't use gnuwin32 if you can help it, most of the packages are very old > and have hard coded paths as you have seen. > If you don't mind using Cygwin, there is already a mingw-w64 cross > compiler in the Cygwin setup.exe, likewise for > autoconf/automake/libtool, you don't need to do any extra configuration. i'm downloading all those packages i need right now via the cygwin installer, and i have to say i'm really impressed by the diversity of the binary packages available in the cygwin mirrors. i hope this will be the right starting point for me, and that i will be able to compile my things after... it's really too bad that no delayimp is available with the regular mingw, i was pretty happy with it :) Thanks again for your valuable knowledge! Pierre. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 12:42:48
|
Hello again list users, and JonY > You can use mingw-get to install MSYS (with autoconf/automake/libtool), > I'm not sure if you can skip the regular mingw parts. Then i might be missing something here. i thought mingw-get wasn't available, at least it is not present in the package i downloaded here: http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS Is the regular msys installation compatible with a mingw-w64 environement? Is mingw-w32 the same as mingw or are those two different project as i think i understood? > If you don't mind using Cygwin, there is already a mingw-w64 cross > compiler in the Cygwin setup.exe, likewise for > autoconf/automake/libtool, you don't need to do any extra configuration. Good to know. i'm trying right now. What would be the pros / cons for switching to Cygwin, are there any gotchas i should be aware of? Thank you again for your kind help, and sorry for this global misunderstanding... it's kind of difficult to understand what is what, what project is or isn't the same as another, etc. Pierre. |
From: Vincent T. <vin...@gm...> - 2012-04-16 13:00:05
|
hey On Mon, Apr 16, 2012 at 2:18 PM, MARTIN Pierre <hic...@gm...> wrote: > Hello Kai, > >> The mingw-w64 toolchain supports 64-bit and 32-bit. Windows XP is supported. >> So you just need to download a 32-bit targetting version. > i've been trying real hard to get things up and running, with really no luck. > So far, what i have done is: > - Downloaded and untarred the mingw-w64 package compiled by SeZero to C:\MinGW > - Download the msys binary package (As described here: http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS), then ran the postinstall script. My MinGW installation is mounted in /mingw without problem. > - Then, and as (one of) the software i'm trying to build requires aclocal / autoconf / automake / libtool, i headed to http://gnuwin32.sourceforge.net/packages.html and downloaded each of them (i tried both the binary version, which has C:/Progra~1/* hard-coded paths, so it's not working for me, as well as the sources versions, but most of them just won't compile). > > My question is now, is there a "ready-to-use" MSys package for mingw-w64 with more unix tools than the regular one offered in the wiki page, allowing me to use automake, autoconf etc? > > PS: i believe my mingw-w64 install itself has no problem at all, because i was able to compile Qt 4.8.1 without much problems, except that the makefiles were using the findutils package which isn't in the mingw-w64 MSys package, and it was using the windows FIND binary without success because of the very different parameters it was passing to it. So i directly installed the findutils into my MSys/bin folder. Then, i tried again to compile Qt, but it didn't work because of invalid symlinks paths. So i just compiled Qt without MSys, just using the regular windows command line. > i usually use the MinGW installer (MSYS + MinGW) [1], untar a mingw-w64 tarball somewhere (no space in the PATH, as usual), update PATH in /etc/profile to point to the bin/ subdir of mingw-w64, and it works perfectly. regards Vincent Torri [1] http://sourceforge.net/projects/mingw/files/Installer/mingw-get-inst/ |
From: MARTIN P. <hic...@gm...> - 2012-04-16 13:14:32
|
Dear Tony, > i usually use the MinGW installer (MSYS + MinGW) [1], untar a > mingw-w64 tarball somewhere (no space in the PATH, as usual), update > PATH in /etc/profile to point to the bin/ subdir of mingw-w64, and it > works perfectly. Interesting, it sounds very simple. Thanks for the tip :) If i'm not successfull using cygwin version, i'll give this one a shot. About the cygwin alternative, i'm having a problem which is probably a tiny one. i have installed all the packages i need, including the mingw64 toolchain. However, when trying to compile (e.g. leptonica), i get an error saying that no acceptable C compiler is in my path. So my question is, do i have to symlink (e.g. i686-w64-mingw32-g++.exe to g++, and basically i686-w64-mingw32-* to their counterparts)? How would a symlink act on windows (i see the ln binary is present, but i'm a bit afraid to use it... i wasn't aware symlinks did actually exist on windows)? Or is there any kind of wrapper i have to install along with my compiler? Or maybe do i have to define CC variable? What do you suggest to be the best? Thanks! Pierre. |
From: JonY <jo...@us...> - 2012-04-16 13:16:05
Attachments:
signature.asc
|
On 4/16/2012 20:42, MARTIN Pierre wrote: > Hello again list users, and JonY > >> You can use mingw-get to install MSYS (with autoconf/automake/libtool), >> I'm not sure if you can skip the regular mingw parts. > Then i might be missing something here. i thought mingw-get wasn't available, at least it is not present in the package i downloaded here: http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS > Is the regular msys installation compatible with a mingw-w64 environement? Is mingw-w32 the same as mingw or are those two different project as i think i understood? > That MSYS is just a repackage of the MSYS downloads available at mingw.org, though its geared for more advanced users who just want to unpack and run it without any installer processes. >> If you don't mind using Cygwin, there is already a mingw-w64 cross >> compiler in the Cygwin setup.exe, likewise for >> autoconf/automake/libtool, you don't need to do any extra configuration. > Good to know. i'm trying right now. What would be the pros / cons for switching to Cygwin, are there any gotchas i should be aware of? > > Thank you again for your kind help, and sorry for this global misunderstanding... it's kind of difficult to understand what is what, what project is or isn't the same as another, etc. > Pierre. > To understand better, mingw-w64 is distinct from regular mingw (sometimes referred to as mingw.org when mingw-w64 is used in context). mingw-w64 is a fork of regular mingw to initially support win64 targeting, but these days, it works fine for targeting win32 too. MSYS is a minimalist emulation of a GNU system, it does the bare minimum to run configure and autotools. It is a fork of an old version of Cygwin. You can run win32 hosted toolchains in MSYS (meaning the toolchain executables are actual win32 executables built with mingw or mingw-w64. Cygwin is aimed at being a more complete Unix emulation system on Windows. The advantage is that it is far more complete than MSYS, anything Unix-ish you need to do in MSYS, you could do with Cygwin. Compared to MSYS, it is far easier to extend Cygwin functionality than MSYS (you have your Cygwin setup repo), since MSYS aims to be minimalist. However, with recent Cygwin versions, path translation behavior is now different from MSYS, no longer automatic, that means regular win32 toolchains built with mingw have problems working under Cygwin, though Cygwin provides a cross compiler for mingw and mingw-w64. With Cygwin you should use Cygwin built cross toolchains. Remember, they are cross compilers, so they add a bit of complexity to non-autotooled buildsystems. The mingw-w64 gcc for win64 target is called x86_64-w64-mingw32-gcc instead of just "gcc" ("gcc" is the toolchain targeting Cygwin, not what you want). See the mingw64-x86_64 packages in the Cygwin setup for a list of mingw-w64 related downloads for working with Win64. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 13:28:53
|
JonY, > To understand better, mingw-w64 is distinct from regular mingw > (sometimes referred to as mingw.org when mingw-w64 is used in context). > mingw-w64 is a fork of regular mingw to initially support win64 > targeting, but these days, it works fine for targeting win32 too. Understood. Will the regular mingw tend to die over time, and mingw-w64 be it's successor then? Shall one company encourage its developers to switch to the later already? > MSYS is a minimalist emulation of a GNU system, it does the bare minimum > to run configure and autotools. It is a fork of an old version of > Cygwin. You can run win32 hosted toolchains in MSYS (meaning the > toolchain executables are actual win32 executables built with mingw or > mingw-w64. > Cygwin is aimed at being a more complete Unix emulation system on > Windows. The advantage is that it is far more complete than MSYS, > anything Unix-ish you need to do in MSYS, you could do with Cygwin. > Compared to MSYS, it is far easier to extend Cygwin functionality than > MSYS (you have your Cygwin setup repo), since MSYS aims to be minimalist. Allright, but still a bit foggy: why would one use MSYS then, when Cygwin seems to be more "complete" and mature? > However, with recent Cygwin versions, path translation behavior is now > different from MSYS, no longer automatic, that means regular win32 > toolchains built with mingw have problems working under Cygwin, though > Cygwin provides a cross compiler for mingw and mingw-w64. i believe i pinpointed what you're talking about already. The windows drives (eg. /c/) are no longer available here, but in /cygdrive/c/, is that what youre talking about? Wouldn't a simple mount from /cygdrive/c to /c solve this problem? > With Cygwin you should use Cygwin built cross toolchains. Remember, they > are cross compilers, so they add a bit of complexity to non-autotooled > buildsystems. The mingw-w64 gcc for win64 target is called > x86_64-w64-mingw32-gcc instead of just "gcc" ("gcc" is the toolchain > targeting Cygwin, not what you want). See the mingw64-x86_64 packages in > the Cygwin setup for a list of mingw-w64 related downloads for working > with Win64. Understood. That's probably the origin of my last problem, configure script not being able to find a valid compiler. So i guess i'll just symlink and try again then :) JonY, all those condensed explainations should be made sticky on top of the mingw-w64 project. Like many others, i'm from the Mac / Linux world, where either XCode installs everything for me, or i just aptitude / yum whatever and everything is ready (and i'm aware it's not the best when it comes to later understanding on how things work under the hood). Such explanation would prevent people like me from bugging you guys :) Thanks a huge lot. Pierre. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 14:18:39
|
List users, Tony: >> i usually use the MinGW installer (MSYS + MinGW) [1], untar a >> mingw-w64 tarball somewhere (no space in the PATH, as usual), update >> PATH in /etc/profile to point to the bin/ subdir of mingw-w64, and it >> works perfectly. > Interesting, it sounds very simple. Thanks for the tip :) If i'm not successfull using cygwin version, i'll give this one a shot. i just tried your solution (As i was unable to make cygwin install find the compiler, even after symlinking), and i'm so far able to compile leptonica, and tesseract is compiling right now (Which means that configure worked, and that automake / autoconf / libtoolize were invoked successfully too!!). Thank you for this technique, it is the one which saved me :) What i have done, step by step, following Tony's advices: - Grab the MinGW + MSYS (Not for MinGW-w64, regular one) installer, and installed with default paths, and unchecked everything except "MSYS Basic System". - Downloaded the SeZero binary package for MinGW-w64, and unpacked it to C:/MinGW/mingw-w64. - Updated my /etc/profile file, and added the line after the existing: if [ $MSYSTEM == MINGW32 ]; then export PATH=".:/usr/local/bin:/mingw/bin:/bin:$PATH" else export PATH=".:/usr/local/bin:/bin:/mingw/bin:$PATH" fi # Also add MinGW64 to path... export PATH="/c/MinGW/mingw-w64/bin:$PATH" Anyways, this is very good, so i guess the problem is solved, and i will be able to use delay-loaded features thanks to mingw-w64. But still: i would like to be able to solve the compilation problems under cygwin, it appears interesting to me that a pre-built mingw-w64 package exists for cygwin. Cheers, and thank you all for your help, i'll report back here whatever if i have troubles or not, and give my impressions / findings. Pierre. Off-topic: Attached is my script to compile Tesseract, Leptonica and ZBar (It might be of some interest to someone as it shows the options and required variables, it worked with the regular mingw32 so i guess it would with mingw64 too). The only difference required between the old mingw and the new mingw-w64 is the definition of BLOB (See commented line in the tesseract compilation options). Hopefully this will be of some sort of help when someone will want to compile lept / tess / zbar with mingw-w64. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 14:41:59
|
Correction on my previous email, and an interesting finding. With the regular MinGW, i was able to compile Tesseract with the following options for the compiler directives: CPPFLAGS="-DWIN32 -D__GNUC__ -DNDEBUG -DUSE_STD_NAMESPACE -D__BLOB_T_DEFINED" Doing the same with mingw-w64 fails, because the wtypes.h supplied with the compiled tests _tagBLOB_DEFINED instead of __BLOB_T_DEFINED (i wonder why, because the original windows does the same, so it's a difference between the Win32 API declarations and the mingw-w64 supplied API declarations). No biggie tho, because to solve the problem i just had to: CPPFLAGS="-DWIN32 -D__GNUC__ -DNDEBUG -DUSE_STD_NAMESPACE -D_tagBLOB_DEFINED" i hope this will make sense to maintainers, or that i'll get an explaination of a wrong logic on my side :) Pierre. |
From: JonY <jo...@us...> - 2012-04-16 14:41:59
Attachments:
signature.asc
|
On 4/16/2012 21:28, MARTIN Pierre wrote: > JonY, > >> To understand better, mingw-w64 is distinct from regular mingw >> (sometimes referred to as mingw.org when mingw-w64 is used in context). >> mingw-w64 is a fork of regular mingw to initially support win64 >> targeting, but these days, it works fine for targeting win32 too. > Understood. Will the regular mingw tend to die over time, and mingw-w64 be it's successor then? Shall one company encourage its developers to switch to the later already? > No, I don't think regular mingw will go away soon, there are a whole lot of legacy code that depend on mingw.org specific quirks to work with mingw-w64. mingw-w64 tries to follow MSVC closely when possible, so the difference might bite some code. One of the more notable ones are the ddk headers usage, <ddk/wdm.h> will work with regular mingw but not mingw-w64. Like MSVC, mingw-w64 requires you to use <wdm.h> and use -I to point to the ddk headers directory. >> MSYS is a minimalist emulation of a GNU system, it does the bare minimum >> to run configure and autotools. It is a fork of an old version of >> Cygwin. You can run win32 hosted toolchains in MSYS (meaning the >> toolchain executables are actual win32 executables built with mingw or >> mingw-w64. >> Cygwin is aimed at being a more complete Unix emulation system on >> Windows. The advantage is that it is far more complete than MSYS, >> anything Unix-ish you need to do in MSYS, you could do with Cygwin. >> Compared to MSYS, it is far easier to extend Cygwin functionality than >> MSYS (you have your Cygwin setup repo), since MSYS aims to be minimalist. > Allright, but still a bit foggy: why would one use MSYS then, when Cygwin seems to be more "complete" and mature? > The upside to MSYS is that you use a self-hosting mingw toolchain (mingw target GCC built by mingw itself), great for running the toolchain testsuite without any complicated expect/dejagnu setups. >> However, with recent Cygwin versions, path translation behavior is now >> different from MSYS, no longer automatic, that means regular win32 >> toolchains built with mingw have problems working under Cygwin, though >> Cygwin provides a cross compiler for mingw and mingw-w64. > i believe i pinpointed what you're talking about already. The windows drives (eg. /c/) are no longer available here, but in /cygdrive/c/, is that what youre talking about? Wouldn't a simple mount from /cygdrive/c to /c solve this problem? > Well, that's a minor cosmetic difference, all Windows drives in Cygwin are prefixed with /cygdrive/ by default. The difference is that when calling native win32 programs, eg foo /cygdrive/c/my_arg, MSYS auto translates the paths to win32 equivalent C:\my_arg, but modern Cygwin versions don't bother and will pass it verboten to the program. As you can expect, most win32 programs can't handle that, that includes GCC when you pass it a path argument to a source file. >> With Cygwin you should use Cygwin built cross toolchains. Remember, they >> are cross compilers, so they add a bit of complexity to non-autotooled >> buildsystems. The mingw-w64 gcc for win64 target is called >> x86_64-w64-mingw32-gcc instead of just "gcc" ("gcc" is the toolchain >> targeting Cygwin, not what you want). See the mingw64-x86_64 packages in >> the Cygwin setup for a list of mingw-w64 related downloads for working >> with Win64. > Understood. That's probably the origin of my last problem, configure script not being able to find a valid compiler. So i guess i'll just symlink and try again then :) > It's the same for all autotools based projects, the triplets indicate the toolchain to use, notice the win64 toolchain is called x86_64-w64-mingw32-gcc, the prefix is used for the --host part. For autotools based projects in Cygwin, use --build=i686-pc-cygwin --host=x86_64-w64-mingw32 to target win64, or --host=i686-w64-mingw32 for win32. Finally, don't do any symlinks with the Cygwin toolchain, they're designed to work out of the box after setup completes. > JonY, all those condensed explainations should be made sticky on top of the mingw-w64 project. Like many others, i'm from the Mac / Linux world, where either XCode installs everything for me, or i just aptitude / yum whatever and everything is ready (and i'm aware it's not the best when it comes to later understanding on how things work under the hood). Such explanation would prevent people like me from bugging you guys :) > Thanks a huge lot. The mingw-w64 website could use a dedicated web developer to add more technical content. I don't know about Macs, but if you can think of Cygwin as a Unix distro, the Cygwin setup is likely the closest you can find equivalent to a Linux distro Yum/Apt style application management on Windows. mingw-get too is striving to aim for this Yum/Apt style use model, but it is geared to a more minimalist goal, so you'll need to get your hands dirty if you need something that isn't covered. As far as I know, the mingw-get repo contains the mingw toolchain, some commonly used mingw support library (like gmp, mpfr, gettext, libiconv), MSYS along with some common and expected Unix tools (like sed, awk, m4 and Perl). You won't find anything like python or apache httpd in there, although it's very much possible to do MSYS versions of them, but you'll just be duplicating the efforts done by the Cygwin maintainers. |
From: JonY <jo...@us...> - 2012-04-16 14:47:18
Attachments:
signature.asc
|
On 4/16/2012 22:41, MARTIN Pierre wrote: > Correction on my previous email, and an interesting finding. > With the regular MinGW, i was able to compile Tesseract with the following options for the compiler directives: > CPPFLAGS="-DWIN32 -D__GNUC__ -DNDEBUG -DUSE_STD_NAMESPACE -D__BLOB_T_DEFINED" > Doing the same with mingw-w64 fails, because the wtypes.h supplied with the compiled tests _tagBLOB_DEFINED instead of __BLOB_T_DEFINED (i wonder why, because the original windows does the same, so it's a difference between the Win32 API declarations and the mingw-w64 supplied API declarations). > No biggie tho, because to solve the problem i just had to: > CPPFLAGS="-DWIN32 -D__GNUC__ -DNDEBUG -DUSE_STD_NAMESPACE -D_tagBLOB_DEFINED" > > i hope this will make sense to maintainers, or that i'll get an explaination of a wrong logic on my side :) > Pierre. > You should never hack about the headers by defining internal symbols. __BLOB_T_DEFINED and _tagBLOB_DEFINED not public, its best to fix your code instead. Does your code double define the type? Also, __GNUC__ and WIN32 are always defined when using mingw and mingw-w64 GCC, so you should not define them. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 14:54:21
|
Dear JonY and list users, > You should never hack about the headers by defining internal symbols. > __BLOB_T_DEFINED and _tagBLOB_DEFINED not public, its best to fix your > code instead. Does your code double define the type? As i am very aware of that aspect, i couldn't do much about it, as i'm not the maintainer of Tesseract (Merelly a user, as you might have understood from my questions ;) ). There is probably a very good reason why they did that at the first place back in the 90's, but i have no idea why. > Also, __GNUC__ and WIN32 are always defined when using mingw and > mingw-w64 GCC, so you should not define them. You are right, i did this define to make 100% sure the precompiler was hitting some platform-specific code in the Tesseract source, and after that i was able to remove the define. Thanks for your observations! i will probably make an explaination email to the Tesseract list once i'll be done with everything. That's also why i want to test the cygwin method, even if the msys method works for me. Pierre. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 15:09:46
|
TonY, > No, I don't think regular mingw will go away soon, there are a whole lot > of legacy code that depend on mingw.org specific quirks to work with > mingw-w64. mingw-w64 tries to follow MSVC closely when possible, so the > difference might bite some code. One of the more notable ones are the > ddk headers usage, <ddk/wdm.h> will work with regular mingw but not > mingw-w64. Like MSVC, mingw-w64 requires you to use <wdm.h> and use -I > to point to the ddk headers directory. Okay! Then my previous finding about the BLOB preprocessor definition test may be of some sort of interest to maintainers, because it differs from the MSVC definitions (At least the test to see if it's defined does). Also, i'll keep in mind the "conditional include path" directive in mind to avoid myself some future headaches. The thing is, i am for now not willing to compile for 64 bits at all, only be able to use the delay-loaded library feature offered by mingw-w64, without having to do it myself. > The upside to MSYS is that you use a self-hosting mingw toolchain (mingw > target GCC built by mingw itself), great for running the toolchain > testsuite without any complicated expect/dejagnu setups. Still foggy, but i'm sure this will make sense in a little while when i'll be more familiar with the whole environement. > It's the same for all autotools based projects, the triplets indicate > the toolchain to use, notice the win64 toolchain is called > x86_64-w64-mingw32-gcc, the prefix is used for the --host part. > For autotools based projects in Cygwin, use --build=i686-pc-cygwin > --host=x86_64-w64-mingw32 to target win64, or --host=i686-w64-mingw32 > for win32. Finally, don't do any symlinks with the Cygwin toolchain, > they're designed to work out of the box after setup completes. Oh very simple of a solution! And duly noted about not symlinking. But one more question, and i stop: you say i can pass those options while running the configure script of my program, right? But that means that the maintainer of the program has to implement some sort of tests in the configure script to handle the tripplets in the --host parameter, right? Or maybe it's done automatically when generating the configure script with autotools? > The mingw-w64 website could use a dedicated web developer to add more > technical content. i would have gladdelly helped if i was speaking a proper english, and if i was a more experienced user. Maybe in a few monthes i can, at least in french. > I don't know about Macs, but if you can think of Cygwin as a Unix > distro, the Cygwin setup is likely the closest you can find equivalent > to a Linux distro Yum/Apt style application management on Windows. Yes, i noticed the nice GUI installer for cygwin. i found myself quite embarassed when later i wanted to install other packages, as i am more comfortable with command-line packaging tools than with GUI installers. i figured i had to start the cygwin installer again to install new packages. It's all good too, but too bad there isn't a mingw-get equivalent (Or maybe there is?). > mingw-get too is striving to aim for this Yum/Apt style use model, but > it is geared to a more minimalist goal, so you'll need to get your hands > dirty if you need something that isn't covered. As far as I know, the > mingw-get repo contains the mingw toolchain, some commonly used mingw > support library (like gmp, mpfr, gettext, libiconv), MSYS along with > some common and expected Unix tools (like sed, awk, m4 and Perl). Why not making mingw-w64 part of the msys repo? > You won't find anything like python or apache httpd in there, although > it's very much possible to do MSYS versions of them, but you'll just be > duplicating the efforts done by the Cygwin maintainers. Understood. Good news of the day, tesseract / leptonica / zbar are now successfully compiled with mingw-w64. i'll attack Qt 4.8.1 after, and then my projects, hopping that this delayloading feature will not be too much of a perk (But i already made my makefile call dlltool to make the intermediate delayload libraries, so it should be ok!) :D Thanks for explaining everything! Pierre. |
From: JonY <jo...@us...> - 2012-04-16 15:49:56
Attachments:
signature.asc
|
On 4/16/2012 23:09, MARTIN Pierre wrote: >> It's the same for all autotools based projects, the triplets indicate >> the toolchain to use, notice the win64 toolchain is called >> x86_64-w64-mingw32-gcc, the prefix is used for the --host part. >> For autotools based projects in Cygwin, use --build=i686-pc-cygwin >> --host=x86_64-w64-mingw32 to target win64, or --host=i686-w64-mingw32 >> for win32. Finally, don't do any symlinks with the Cygwin toolchain, >> they're designed to work out of the box after setup completes. > Oh very simple of a solution! And duly noted about not symlinking. But one more question, and i stop: you say i can pass those options while running the configure script of my program, right? But that means that the maintainer of the program has to implement some sort of tests in the configure script to handle the tripplets in the --host parameter, right? Or maybe it's done automatically when generating the configure script with autotools? > Its part of autotools, as long as the programmer does not make any bad assumptions, the code should work out of the box. >> The mingw-w64 website could use a dedicated web developer to add more >> technical content. > i would have gladdelly helped if i was speaking a proper english, and if i was a more experienced user. Maybe in a few monthes i can, at least in french. > >> I don't know about Macs, but if you can think of Cygwin as a Unix >> distro, the Cygwin setup is likely the closest you can find equivalent >> to a Linux distro Yum/Apt style application management on Windows. > Yes, i noticed the nice GUI installer for cygwin. i found myself quite embarassed when later i wanted to install other packages, as i am more comfortable with command-line packaging tools than with GUI installers. i figured i had to start the cygwin installer again to install new packages. It's all good too, but too bad there isn't a mingw-get equivalent (Or maybe there is?). > Cygwin setup can be used in the command line too, try "setup.exe --help". >> mingw-get too is striving to aim for this Yum/Apt style use model, but >> it is geared to a more minimalist goal, so you'll need to get your hands >> dirty if you need something that isn't covered. As far as I know, the >> mingw-get repo contains the mingw toolchain, some commonly used mingw >> support library (like gmp, mpfr, gettext, libiconv), MSYS along with >> some common and expected Unix tools (like sed, awk, m4 and Perl). > Why not making mingw-w64 part of the msys repo? > mingw-w64 and mingw.org are different projects. MSYS comes from the mingw.org maintainers, so it doesn't quite make sense to put files from a different project there. Besides, that would mean more work for the maintainers, both projects are already chronically lacking in manpower. >> You won't find anything like python or apache httpd in there, although >> it's very much possible to do MSYS versions of them, but you'll just be >> duplicating the efforts done by the Cygwin maintainers. > Understood. > > Good news of the day, tesseract / leptonica / zbar are now successfully compiled with mingw-w64. i'll attack Qt 4.8.1 after, and then my projects, hopping that this delayloading feature will not be too much of a perk (But i already made my makefile call dlltool to make the intermediate delayload libraries, so it should be ok!) :D > > Thanks for explaining everything! > Pierre. > Sure, have fun! |
From: MARTIN P. <hic...@gm...> - 2012-04-16 16:23:58
|
> Its part of autotools, as long as the programmer does not make any bad > assumptions, the code should work out of the box. Understood. > Cygwin setup can be used in the command line too, try "setup.exe --help". Exactly what i was looking for, thanks! > mingw-w64 and mingw.org are different projects. MSYS comes from the > mingw.org maintainers, so it doesn't quite make sense to put files from > a different project there. Besides, that would mean more work for the > maintainers, both projects are already chronically lacking in manpower. Ah yes. > Sure, have fun! Thanks, i'm already enjoying the functional setup a lot! Pierre. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 16:22:06
|
Hello list, Earlier, regarding compilation under Cygwin with mingw-w64, TonY said: >> It's the same for all autotools based projects, the triplets indicate >> the toolchain to use, notice the win64 toolchain is called >> x86_64-w64-mingw32-gcc, the prefix is used for the --host part. >> For autotools based projects in Cygwin, use --build=i686-pc-cygwin >> --host=x86_64-w64-mingw32 to target win64, or --host=i686-w64-mingw32 >> for win32. Finally, don't do any symlinks with the Cygwin toolchain, >> they're designed to work out of the box after setup completes. Even being successfull with MSYS, i'm still experimenting with Cygwin. i used --host=i686-w64-mingw32 in my configure options (The program i'm compiling is Leptonica). The configuration fails with this message: configure: WARNING: If you wanted to set the --build type, don't use --host. If a cross compiler is detected then cross compile mode will be used. checking build system type... i686-pc-cygwin checking host system type... i686-w64-mingw32 checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc checking whether the C compiler works... no What does it means? Is the configure script unaware of the option? Is it related to something wrong in general i'm doing, or shall i consider giving the information to the makers of Leptonica instead? Thanks, Pierre. |
From: MARTIN P. <hic...@gm...> - 2012-04-16 16:27:10
|
> configure: WARNING: If you wanted to set the --build type, don't use --host. > If a cross compiler is detected then cross compile mode will be used. > checking build system type... i686-pc-cygwin > checking host system type... i686-w64-mingw32 > checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc > checking whether the C compiler works... no A bit of the answer appeared to me... And that's really a shame. When using the same option to configure another program (e.g. ZBar), it is successfull. So it probably means that the configure script for Leptonica isn't aware of the --host option correctly. Is there anything i can do about it beside contacting the authors? |
From: MARTIN P. <hic...@gm...> - 2012-04-16 16:39:49
|
And finally ansering the whole question, thanks to Tony and JonY answers regarding how the configure script are generated: >> configure: WARNING: If you wanted to set the --build type, don't use --host. >> If a cross compiler is detected then cross compile mode will be used. >> checking build system type... i686-pc-cygwin >> checking host system type... i686-w64-mingw32 >> checking for i686-w64-mingw32-gcc... i686-w64-mingw32-gcc >> checking whether the C compiler works... no > A bit of the answer appeared to me... And that's really a shame. When using the same option to configure another program (e.g. ZBar), it is successfull. So it probably means that the configure script for Leptonica isn't aware of the --host option correctly. Is there anything i can do about it beside contacting the authors? i didnt run the autobuild script prior to calling the configure script. Calling it made the configure script aware of the --host option! Thanks anyways :) Pierre. |