bug unknown type "mbstate_t" in iconv.h

classic Classic list List threaded Threaded
28 messages Options
12
Reply | Threaded
Open this post in threaded view
|

bug unknown type "mbstate_t" in iconv.h

Mark Mikofski
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

doesn't compile anyway due to another type error in one of their headers (proto.h unknown type is sigjmp_buf)

expected: compiles

build:
gcc 4.7 installed with mingw-get, everything is current
windows XP
 

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

lrn-2
-----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?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJQEg1QAAoJEOs4Jb6SI2CwGJAH/iGpHZR2yvUsKXdZxtVdpGW6
WnY5bWtbr4+U1NJb29EXrjibjbtzuuKFVIXGQDKehWEpGHydzvO6hCslfP4Uzb/b
Ed2iW3Te9MKhbSOf2fab0CDRERwGhUm2pGaIGFiJvz3FNJ4PcC4UutwJNAFrDusv
j+ZDJpNK6GE0w1mi+z7xpjL7dgXmAWnaNeTFUMBmHQi1U8a3p0yawAkRZcNyP6P0
6wDEXjxHUBEIFjfOYvbWI54zEaGmOGagTrihVuN7uchgty46YH+1EmOPUMKs+V/3
R7DHOxMrGXyDnH6ki6oRCh/DuiqTP1YwWsVZmEnq0184+ElwGjpL/f8utTUz2sY=
=aWCS
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Mark Mikofski
In reply to this post by Mark Mikofski
------------------------------
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,


and


The mingw version has a build script, so maybe I can follow that. Thanks again for your help!


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Eli Zaretskii
> Date: Fri, 27 Jul 2012 11:34:35 -0700 (PDT)
> From: Mark Mikofski <[hidden email]>
>
> >>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?


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Mark Mikofski
> Date: Fri, 27 Jul 2012 11:34:35 -0700 (PDT)
> From: Mark Mikofski <[hidden email]>
>
> >>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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

lrn-2
In reply to this post by Mark Mikofski
-----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-----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

lrn-2
In reply to this post by Mark Mikofski
-----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 <[hidden email]>
>>>
>>>>> 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-----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Keith Marshall
In reply to this post by lrn-2
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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Mark Mikofski
From: Keith Marshall <[hidden email]>
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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

lrn-2
-----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-----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Keith Marshall
In reply to this post by Mark Mikofski
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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Earnie Boyd
In reply to this post by Mark Mikofski
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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Damon Register-3
In reply to this post by lrn-2
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


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Earnie Boyd
On Sun, Jul 29, 2012 at 8:30 PM, Damon Register <[hidden email]> 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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Keith Marshall
In reply to this post by Damon Register-3
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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

lrn-2
-----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-----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug unknown type "mbstate_t" in iconv.h

Damon Register-3
In reply to this post by Earnie Boyd
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


------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug: MSYS path transformation heuristics are broken; (was: unknown type "mbstate_t" in iconv.h)

Keith Marshall
In reply to this post by lrn-2
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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug: MSYS path transformation heuristics are broken;

lrn-2
-----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-----

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: bug: MSYS path transformation heuristics are broken;

Keith Marshall
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.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
MinGW-users mailing list
[hidden email]

This list observes the Etiquette found at
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:[hidden email]?subject=unsubscribe
12