From: Jim M. <jmi...@ya...> - 2010-01-25 05:22:15
|
I have 4 questions. 1. I have a 32-bit OS. when I try to execute a "real" 64-bit exe, I usually get an error saying that it "is not a valid win32 application". when I use plain g++ with no special switches, it generates an executable that executes on my 32-bit machine. that's great for debugging, but once I have finished debugging my app, how do I generate a real 64-bit executable? 2. where is the documentation for the mingw-w64 switches and the mingw switches? I already have switches for standard gcc. but these are not in the generic gcc docs. for mingw-w64, assume I am using sezero hand-build. 3. I can't find any documentation for mingw libraries (such as pthreads and opengmp)! where is it? 4. what are those files with the -1 on the end of the basename? Jim Michaels jmi...@ya... http://JesusnJim.com |
From: JonY <jo...@us...> - 2010-01-25 05:48:12
|
On 1/25/2010 13:22, Jim Michaels wrote: > I have 4 questions. > > 1. I have a 32-bit OS. when I try to execute a "real" 64-bit exe, I usually get an error saying that it "is not a valid win32 application". > > when I use plain g++ with no special switches, it generates an executable that executes on my 32-bit machine. that's great for debugging, but once I have finished debugging my app, how do I generate a real 64-bit executable? > > > 2. where is the documentation for the mingw-w64 switches and the mingw switches? I already have switches for standard gcc. but these are not in the generic gcc docs. for mingw-w64, assume I am using sezero hand-build. > > 3. I can't find any documentation for mingw libraries (such as pthreads and opengmp)! where is it? > > 4. what are those files with the -1 on the end of the basename? > Hi, For your 1st question, "g++" for MinGW generates 32bit applications, not 64bit applications. For 64bit applications, use the toolchains that target 64bit Windows on the mingw-w64 downloads site[1]. For the 2nd question, see the GCC docs[2]. For the 3rd question, OpenMP is part of GCC, it uses pthreads-win32[3]. For the 4th question, I suppose those indicate that they are the first release. The *mingw-w64* list is at *mingw-w64-public*, not *mingw-users*, you are on the wrong mailing list. Please direct mingw-w64 questions there next time. [1] <http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/> [2] <http://gcc.gnu.org/onlinedocs/gcc/index.html> [3] <http://sourceware.org/pthreads-win32/> |
From: Keith M. <kei...@us...> - 2010-01-25 21:02:14
|
On Monday 25 January 2010 05:32:21 JonY wrote: [Rearranged; JonY, please trim, and reply point-by-point, rather than bottom posting, thanks]. > On 1/25/2010 13:22, Jim Michaels wrote: > > I have 4 questions. > > > > [...snip...] > > > > 3. I can't find any documentation for mingw libraries (such as > > pthreads and opengmp)! where is it? > > ... OpenMP is part of GCC, it uses pthreads-win32... Authoritative answer: we provide gmp, pthreads-w32 (and mpfr) in DLL form only, simply because they are required by the GCC-4 compiler exectutables themselves; (of course, we also provide source, to satisfy our obligations under the GPL). We do not (currently) offer them for end-user deployment, hence we do not provide documentation other than that present in the source tarballs. If you require these libraries specifically for use by your own applications, then we expect you to build, use and redistribute (as appropriate), either from the source we provide, or (perhaps to be preferred), from up-to-date releases obtained directly from the originating upstream projects. > > 4. what are those files with the -1 on the end of the basename? > > ... I suppose those indicate that they are the first release. For our packages: http://mingw.org/PackageIdentificationHOWTO For mingw-w64 packages: <shrug> ask the mingw-w64 team. -- Regards, Keith. |
From: Charles W. <cwi...@us...> - 2010-01-26 03:05:30
|
Keith Marshall wrote: > Authoritative answer: we provide gmp, pthreads-w32 (and mpfr) in DLL > form only, Actually, we don't -- there's a packaging bug in the pthreads pkgs. See this post: http://thread.gmane.org/gmane.comp.gnu.mingw.user/30247 I never bothered to fix it, because there was no response to the post at all, so I'm not sure my proposed fix is the "right" one. -- Chuck |
From: Roumen P. <bug...@ro...> - 2010-01-26 07:32:30
|
Charles Wilson wrote: > Keith Marshall wrote: >> Authoritative answer: we provide gmp, pthreads-w32 (and mpfr) in DLL >> form only, > > Actually, we don't -- there's a packaging bug in the pthreads pkgs. See > this post: > http://thread.gmane.org/gmane.comp.gnu.mingw.user/30247 > > I never bothered to fix it, because there was no response to the post at > all, so I'm not sure my proposed fix is the "right" one. You post is for native tools. Location pthreads-w32 where mingwrt and win32 will be installed. As the cross-compiler didn't search in <PREFIX>{include|lib} I install all above in <PREFIX>/<TARGET> as prefix. Configure script of some project is not so perfect and for mingw GCC 4.4 will detect pthreads.h and will try to build with pthread support instead native windows thread support. In the cases that I know build fail. As example libxml2 require --with-threads flag to be set (all except "pthread","yes" or empty) will force configure script to select windows threads for mingw32 hosts. > -- > Chuck Roumen |
From: Keith M. <kei...@us...> - 2010-01-27 20:02:15
|
On Tuesday 26 January 2010 03:04:34 Charles Wilson wrote: > Keith Marshall wrote: > > Authoritative answer: we provide gmp, pthreads-w32 (and mpfr) in > > DLL form only, > > Actually, we don't -- there's a packaging bug in the pthreads > pkgs. See this post: > http://thread.gmane.org/gmane.comp.gnu.mingw.user/30247 Oops! I've either overlooked that at the time, or more likely, I assumed that Aaron, as the original package contributor, would address it, (which he apparently didn't). There is also an outstanding bug report, on the tracker, for the same issue. > I never bothered to fix it, because there was no response to the > post at all, so I'm not sure my proposed fix is the "right" one. I don't know either; perhaps Aaron, although he is no longer our GCC maintainer, would be so kind as to apprise us of his intended content when he rolled the original package. Reviewing your original post: > It seems to me that the file currently called > "pthreads-w32-2.8.0-mingw32-dll.tar.gz" really should be named > "pthreads-w32-2.8.0-mingw32-dev.tar.gz" Given its content, and our agreed package naming standard, I concur, (*if* we actually need to provide this development kit at all). We should certainly provide: > a REAL pthreads-w32-2.8.0-mingw32-dll.tar.gz file containing > bin/pthreadGC2.dll because that is a stated prerequisite for GCC-4.4. If it is imperative to also provide the development kit, then we really *need* Aaron to comment on: > [*] I *think* these paths ought to be > include/pthread.h > include/sched.h > include/semaphore.h > lib/libpthread.a > (or, if you want them sequestered in the compiler's private area) > lib/gcc/mingw32/4.4.0/include/pthread.h > lib/gcc/mingw32/4.4.0/include/sched.h > lib/gcc/mingw32/4.4.0/include/semaphore.h > lib/gcc/mingw32/4.4.0/libpthread.a > but I'm not really sure that's what you want). because only he, as original contributor, knows what he intended. -- Regards, Keith. |
From: Roumen P. <bug...@ro...> - 2010-01-27 22:05:56
|
Keith Marshall wrote: > On Tuesday 26 January 2010 03:04:34 Charles Wilson wrote: >> Keith Marshall wrote: [SNIP] > >> [*] I *think* these paths ought to be >> include/pthread.h >> include/sched.h >> include/semaphore.h >> lib/libpthread.a >> (or, if you want them sequestered in the compiler's private area) >> lib/gcc/mingw32/4.4.0/include/pthread.h >> lib/gcc/mingw32/4.4.0/include/sched.h >> lib/gcc/mingw32/4.4.0/include/semaphore.h >> lib/gcc/mingw32/4.4.0/libpthread.a >> but I'm not really sure that's what you want). > > because only he, as original contributor, knows what he intended. > So the question is same for gmp and libiconv - where to install for cross-compiler ? With directory tree include/lib/bin installation is simple - just unpack in PREFIX/TARGET. I'm not sure that packages like gmp, libiconv and pthreads-w32 has to installed in compiler's private area. Roumen |
From: Keith M. <kei...@us...> - 2010-01-29 21:34:06
|
On Wednesday 27 January 2010 22:05:44 Roumen Petrov wrote: [Re: auxiliary libraries required for a working GCC-4 installation] > So the question is same for gmp and libiconv - where to install > for cross-compiler ? A cross-compiler needs different considerations anyway. AIUI, we provide these extra libraries because GCC needs them *internally*, not because we think they might be convenient for end users to link into their own applications. Now, depending on the nature of GCC's requirement: * for code linked directly into the GCC executables themselves, the libraries are needed because there are references within the GCC executables, which demand the DLL for runtime binding. In this case we need to provide only the DLL, for the native GCC build; for a cross-compiler, the Windows DLL isn't required at all; references must be resolved against a library which is native to the $build platform. For such dependencies, we do not *need* to make the public API (development kit) available at all. * for code used to facilitate implementation of compiler intrinsics or standard library functions, then the DLL alone isn't sufficient; we need to also provide enough of the development kit to allow user applications to be linked. However, that still doesn't make it necessary to publish details of the API in the form of headers, because we don't expect user code to directly refer to this API. > With directory tree include/lib/bin installation is simple - just > unpack in PREFIX/TARGET. It's just as simple to sequester it in the compiler's private data area, as it is to install for public use. > I'm not sure that packages like gmp, libiconv and pthreads-w32 has > to installed in compiler's private area. You're assuming that our objective is to make these libraries available for the general convenience of end users. That isn't the case; if it were, we would provide them as standalone packages, in complete form, for separate installation by the end user. Our motivation is quite different; these are required for *private* use by GCC-4 itself, thus there is an argument in favour of keeping them private. However, if there is also a strong case of making them available for public use, then there is a counter argument for installing in the public API arena. The issue is that we are undecided on the best approach, and we would really like the original maintainer to share his perspective on this. -- Regards, Keith. |
From: Roumen P. <bug...@ro...> - 2010-01-29 23:48:56
|
Keith Marshall wrote: > On Wednesday 27 January 2010 22:05:44 Roumen Petrov wrote: > [Re: auxiliary libraries required for a working GCC-4 installation] >> So the question is same for gmp and libiconv - where to install >> for cross-compiler ? > > A cross-compiler needs different considerations anyway. AIUI, we > provide these extra libraries because GCC needs them *internally*, > not because we think they might be convenient for end users to link > into their own applications. Now, depending on the nature of GCC's > requirement: > > * for code linked directly into the GCC executables themselves, the > libraries are needed because there are references within the GCC > executables, which demand the DLL for runtime binding. In this case > we need to provide only the DLL, for the native GCC build; for a > cross-compiler, the Windows DLL isn't required at all; references > must be resolved against a library which is native to the $build > platform. For such dependencies, we do not *need* to make the > public API (development kit) available at all. The cross-build process check for pthread, gmp and iconv target headers and libraries and if found the result on host is: - libgomp-1.dll depend from pthreadGC2.dll - libjavamath.dll depend from gmp-3.dll - libgcj-XXX-10.dll depend from libiconv-2.dll May be build will succeed without them but this case is never tested by me. > * for code used to facilitate implementation of compiler intrinsics > or standard library functions, then the DLL alone isn't sufficient; > we need to also provide enough of the development kit to allow user > applications to be linked. However, that still doesn't make it > necessary to publish details of the API in the form of headers, > because we don't expect user code to directly refer to this API. >> With directory tree include/lib/bin installation is simple - just >> unpack in PREFIX/TARGET. > > It's just as simple to sequester it in the compiler's private data > area, as it is to install for public use. No because directory tree will be different if installation is in private area. >> I'm not sure that packages like gmp, libiconv and pthreads-w32 has >> to installed in compiler's private area. > > You're assuming that our objective is to make these libraries > available for the general convenience of end users. Headers and import library are required for build process after this only shared libraries. > That isn't the > case; if it were, we would provide them as standalone packages, in > complete form, for separate installation by the end user. Our > motivation is quite different; these are required for *private* use > by GCC-4 itself, thus there is an argument in favour of keeping them > private. However, if there is also a strong case of making them > available for public use, then there is a counter argument for > installing in the public API arena. The issue is that we are > undecided on the best approach, and we would really like the > original maintainer to share his perspective on this. Sure users always could build from source instead to really on ready to use "development" packages. Roumen |
From: Keith M. <kei...@us...> - 2010-01-30 20:59:06
|
On Friday 29 January 2010 23:48:45 Roumen Petrov wrote: > The cross-build process check for pthread, gmp and iconv target > headers and libraries What cross build process? It certainly isn't one we sanction. [*] > and if found the result on host is: > - libgomp-1.dll depend from pthreadGC2.dll > - libjavamath.dll depend from gmp-3.dll > - libgcj-XXX-10.dll depend from libiconv-2.dll Surely you have these the wrong way around? As you've stated this, it suggests that e.g. libiconv depends on libgcj; I can assert that this categorically is not so; I believe that libgcj may depend on libiconv, but as I've never programmed java, (and likely never will), I may be wrong. However, I have written applications which use libiconv, (e.g. gencat from MinGW's libcatgets implementation), and these work fine, with no trace of libgcj in sight. > >> With directory tree include/lib/bin installation is simple - > >> just unpack in PREFIX/TARGET. > > > > It's just as simple to sequester it in the compiler's private > > data area, as it is to install for public use. > > No because directory tree will be different if installation is in > private area. It depends on how the package maintainer chooses to configure the build; it is no more difficult to configure for private installation than for public. > > You're assuming that our objective is to make these libraries > > available for the general convenience of end users. > > Headers and import library are required for build process after > this only shared libraries. Exactly. And, if the API needs to be visible only while building the compiler itself, we don't need to publish it. If static or import libraries are also required to link user applications, then those must be provided, but it still may not be necessary to publish the header components of the API. Please don't misunderstand me; I favour publication of the full library suite, in publicly accessible fashion, but IIRC Aaron, as GCC maintainer at the time, did not want to assume the additional maintenance burden which that might incur. [*] The cross-compiler build procedure which we support will not yet deliver a GCC-4.x compiler; on the "if it ain't broken, don't fix it" principle, I am still using GCC-3.4.5 as my production MinGW compiler. I know our users would appreciate an upgrade, but I am maintaining it single-handedly at present, and I simply don't have time to address it. I have invited patches from others, but as yet, none have been forthcoming. -- Regards, Keith. |