From: Mark M. <bwa...@ya...> - 2012-07-27 18:34:43
|
------------------------------ >On Thu, Jul 26, 2012 8:38 PM PDT LRN wrote: > > >>-----BEGIN PGP SIGNED MESSAGE----- >>Hash: SHA1 >> >>On 27.07.2012 7:28, Mark Mikofski wrote: >>> Overview: Try to configure nano-2.3.1 (GNU nano editor), it runs >>> conftest to check for iconv, returns error: >>> >>> checking for iconv >>> >>> ... /include/iconv.h:123:3: error: unknown type name 'mbstate_t' >>> result: no, consider installing GNU libiconv >>Looks like it groks msys /include directory instead of mingw >>/mingw/include directory. Are you configuring with --prefix=/mingw ? >>Are there any possible --with-foo...=PREFIX arguments to configure? > > Good idea, thanks, but there is no iconv header in the /mingw/msys/1.0/include (/include) directory, it is only in /mingw/include. The full path of the compiler error message is ...am_cv_python_pyexecdir c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/iconv.h:123:3: error: unknown type name 'mbstate_t' ... which points to /mingw/include/iconv.h. I did explicitly include /include as a CPPFLAG, but that was to find regex.h (perhaps mistakenly? can I *not* use any headers from msys on my toolchain?) a required header for nano. I think I can explicitly cache am_cv_fun_iconv (or can't remember) to bypass the iconv check, assuming that iconv is fine, it's the check that causes the error or use a different iconv. I could use the one from xmlsoft or another packager built an additional mingw-iconv (see below). There are 2 binary version of nano already out there, http://www.nano-editor.org/dist/v2.2/NT/nano-2.2.6.zip on http://www.nano-editor.org/download.php built with cygwin + PDcurses + a "few tweaks" and http://mingw-and-ndk.googlecode.com/files/win-mingw-nano.7z on http://code.google.com/p/mingw-and-ndk/downloads/detail?name=win-mingw-nano.7z built with mingw, also builds iconv, mingw-regex, gettext and win-pthreads + patches The mingw version has a build script, so maybe I can follow that. Thanks again for your help! |
From: Eli Z. <el...@gn...> - 2012-07-27 18:46:55
|
> Date: Fri, 27 Jul 2012 11:34:35 -0700 (PDT) > From: Mark Mikofski <bwa...@ya...> > > >>Looks like it groks msys /include directory instead of mingw > >>/mingw/include directory. Are you configuring with --prefix=/mingw ? > >>Are there any possible --with-foo...=PREFIX arguments to configure? > > > > > Good idea, thanks, but there is no iconv header in the /mingw/msys/1.0/include (/include) directory, it is only in /mingw/include. The full path of the compiler error message is ...am_cv_python_pyexecdir > > c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/iconv.h:123:3: error: unknown type name 'mbstate_t' > > > ... which points to /mingw/include/iconv.h. Something is broken in your system headers. mbstate_t is defined on wchar.h, and iconv.h includes that header, at least on my system. Perhaps your iconv.h is broken. Where did you get it? |
From: Mark M. <bwa...@ya...> - 2012-07-27 23:17:19
|
> Date: Fri, 27 Jul 2012 11:34:35 -0700 (PDT) >> From: Mark Mikofski <bwa...@ya...> >> >> >>Looks like it groks msys /include directory instead of mingw >> >>/mingw/include directory. Are you configuring with --prefix=/mingw ? >> >>Are there any possible --with-foo...=PREFIX arguments to configure? >> > >> > >> Good idea, thanks, but there is no iconv header in the /mingw/msys/1.0/include (/include) directory, it is only in /mingw/include. The full path of the compiler error message is ...am_cv_python_pyexecdir >> >> c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/iconv.h:123:3: error: unknown type name 'mbstate_t' >> >> >> ... which points to /mingw/include/iconv.h. > > >Something is broken in your system headers. mbstate_t is defined on >wchar.h, and iconv.h includes that header, at least on my system. >Perhaps your iconv.h is broken. Where did you get it? Aaaahh. Nothing broken,this is the same as on my system. My iconv is from mingw-get install ... autotools (mingw32), mingw-developer-toolkit (msys), libiconv (mingw32) and msys-libiconv (msys, which I just now discovered, and which solved my libxslt problem. So my bad, I guess if you install this, then iconv.h *is* in /include.) So installing the msys-libiconv solved *that* problem. Now I just need to apply some patches (setjmp.h needs sigjmp_buf) supplied online. I guess iconv.h in /include doesn't use mbstate, and /include/wchar.h doesn't define it? libiconv is also evidentally in minw32-libcharset & msys-libcharset, which I don't know if I need? And the msys-system-builder (meta) package, which I also don't have. So I am still learning exactly when to use msys (apps for posix like env) and when to use mingw (win32 apps, right?). But nano.exe works in both, so? Any problem solved. |
From: LRN <lr...@gm...> - 2012-07-28 00:55:18
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 28.07.2012 3:17, Mark Mikofski wrote: >> Date: Fri, 27 Jul 2012 11:34:35 -0700 (PDT) >>> From: Mark Mikofski <bwa...@ya...> >>> >>>>> Looks like it groks msys /include directory instead of >>>>> mingw /mingw/include directory. Are you configuring with >>>>> --prefix=/mingw ? Are there any possible >>>>> --with-foo...=PREFIX arguments to configure? >>>> >>>> >>> Good idea, thanks, but there is no iconv header in the >>> /mingw/msys/1.0/include (/include) directory, it is only in >>> /mingw/include. The full path of the compiler error message is >>> ...am_cv_python_pyexecdir >>> >>> c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/iconv.h:123:3: >>> error: unknown type name 'mbstate_t' >>> >>> >>> ... which points to /mingw/include/iconv.h. >> >> >> Something is broken in your system headers. mbstate_t is defined >> on wchar.h, and iconv.h includes that header, at least on my >> system. Perhaps your iconv.h is broken. Where did you get it? > > Aaaahh. Nothing broken,this is the same as on my system. My iconv > is from mingw-get install ... autotools (mingw32), > mingw-developer-toolkit (msys), libiconv (mingw32) and > msys-libiconv (msys, which I just now discovered, and which solved > my libxslt problem. So my bad, I guess if you install this, then > iconv.h *is* in /include.) > > So installing the msys-libiconv solved *that* problem. Now I just > need to apply some patches (setjmp.h needs sigjmp_buf) supplied > online. I guess iconv.h in /include doesn't use mbstate, and > /include/wchar.h doesn't define it? > > libiconv is also evidentally in minw32-libcharset & > msys-libcharset, which I don't know if I need? And the > msys-system-builder (meta) package, which I also don't have. > > So I am still learning exactly when to use msys (apps for posix > like env) and when to use mingw (win32 apps, right?). But nano.exe > works in both, so? > > Any problem solved. > If you want to build the thing you're building to be dependent on msys (and be required to drag around msys-1.dll, and use relatively slow POSIX wrappers from msys) - then yes, that's the solution. Otherwise - no, you're doing it wrong. MSys headers and libraries are not for MinGW applications, and vice versa. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQEzhqAAoJEOs4Jb6SI2CwE6IH/1FlUzhuyWr793HSCU+4q58a cn/6q3OQPGSyp2nUYH34QJWlGqwETLG041AwiaaXb2W+QpEdJXL1nrPrJ6GibIMA nNia0jknFDy4zhCwb6Pm1sPzXtFi0HAqahJHYJ0yT9+NASfRT8w0uYUZpkTkiCWy as6OsXIbEBxNmhd9V6k8hG4GOIO8BZo3+Ig14pu2eZhPpOz4HvMGj5OYlAD1spNU iHXu9Z1k1ABK9wZ0hRcEhkayVou+uU4wzNonRMH7riaTFA51I8TP+4Tqylm4nOCy vs2tkfgxit82yM/1/b6Yni+RoZ1jdAF2FvzB5AI2Cth7pbtIU3+jBx9nExswQeE= =S/LA -----END PGP SIGNATURE----- |
From: LRN <lr...@gm...> - 2012-07-28 00:52:20
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 27.07.2012 22:34, Mark Mikofski wrote: > On Thu, Jul 26, 2012 8:38 PM PDT LRN wrote: >> On 27.07.2012 7:28, Mark Mikofski wrote: >>> Overview: Try to configure nano-2.3.1 (GNU nano editor), it >>> runs conftest to check for iconv, returns error: >>> >>> checking for iconv >>> >>> ... /include/iconv.h:123:3: error: unknown type name >>> 'mbstate_t' result: no, consider installing GNU libiconv >> Looks like it groks msys /include directory instead of mingw >> /mingw/include directory. Are you configuring with >> --prefix=/mingw ? Are there any possible --with-foo...=PREFIX >> arguments to configure? > Good idea, thanks, but there is no iconv header in the > /mingw/msys/1.0/include (/include) directory, it is only in > /mingw/include. The full path of the compiler error message is > ...am_cv_python_pyexecdir > > c:\mingw\bin\../lib/gcc/mingw32/4.7.0/../../../../include/iconv.h:123:3: > error: unknown type name 'mbstate_t' > > > ... which points to /mingw/include/iconv.h. > > I did explicitly include /include as a CPPFLAG, but that was to > find regex.h (perhaps mistakenly? can I *not* use any headers from > msys on my toolchain?) a required header for nano. I think I can > explicitly cache am_cv_fun_iconv (or can't remember) to bypass the > iconv check, assuming that iconv is fine, it's the check that > causes the error or use a different iconv. I could use the one from > xmlsoft or another packager built an additional mingw-iconv (see > below). That is exactly the problem. You add /include to include path, and when /mingw/include/iconv.h includes wchar.h, it gets the one from /include, and guess what? It doesn't have mbstate_t definition in it! If you need regex.h, use libgnurx for mingw or something. > The mingw version has a build script, so maybe I can follow that. > Thanks again for your help! Yeah, it's usually a good idea to see how other people do stuff. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQEze3AAoJEOs4Jb6SI2CwoYMH/0nfyyYvL+6u/ersJQrk8Ck0 TxdFp7k2HCZZ5NELounz8JAgHyHJLJjTNdrXD5SIXay5eoQFfkOQmZHjBB+lEtDe mCjqZ0OELwxzGfHmuuggioeLNyvAKe1b8HsfHmWSsL0hqnIGPiX5FLCL/4tD2URy mifrZR8ZZB4zqAvN2gFf2Xwltk956ngDJ2narTWzgXVewrWu/4bE08GJzch8WSgi aJWeJyPHSvkBAD+9b3iDMlyKprcNALtW6SLhvnmq0bCmp3oQkTAwq7HWkmMz4b5K J9Rjbwgy0ZvPv5f5Ep1vQPnh/02JypWq+Frvj89/yMsIgV/gIBkiprKzTblqRdc= =QUwn -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2012-07-28 08:57:44
|
On 28/07/12 01:52, LRN wrote: >> I did explicitly include /include as a CPPFLAG, but that was to >> find regex.h (perhaps mistakenly? can I *not* use any headers from >> msys on my toolchain?) If you are trying to build a pure (native) windows application, then no, you MUST NOT do this. (LRN has already pointed you to a source for a native MinGW regex implementation). >> a required header for nano. Then, you MUST use a MinGW compatible version; you CANNOT mix MinGW and MSYS headers/libs, with any expectation of success. >> I think I can explicitly cache am_cv_fun_iconv (or can't remember) >> to bypass the iconv check, If you've installed a complete and consistent tool chain,then you shouldn't need to do any such thing; that you're even considering any such gross hack is a sure clue that you are doing something wrong! >> assuming that iconv is fine, it's the check that causes the error >> or use a different iconv. I could use the one from xmlsoft or >> another packager built an additional mingw-iconv (see below). > > That is exactly the problem. You add /include to include path, and > when /mingw/include/iconv.h includes wchar.h, it gets the one from > /include, and guess what? It doesn't have mbstate_t definition in it! Or, to express it more succinctly, you have a mix of MinGW and MSYS headers in your build environment; you must NEVER do this. (Your first mistake was probably to install ANY PART of the MSYS System Builder tool chain; 99.9% of users don't need it, shouldn't install it, and only incur a mass of grief when they mistakenly do so). -- Regards, Keith. |
From: Mark M. <bwa...@ya...> - 2012-07-28 21:31:01
|
From:Keith Marshall <kei...@us...> >To: min...@li... >Sent: Saturday, July 28, 2012 1:57 AM >Subject: Re: [Mingw-users] bug unknown type "mbstate_t" in iconv.h > > >On 28/07/12 01:52, LRN wrote: >>> I did explicitly include /include as a CPPFLAG, but that was to >>> find regex.h (perhaps mistakenly? can I *not* use any headers from >>> msys on my toolchain?) > > >If you are trying to build a pure (native) windows application, then no, >you MUST NOT do this. (LRN has already pointed you to a source for a >native MinGW regex implementation). > > >>> a required header for nano. > > >Then, you MUST use a MinGW compatible version; you CANNOT mix MinGW and >MSYS headers/libs, with any expectation of success. > > >>> I think I can explicitly cache am_cv_fun_iconv (or can't remember) >>> to bypass the iconv check, > > >If you've installed a complete and consistent tool chain,then you >shouldn't need to do any such thing; that you're even considering any >such gross hack is a sure clue that you are doing something wrong! > > >>> assuming that iconv is fine, it's the check that causes the error >>> or use a different iconv. I could use the one from xmlsoft or >>> another packager built an additional mingw-iconv (see below). >> >> That is exactly the problem. You add /include to include path, and >> when /mingw/include/iconv.h includes wchar.h, it gets the one from >> /include, and guess what? It doesn't have mbstate_t definition in it! > > >Or, to express it more succinctly, you have a mix of MinGW and MSYS >headers in your build environment; you must NEVER do this. (Your first >mistake was probably to install ANY PART of the MSYS System Builder tool >chain; 99.9% of users don't need it, shouldn't install it, and only >incur a mass of grief when they mistakenly do so). > > >-- >Regards, >Keith. Keith, LRN and Eli, Thanks for your help and especially Keith's response, which has really cleared up a lot of things for me specifically regarding the mingw toolchain. I believe that the dbus, dbus-glib and dbus-python instructions and binaries I already posted should be okay, as they were built without any pollution from the msys-dev chain, but perhaps I should go back and rebuild them with --prefix=/mingw just to make sure. Obviously my newest libxslt was built from the msys-dev libs so it is should be rebuilt with prefix=/mingw too, but first I will have to rebuild libxml2 (2.7.8), since xmlcatalog.exe is randomly throwing seg faults on both read and write. Do you think the newest prebuilt win32 binaries from xmlsoft are okay to use interchangably with mingw? Also, if I use prefix=/mingw for everything, then should I just keep installing there as well, or follow LRN's advice and continue to install them in /local? (the 2nd option would be my preference) Also, if I have used mingw-get install msys-*, will that pollute my mingw toolchain, if my PATH is /opt/bin:/local/bin:/mingw/bin:/bin, if I always use prefix=/mingw and install in /local? Thanks again. I don't know how you guys never get tired of answering n00bie questions like these? Or if you do, don't worry, I will survive on my own, sink or swim, we all have families (my son is napping as we speak!) and day jobs. Thanks anyway! --Mark |
From: Keith M. <kei...@us...> - 2012-07-29 09:05:19
|
On 28/07/12 22:30, Mark Mikofski wrote: >> Or, to express it more succinctly, you have a mix of MinGW and MSYS >> headers in your build environment; you must NEVER do this. (Your first >> mistake was probably to install ANY PART of the MSYS System Builder tool >> chain; 99.9% of users don't need it, shouldn't install it, and only >> incur a mass of grief when they mistakenly do so). > > ... > > Also, if I have used mingw-get install msys-*, will that pollute my > mingw toolchain, if my PATH is /opt/bin:/local/bin:/mingw/bin:/bin, > if I always use prefix=/mingw and install in /local? You are reading too much into that "ANY PART of MSYS System Builder". You DO need to "mingw-get install msys-*", for the the components of the shell environment you will use to build MinGW applications; what you don't need are the additional components which are provided for the explicit purpose of building MSYS ITSELF, (hence the system builder designation). The general rule of thumb is, that where similarly named packages are provided, one named as mingw32-* and one as msys-*, most users should install the mingw32-* variant, as the msys-* variant is intended for use when BUILDING MSYS. (A further clue is often provided in the description shown when you "mingw-get show msys-package-name"; Chuck has often noted that "this is not the package you are looking for", when most users should be installing a mingw32-* alternative). Of course, there are users who contribute to MSYS itself, or to MSYS spin-off projects, who DO need to install both tool chains; such users need to take care that only MinGW headers and libraries are seen by the compiler, and associated tools, when they invoke the mingw32 compiler, and conversely, only the MSYS headers and libraries are seen by the MSYS compiler. This is achieved, not only by reordering $PATH, (as LRN has already noted), such that /mingw/bin precedes /bin for the mingw32, for the mingw32 compiler, and /bin precedes /mingw/bin, (or /mingw/bin is omitted entirely), for the MSYS compiler, but also by ensuring that any -I paths specified in the CPPFLAGS, CFLAGS, and CXXFLAGS refer only to directories containing exclusively mingw32 compatible headers, when invoking the mingw32 compilers, and vice-versa for the MSYS compilers. (Similarly, the LDFLAGS should point to exclusively compiler specific libraries, for each case). Note that the above does not preclude segregating the core MinGW offerings from any add-on libraries, (and their associated headers), which you may have built yourself, (or acquired from an alternative source). You will find tips on setting things up in the following wiki articles:-- http://mingw.org/wiki/IncludePathHOWTO http://mingw.org/wiki/LibraryPathHOWTO http://mingw.org/wiki/SpecsFileHOWTO (In the third case, in particular, be sure to read the comments following the article). -- Regards, Keith. |
From: Earnie B. <ea...@us...> - 2012-07-29 17:38:45
|
On Sat, Jul 28, 2012 at 5:30 PM, Mark Mikofski wrote: > > Do you think the newest prebuilt win32 binaries from xmlsoft are okay to use > interchangably with mingw? > I have no idea. I like to build it myself just because it is easiest for me and I know it's correct. > Also, if I use prefix=/mingw for everything, then should I just keep > installing there as well, or follow LRN's advice and continue to install > them in /local? (the 2nd option would be my preference) > We encourage you to install it into the /mingw path. You will be happier when you try to use it for development because the MinGW GCC will be able to find the headers and libraries without you having to tell it where they are. > Also, if I have used mingw-get install msys-*, will that pollute my mingw > toolchain, if my PATH is /opt/bin:/local/bin:/mingw/bin:/bin, if I always > use prefix=/mingw and install in /local? > MSYS is quite capable of determining which executables are MSYS runtime versus MSVCRT runtime so in reality it shouldn't matter. What does matter is which libraries you use for your native build. The mingw-get default profile is setup to install MSYS and MinGW into separate locations. Your PATH is setup by default to have /mingw/bin ahead of /bin so that you get the MinGW executables first should matching named binaries exist between the two. It is up to you to decide that /opt/bin and /local/bin are safe to put in front of /mingw/bin but generally should be. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: LRN <lr...@gm...> - 2012-07-29 02:23:27
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 29.07.2012 1:30, Mark Mikofski wrote: > first I will have to rebuild libxml2 (2.7.8), since xmlcatalog.exe > is randomly throwing seg faults on both read and write. Build with CFLAGS="-g -O0", and get us some backtraces. This isn't the first time i hear xmlcatalog segfaulting. If it still segfaults on you - - try re-building it without zlib support. Also, i think i should mention that xmlcatalog, when built for MinGW, is incapable of processing MSys paths. Depending on your intentions for using it, that might be a big disadvantage (it was for me). In that case you can rename xmlcatalog.exe (to something like mingw32-xmlcatalog.exe, just to keep it out of the way; presumably, you still need MinGW libxml for other stuff) and use xmlcatalog.exe from msys-libxml. > > Do you think the newest prebuilt win32 binaries from xmlsoft are > okay to use interchangably with mingw? No idea. > Also, if I use prefix=/mingw for everything, then should I just > keep installing there as well, or follow LRN's advice and continue > to install them in /local? (the 2nd option would be my preference) Yes, you'll pollute mingw-get-installed toolchain with your own stuff. On the other hand, configure scripts are sometimes NOT smart enough to look in /usr/local/, and you'll have to specify LOTS of various prefixes to compile something, if your dependencies don't live in /mingw. And will also routinely need to expand PKG_CONFIG_PATH, since it won't automagically detect that you have package info in places other than /mingw/lib/pkgconfig. It's easier to just put things into /mingw. It's also a good idea to pack your stuff in MinGW-compatible way (look at how MinGW packages are built). That, plus some Python scripts - and you'll be able to re-install your toolchain in mere minutes. > > Also, if I have used mingw-get install msys-*, will that pollute > my mingw toolchain, if my PATH is > /opt/bin:/local/bin:/mingw/bin:/bin, if I always use prefix=/mingw > and install in /local? No. Not sure why you have /opt/bin in your PATH, but other than that this looks like correct PATH to have (/mingw/bin has preference over /bin). -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQFJ6TAAoJEOs4Jb6SI2CwbU4H/RxF3m36tRH+3MMr0E7Uk8HO VJjRlFUST7W7jEpwaZ4Xt4HDVTwXPeJI650QR891vjiJqDYYVOEJ/RmZGJjJrUgx f5Vuu2MMRUc9CTW5hECvsfGxnS/5RdKmFT9SKRRHC+maaeZ2cLMUxwJRAVqeib8Y Klp7+jsgRa4E6y3O18ZgPHMILS1oanu2ReBw5NFUIg+1+MjeusNll0SoEgVcX7Tf BbyazAoI35C2W13AQBdm9sJbzzwkh63OV39mcWnUTpPPBgzegRNPoWruajwvQ846 B/krPp+ggVeUIvfwfelLVGUoXwZ9jNtBJeq1eVUseReFrsl7gFec8SBiFuADsb4= =H47S -----END PGP SIGNATURE----- |
From: Damon R. <dre...@cl...> - 2012-07-30 00:59:19
|
On 7/28/2012 10:23 PM, LRN wrote: > Also, i think i should mention that xmlcatalog, when built for MinGW, > is incapable of processing MSys paths. Depending on your intentions > for using it, that might be a big disadvantage (it was for me). Incapable in what way? Is this related to what we are discussing in the "Building libxml2 2.8.0 on WindowsXP fails" thread? If so, does that really mean that it doesn't build ok? I did run into a path problem with xmlcatalog but then with some investigation I found http://www.mingw.org/wiki/Posix_path_conversion and learned a little more about what was happening. I wrote a simple console app that does nothing but print the argument passed to it. I could see the mangling that happens to a string like -//OASIS//DTD DocBook XML V4.3//EN Although I read it a few times I didn't totally understand all the conversion rules or which one was responsible for mangling the above string. I tampered with the msys-core source path.cc to add my own option for not doing any conversion. Tomorrow I will see what happens when I rebuild libxml using the tampered path conversion. I see that Earnie Boyd suggested that I try -///OASIS///DTD DocBook XML V4.3///EN so I will try that too. Damon Register |
From: Earnie B. <ea...@us...> - 2012-07-30 02:01:35
|
On Sun, Jul 29, 2012 at 8:30 PM, Damon Register <dre...@cl...> wrote: > On 7/28/2012 10:23 PM, LRN wrote: >> Also, i think i should mention that xmlcatalog, when built for MinGW, >> is incapable of processing MSys paths. Depending on your intentions >> for using it, that might be a big disadvantage (it was for me). > Incapable in what way? Is this related to what we are discussing in the > "Building libxml2 2.8.0 on WindowsXP fails" thread? If so, does that > really mean that it doesn't build ok? > Some of you must smoke something. Ok, POSIX paths stored in files will not be grokked by "native" (those requiring MSVCRT or equivalent) executables and libraries because in Windows it doesn't exist. It is for this reason we supply an MSYS version of perl. > I did run into a path problem with xmlcatalog but then with some investigation > I found http://www.mingw.org/wiki/Posix_path_conversion and learned a little > more about what was happening. I wrote a simple console app that does > nothing but print the argument passed to it. I could see the mangling > that happens to a string like > -//OASIS//DTD DocBook XML V4.3//EN > Although I read it a few times I didn't totally understand all the > conversion rules or which one was responsible for mangling the above > string. > > I tampered with the msys-core source path.cc to add my own option > for not doing any conversion. Tomorrow I will see what happens when > I rebuild libxml using the tampered path conversion. I see that Earnie > Boyd suggested that I try > -///OASIS///DTD DocBook XML V4.3///EN > so I will try that too. The path conversion should occur only if the path is passed to a program that is "native" and that program is being invoked from an MSYS process. Not all of it is a simple solution and it is quite possible that the only solution such as perl is to create an MSYS runtime enabled application. Since you've begun delving into the MSYS source if you find a resolution that is acceptable please submit a patch file to the patch Tracker for review. Note that I tend not to like user configurable options for MSYS because each one causes the testing time to increase logarithmically. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Damon R. <dre...@cl...> - 2012-07-31 02:31:50
|
On 7/29/2012 10:01 PM, Earnie Boyd wrote: > Some of you must smoke something. Ok, POSIX paths stored in files I wish; then I wouldn't feel this headache :-) > will not be grokked by "native" (those requiring MSVCRT or equivalent) I had to lookup that word and am now more confused. How does it apply to what or what is not done? > executables and libraries because in Windows it doesn't exist. It is > for this reason we supply an MSYS version of perl. What would the Msys version of perl do for this situation or problem? > runtime enabled application. Since you've begun delving into the MSYS > source if you find a resolution that is acceptable please submit a > patch file to the patch Tracker for review. Note that I tend not to I would love to do that. I did come up with one solution but on thinking about it, I realize it is really only to solve a specific problem. Do you have any suggestions for an approach that would be more generally useful? Perhaps I am a little slow in understanding but after reading http://www.mingw.org/wiki/Posix_path_conversion a few times I think I figured out that this is the rule that applies to my particular situation: If an argument has a leading - and the second character is a /, the part from the / onward is converted according to these rules. One thing I am curious about is what sort of cases would have a string starting with -/ Would I want to add a condition to that rule such as do convert when there is -/ but don't convert when there is a -// ? Perhaps an escape character such as in a c string \-// ? Maybe as one person suggested if the string starts with = ? Maybe don't convert when an environment variable is present? Any suggestions? > like user configurable options for MSYS because each one causes the > testing time to increase logarithmically. I thought about that and wondered how testing would be done. Damon Register |
From: Keith M. <kei...@us...> - 2012-07-30 20:23:59
|
On 30/07/12 01:30, Damon Register wrote: > I see that Earnie Boyd suggested that I try > > -///OASIS///DTD DocBook XML V4.3///EN > > so I will try that too. Doesn't work, with current MSYS: $ uname -a MINGW32_NT-6.0 ... 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys $ showargv '-///OASIS///DTD DocBook XML V4.4///EN' argv[0]: c:\Local\MinGW32\local\bin/showargv.exe argv[1]: -///OASIS///DTD DocBook XML V4.4///EN Triple slash is preserved, NOT reduced as intended, but double slashes ARE reduced, AND subjected to path name transformation: $ showargv '-//OASIS//DTD DocBook XML V4.4//EN' argv[0]: c:\Local\MinGW32\local\bin/showargv.exe argv[1]: -/c:/Local/MinGW32/msys/1.0/OASIS/DTD DocBook XML V4.4/EN We COULD get the desired effect, by utilizing a specific prefix, (say '=' for example)... $ showargv '=-//OASIS//DTD DocBook XML V4.4//EN' argv[0]: c:\Local\MinGW32\local\bin/showargv.exe argv[1]: =-//OASIS//DTD DocBook XML V4.4//EN ...IF only MSYS could be cajoled into discarding it, before passing the remainder of the argument string on, verbatim, to the native secondary process. However, I've offered this suggestion several times, over a number of years, and to date it has always fallen on (metaphorically) profoundly deaf ears. I simply don't have the time, (and since I perform all of my Windows development by cross-compiling from Linux, I have little incentive), to pursue this myself. If someone cared enough to provide a patch, (for path.cc), perhaps the MSYS maintainers could be persuaded to at least consider it, and maybe even apply it. -- Regards, Keith. |
From: LRN <lr...@gm...> - 2012-07-30 22:01:59
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 30.07.2012 16:04, Keith Marshall wrote: > On 30/07/12 01:30, Damon Register wrote: >> I see that Earnie Boyd suggested that I try >> >> -///OASIS///DTD DocBook XML V4.3///EN >> >> so I will try that too. > > Doesn't work, with current MSYS: [snip] > > ...IF only MSYS could be cajoled into discarding it, before passing > the remainder of the argument string on, verbatim, to the native > secondary process. However, I've offered this suggestion several > times, over a number of years, and to date it has always fallen on > (metaphorically) profoundly deaf ears. > > I simply don't have the time, (and since I perform all of my > Windows development by cross-compiling from Linux, I have little > incentive), to pursue this myself. If someone cared enough to > provide a patch, (for path.cc), perhaps the MSYS maintainers could > be persuaded to at least consider it, and maybe even apply it. > What exactly is the problem? Can't you use msys-libxml for such things? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQFwRKAAoJEOs4Jb6SI2Cw+0MIANuUj83LCD3YQw4BHSeVYbDJ a+pO1xjt4urRiBvauwHq2EBfXpq3Qpyhik4mT0Ui5W4w7BrErMs9yiH6GzvoGEwB qMC93s+hKhzzObewcL+zgaaH5M0oXj6Rdc2lVKzgpPBEwU778iW+HAxjkFRDXJt4 A30c1k4HOiqZ4/KYVegY7YV37uC59rhEcWSi7KUa7MkQb8kDZUO1DumW3AfJbCKa omMnUiTmkNRvwpe7sruj830aT+TDshQvxJ7tQPFR7PI7fxNFppa4kUi5YtY7qjub NfgA5wcWMXDJfHpxHrEP7j0lGawnyEBUhz4Ab9hPicMnflts1D3uzbHgwNBzXBI= =k8A8 -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2012-07-31 18:54:28
|
On 30/07/12 23:01, LRN wrote: > What exactly is the problem? Can't you use msys-libxml for such things? Huh? How, exactly, would that address a *generic* problem, which is in no way specific to XML, and which pervades all potential MSYS use cases? How do you use msys-libxml, (a library which is specifically designated for use in MSYS applications *only*), when the goal is to support MinGW application building? Please don't add to the confusion, by advocating a taboo use case -- there's enough confusion around already, concerning when it is, and when it isn't legitimate to use MSYS application building components! The problem lies in the core of MSYS itself -- in the heuristically cavalier manner in which it assumes that anything which remotely resembles a POSIX path name must be a POSIX style path name, and so, *must* be transformed to some meaningless Windows style equivalent; there is no escape mechanism to prevent that transformation, even when the user knows better than MSYS, and his/her intent was to pass a particular string verbatim. The XML example, as cited in this thread, is just one case in which it proves impossible to bypass the MSYS heuristics, to get the correct expression of the argument passed through to the native secondary process; it is by no means the only one. As is usually the case, the heuristic algorithm inevitably fails; that there is no escape mechanism to circumvent this particular failure case is, unequivocally, a bug in MSYS core; it (badly) needs to be fixed [*], at source, instead of persistently futzing around with suggestions for ineffective (and often untested) work-arounds. [*] But please, *not* a blanket environment variable solution, which either enables or disables path name transformation entirely. That's a sledgehammer to crack a nut approach; we need a more fine grained solution. -- Regards, Keith. |
From: LRN <lr...@gm...> - 2012-07-31 19:01:28
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31.07.2012 12:53, Keith Marshall wrote: > On 30/07/12 23:01, LRN wrote: >> What exactly is the problem? Can't you use msys-libxml for such >> things? > > Huh? How, exactly, would that address a *generic* problem, which > is in no way specific to XML, and which pervades all potential MSYS > use cases? How do you use msys-libxml, (a library which is > specifically designated for use in MSYS applications *only*), when > the goal is to support MinGW application building? Please don't > add to the confusion, by advocating a taboo use case -- there's > enough confusion around already, concerning when it is, and when it > isn't legitimate to use MSYS application building components! You've mentioned docbook xml files. I assumed that you wanted to use native (mingw) libxml and xmlcatalog with these. You know, for things like gtk-doc and such? If that is the case, then i feel compelled to inform you that gtk-doc works just fine with msys-libxml and xmlcatalog. If that is not the case, then disregard my remark. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQGCt8AAoJEOs4Jb6SI2Cwh94IAL+e6Ipg6s2yWRiXKzAD0OBz eHoOSqJvtbLEGbp5zI57++brLrKzATUhw1iw5SizQ4Uh5uiZfLwEx2ADEApU21Xl E/iyAOWLZX5c8qWVXa0hLIgoc3cXCiny+RVAjBVrSgBULGrusOvq5BTpaB9o0YeS /j8jlhZ4IwFN5lzbNtOIiACoIhl2ZtTLw6desQ6UgBIbhR/XW2PCb2AzYMWh8RX+ RaOzPBwVboUsyjFl7++X/mMoghdskRP7YULF9BheqtC7Z1rJSO7IFjMS4RXcFjIo SZdP/+o3iavrqANsg+425b9O9EzcUg3ye+3i872Vf52rgRmyz2FeOIbhwqypo8U= =OnRz -----END PGP SIGNATURE----- |
From: Keith M. <kei...@us...> - 2012-07-31 19:25:55
|
On 31/07/12 20:01, LRN wrote: > You've mentioned docbook xml files. I did not. > I assumed that you wanted to use native (mingw) libxml and xmlcatalog > with these. You know, for things like gtk-doc and such? That may have been the OP's intent; mine was to point out that this is just another instance of a (moderately serious) *generic* issue, which has been reported on several occasions over a period of several years, yet it appears that not the slightest effort has been directed toward addressing, let alone resolving it. > If that is the case, then i feel compelled to inform you that gtk-doc > works just fine with msys-libxml and xmlcatalog. It is not the case. > If that is not the case, then disregard my remark. I shall; it is irrelevant. -- Regards, Keith. |
From: Damon R. <dre...@cl...> - 2012-07-31 23:57:12
|
On 7/31/2012 3:25 PM, Keith Marshall wrote: > On 31/07/12 20:01, LRN wrote: >> You've mentioned docbook xml files. > > I did not. That was I who mentioned that. > That may have been the OP's intent; mine was to point out that this is > just another instance of a (moderately serious) *generic* issue, which That was my original intent but I am with you in wanting to fix the more general problem and not just find a workaround. I may have gotten past that point but unfortunately I am just stuck at a new point. I am trying to build Glade which might need gnome-doc-utils which might need a useable python. I had used the windows installer from python.org but that seems to be missing python-config. As far as the MSYS path issue, I am ok for now but I would still like to come up with a more useful, more general approach for that. Damon Register |
From: Earnie B. <ea...@us...> - 2012-08-01 00:04:01
|
On Tue, Jul 31, 2012 at 7:57 PM, Damon Register wrote: > On 7/31/2012 3:25 PM, Keith Marshall wrote: >> On 31/07/12 20:01, LRN wrote: >>> You've mentioned docbook xml files. >> >> I did not. > That was I who mentioned that. > >> That may have been the OP's intent; mine was to point out that this is >> just another instance of a (moderately serious) *generic* issue, which > That was my original intent but I am with you in wanting to fix the more > general problem and not just find a workaround. I may have gotten past > that point but unfortunately I am just stuck at a new point. I am trying > to build Glade which might need gnome-doc-utils which might need a useable > python. I had used the windows installer from python.org but that seems > to be missing python-config. As far as the MSYS path issue, I am ok for > now but I would still like to come up with a more useful, more general > approach for that. I've done some of it. You need to be specific in the PYTHON* environment variables and you need to configure python appropriately. I'll ping you off list tomorrow with a draft document I was working on that might help. It's rather ugly stuff. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Cesar S. <ces...@gm...> - 2012-08-01 00:58:26
|
On 7/29/2012 9:30 PM, Damon Register wrote: > I did run into a path problem with xmlcatalog but then with some investigation > I found http://www.mingw.org/wiki/Posix_path_conversion and learned a little > more about what was happening. I wrote a simple console app that does > nothing but print the argument passed to it. I could see the mangling > that happens to a string like > -//OASIS//DTD DocBook XML V4.3//EN Try: $ cmd //c echo '-//OASIS//DTD DocBook XML V4.3//EN' "-/C:/programas/msys/OASIS/DTD DocBook XML V4.3/EN" $ mount /OASIS /OASIS $ cmd //c echo "-//OASIS//DTD DocBook XML V4.3//EN" "-//OASIS/DTD DocBook XML V4.3/EN" Regards, Cesar |
From: Earnie B. <ea...@us...> - 2012-08-01 13:54:45
|
On Tue, Jul 31, 2012 at 8:58 PM, Cesar Strauss wrote: > On 7/29/2012 9:30 PM, Damon Register wrote: >> I did run into a path problem with xmlcatalog but then with some investigation >> I found http://www.mingw.org/wiki/Posix_path_conversion and learned a little >> more about what was happening. I wrote a simple console app that does >> nothing but print the argument passed to it. I could see the mangling >> that happens to a string like >> -//OASIS//DTD DocBook XML V4.3//EN > > Try: > > $ cmd //c echo '-//OASIS//DTD DocBook XML V4.3//EN' > "-/C:/programas/msys/OASIS/DTD DocBook XML V4.3/EN" > > $ mount /OASIS /OASIS > > $ cmd //c echo "-//OASIS//DTD DocBook XML V4.3//EN" > "-//OASIS/DTD DocBook XML V4.3/EN" Not good enough the //DTD was modified to /DTD and the //EN was modified to /EN. -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Keith M. <kei...@us...> - 2012-08-01 17:55:06
|
On 01/08/12 01:58, Cesar Strauss wrote: > Try: > > $ cmd //c echo '-//OASIS//DTD DocBook XML V4.3//EN' > "-/C:/programas/msys/OASIS/DTD DocBook XML V4.3/EN" > > $ mount /OASIS /OASIS > > $ cmd //c echo "-//OASIS//DTD DocBook XML V4.3//EN" > "-//OASIS/DTD DocBook XML V4.3/EN" But see, this is just another failed attempt to kludge around the issue; notice that the generated XPath expression -//OASIS/DTD DocBook XML V4.3/EN is NOT the same as -//OASIS//DTD DocBook XML V4.3//EN which is what the user specified; (XPath attributes DIFFERENT meanings to // and /). It's time to stop futzing around with these half-hearted attempts to kludge around this long standing issue; a deterministic solution is long overdue. -- Regards, Keith. |
From: LRN <lr...@gm...> - 2012-08-01 06:29:57
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01.08.2012 3:57, Damon Register wrote: > On 7/31/2012 3:25 PM, Keith Marshall wrote: >> On 31/07/12 20:01, LRN wrote: >>> You've mentioned docbook xml files. >> >> I did not. > That was I who mentioned that. > >> That may have been the OP's intent; mine was to point out that >> this is just another instance of a (moderately serious) *generic* >> issue, which > That was my original intent but I am with you in wanting to fix the > more general problem and not just find a workaround. I may have > gotten past that point but unfortunately I am just stuck at a new > point. I am trying to build Glade which might need gnome-doc-utils > which might need a useable python. See [1]. Basically, you need to hack bootstrap.make to account for DOS paths, hack xml2po/modes/Makefile.am to convert backslashes to slashes. It also wouldn't hurt to tell it to put pkgconfig in libdir (though that is actually optional - pkgconfig.exe will look in both libdir and datadir, though i think libdir is somewhat more canonical). [1] http://lrn.no-ip.info/other/mingw/mingw32/gnome-doc-utils/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQGMzTAAoJEOs4Jb6SI2CwEJkIANW2yGyFzymuyWztrxZu5sn3 0j+uKKcLSRtpxkLl25/CMLrko0K86b7H93cvTQfidM+UNIJ0Pv8BdojRkrBb/2o6 hjzD7aLY8u08ZPTF4nQM/aKeN0qkBGXDFmwhdYqRYtT9fZl4awZzGs7EhC8gEeYY x6+Tb2sojfx2nj40CXx/MnA6UPb9ToAIZf48CT3840JYg7jqYuifg/L1kB0UBBM+ m725/5nEu2knqMjo2yd+SVzHVox580ez0Lagtdv06mpVuZ6q1x65qOTDGuv//yCt JPg8eMO35U1C9qGMv0KR7hITXPQJdP06bJCDFJ5xyG/LzAKWIRBH5vFXmdIjdTg= =lROr -----END PGP SIGNATURE----- |
From: Damon R. <dre...@cl...> - 2012-08-06 01:22:21
|
On 8/1/2012 2:29 AM, LRN wrote: > See [1]. I just did. Thanks. It looks like you already did the work. > Basically, you need to hack bootstrap.make to account for DOS paths, > hack xml2po/modes/Makefile.am to convert backslashes to slashes. maybe I will try a file compare between yours and the original so I should be able to see exactly what you did. > It also wouldn't hurt to tell it to put pkgconfig in libdir (though > that is actually optional - pkgconfig.exe will look in both libdir and I am not sure that I follow. I thought that it looked in what is defined by PKG_CONFIG_PATH Thanks again for your help. Damon Register |