Nabble - MinGW - User

Re: STLPort test units won't build

2009-12-20T01:55:03Z

On Sunday 20 December 2009 02:25:25 Greatwolf wrote:
> I am able to build stlport 5.2.1 successfully under MinGW
> (installed with mingw-5.1.6.exe) but for some reason building the
> test units in it results in compiler errors:
>
> error: declaration of C function Long InterlockedDecrement
> conflicts with...
> error: declaration of C function Long InterlockedIncrement...
> error: declaration of C function Long InterlockedExchange...

Looks like *some* of the Increment* function prototypes have been
incorrectly declared in w32api's winbase.h; (MSDN says some should
be __cdecl, but w32api declares all as WINAPI, (i.e. __stdcall)).

> The problem seems to be a redeclaration of those functions between
> winbase.h header file supplied by mingw and the _windows.h header
> file supplied by stlport.

This wouldn't be a problem, if the declarations were correct, (thus
consistent), in both places; the *real* problem is those incorrect
declarations in w32api.

> I searched around for possible solutions and this one seem to come
> close:
>
> http://www.codesynthesis.com/projects/xsd/extras/build-windows.xht
>ml
>
> The compiler errors match the ones that I am seeing when I try to
> build it. But the site says this problem might happen if your
> using an older version of cygwin. I couldn't find this problem as
> it relates to using mingw tools.

Cygwin and mingw32 share a common code base for w32api; if it's wrong
for one, it will be similarly wrong for the other.

> Why does this happen and how should this be resolve?

The bugs in w32api need to be fixed. I don't have time to address
it right now, so please file a formal bug report, (on the bug tracker
please), so that it isn't forgotten: http://mingw.org/Reporting_Bugs

--

Regards,
Keith.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

STLPort test units won't build

2009-12-19T18:25:25Z

I am able to build stlport 5.2.1 successfully under MinGW (installed with
mingw-5.1.6.exe) but for some reason building the test units in it results
in compiler errors:

error: declaration of C function Long InterlockedDecrement conflicts
with...
error: declaration of C function Long InterlockedIncrement...
error: declaration of C function Long InterlockedExchange...

The problem seems to be a redeclaration of those functions between
winbase.h header file supplied by mingw and the _windows.h header file
supplied by stlport.

I searched around for possible solutions and this one seem to come close:

http://www.codesynthesis.com/projects/xsd/extras/build-windows.xhtml

The compiler errors match the ones that I am seeing when I try to build it.
But the site says this problem might happen if your using an older version
of cygwin. I couldn't find this problem as it relates to using mingw tools.
Why does this happen and how should this be resolve?

Thanks

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: unresolved external symbol ___mingw_vprintf

2009-12-19T08:58:38Z

On 12/19/2009 22:05, Olumide wrote:

> On 12/15/2009 4:37 AM, JonY wrote:
>> On 12/15/2009 10:37, Olumide wrote:
>>> I've just compiled a library with MINGW. My intention is to use this
>>> library in Visual Studio .NET. Unfortunately, when I try to link the
>>> library, I get the following linker error:
>>>
>>> error LNK2019: unresolved external symbol ___mingw_vprintf referenced in
>>> function _printf
>>>
>>> I've removed all references to printf in my code but the error persists.
>>>
>>> I'd appreciate any advise toward resolving this error. Regards,
>>
>> try adding libmingwex.a to the MSVC linker command.
>
> I've added libmingwwex.a, now I'm getting the following errors:
>
> libmingwex.a(pformat.o) : error LNK2019: unresolved external symbol
> ___umoddi3 referenced in function ___pformat_int
> libmingwex.a(pformat.o) : error LNK2019: unresolved external symbol
> ___udivdi3 referenced in function ___pformat_int
> libmingwex.a(pformat.o) : error LNK2019: unresolved external symbol
> __alloca referenced in function ___pformat_int
> libmingwex.a(pformat.o) : error LNK2019: unresolved external symbol
> __get_output_format referenced in function ___mingw_pformat
>

Hi,

Those symbols are from libgcc.a, so add that to the link command too.

"_get_output_format" is in libmsvcrt.a, but I'm not sure about mixing
runtimes, ymmv.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: unresolved external symbol ___mingw_vprintf

2009-12-19T06:05:30Z

On 12/15/2009 4:37 AM, JonY wrote:

> On 12/15/2009 10:37, Olumide wrote:
>> I've just compiled a library with MINGW. My intention is to use this
>> library in Visual Studio .NET. Unfortunately, when I try to link the
>> library, I get the following linker error:
>>
>> error LNK2019: unresolved external symbol ___mingw_vprintf referenced in
>> function _printf
>>
>> I've removed all references to printf in my code but the error persists.
>>
>> I'd appreciate any advise toward resolving this error. Regards,
>
> try adding libmingwex.a to the MSVC linker command.

I've added libmingwwex.a, now I'm getting the following errors:

libmingwex.a(pformat.o) : error LNK2019: unresolved external symbol
___umoddi3 referenced in function ___pformat_int
libmingwex.a(pformat.o) : error LNK2019: unresolved external symbol
___udivdi3 referenced in function ___pformat_int
libmingwex.a(pformat.o) : error LNK2019: unresolved external symbol
__alloca referenced in function ___pformat_int
libmingwex.a(pformat.o) : error LNK2019: unresolved external symbol
__get_output_format referenced in function ___mingw_pformat

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-19T02:44:17Z

> Tada, a UTF-8 Character. It actually is represented by more than one
> byte in terms of memory storage size.

This might seem like a minor terminological nit, but it is a *Unicode*
code point for a Chinese character, *encoded* as UTF-8. UTF-8 is not a
set of characters. It might be a "charset" as that term usually is
used for the combination of a character set and an encoding of it.

>> What makes you think he is interested in using GLib?
> Mr. Smorigo mentioned he was using C++: "int RecFile::openFile"

(In fact he said: "int RecFile::openFile(const wchar_t *fileName)" ,
note the wchar_t even. There is very little in GLib API that would use
wchar_t.)

Being a GLib maintainer, I hate to say this, but let's be realistic
here: In no way is GLib (in the form of its C++ binding, glibmm) the
ubiquitous or immediately obvious way to handle Unicode or character
set issues in C++, especially not on Windows.

GLib and glibmm is mostly used by software originally written for
Linux and usually in the GNOME-oriented subculture of Linux. (Although
GLib is used by lots of software that does not use GNOME APIs, too,
like GIMP for instance.) Software written for Windows from the start
that wants to be Unicode aware tends to Microsoft style code with
<tchar.h> and all that crack, sadly.

> In fact, Mr. Smorigo just took my advice because he understood my train
> of thought.
>> The Glib::locale_from_utf8 is perfect!

Sure, so you were lucky.

> There is a need to go exotic as you say because, utf8 is the way to go.

Of course I agree with that. That doesn't change the fact that the
Microsft C library which is from where MinGW-compiled code gets
functions like fopen() is not really UTF-8-friendly.

> Again, he's using C++, and using Glib::ustring is the recommended way to
> go for internationalization in a platform-independant manner.

As much as I might enjoy that to be true, it simply isn't.

> Have a good day, and hopefully one day we could talk about something
> else over a beer instead.

That sounds like a good idea. Mail me when you are in Helsinki;)

--tml

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T18:00:50Z

Raffaello D. Di Napoli wrote:
> I don’t mean to be mean, but I really felt the urge to correct such
> gross inaccuracies.
> R
The beauty of the forum is one may say something not quite accurate, but
the intended audience will get the gist. All of you got the gist, it
seems. I'm happy to hear it.

Merry Christmas and Happy New Year.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T16:01:09Z

2009/12/18 uticdmarceau2007@... <uticdmarceau2007@...>:
>>> UTF16 strings are wide character strings. A UTF16 character is a wide
>>> character made of exactly 4 bytes. wchar is 4 bytes == 4 chars in terms
>>> of storage size.

I’d like to restate this is entirely wrong, and trying to defend such
an incorrect statement just brings more confusion to the reader and
disproves your self-proclaimed qualifications.

> Historically, a byte(unsigned 8bit) to represent one char, but
> later on it became redefined as an int internally which is 16bits.

No such thing. On the Windows platform, “later on” (early nineties,
Win32) Microsoft switched to Unicode using 16-bit UTF-16 encoding
(mapped to wchar_t), while in the rest of the software world (AFAIK)
the switch was to using variable-length UTF-8 encoding or fixed-length
32-bit UTF-32 encoding (also mapped to wchar_t).

Besides, the size of an int is not 16 bits. Not by definition, nor by
current usage, since nowadays int is most often 32 bits in size.

> So 16bits are actually used for each character typed char in win32, but
> the name utf8 stuck.

Nothing stuck: Win32 uses UTF-16 for Unicode text. That’s why it uses
16 bits per code point (you don’t call them “characters”...), except
surrogates requiring two UTF-16 characters (...and here’s why).

> So when you take two char types to make a UTF16 Unicode character, you
> get an int plus another int which is actually 16bits+16bit = 32bits/8 =
> 4bytes.
> So one wide char was defined in the headers as WORD = 32 bits.
> WORD = WCHAR = wchar
> == 2 16-bit char(i.e. assember 8088 ax
> == 4 8-bit char(i.e. 8088 assembler al/ah)

This is complete nonsense, starting from the fact that WORD in Win32
is a typedef to unsigned short, so (still in Win32) 16 bits, not 32.
Furthermore, the fact that WORD happens to be the same size as wchar_t
(in Win32 only!) is merely a coincidence.

>> Sorry, but here you are completely wrong. The "16" in the name
>> "UTF-16" isn't just a random number. What might it mean? Think!
>
> I'm actually correct. Given the context of what I was talking about.
> UTF8 is all about 8-bit char
> UTF16 is worth 4 8-bit char.

No, you’re far from being correct in any context, as I pointed out
above. Please read the relevant documentation before spreading such
inaccurate and incorrect information.

Here’s a few starting points:
http://en.wikipedia.org/wiki/Unicode
http://unicode.org/

What’s an encoding’s “worth”, anyway?

> Again, he's using C++, and using Glib::ustring is the recommended way to
> go for internationalization in a platform-independant manner.

Recommended by who?

I don’t mean to be mean, but I really felt the urge to correct such
gross inaccuracies.
--
R

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T12:57:16Z

Tor Lillqvist wrote:
>> A utf8 character is a sequence of bytes to describe a single character
>> in any language.
>
> Well... yes and no. There is no such thing as a "UTF-8 character".
> What you mean is the UTF-8 representation of a Unicode code point
> ("character").
I don't mean to flame, but I need to tell you there is such a thing as a
UTF-8 character. Take a language like Chinese and here is one Chinese
character in utf8 that follows:
马
Tada, a UTF-8 Character. It actually is represented by more than one
byte in terms of memory storage size.

>> What distinguishes a utf8 string from a normal std::string is that it's
>> storage size may in fact be larger than the actually displayed to
>> console/gui string.
It actually is represented by more than one byte in terms of memory
storage size. This number is very different from the
Glib::ustring::length() service which is the length of characters that
you see displayed in a console.

In order for you to see the actual number of bytes used in memory
storage, you would do something like ustring::bytes() and
bytearray::size(). But like I said Glib::ustring classes are helping
you by hiding all of this noise to focus on the real task at hand. This
is what makes C++ relevant and Glib relevant contrary to what you said.

> What makes you think he is interested in using GLib?

Mr. Smorigo mentioned he was using C++: "int RecFile::openFile"

> Which is a quite confusing way to say it, what you mean is simply "a
> character might take one or several bytes".
>
>> Although a U.S. character is represented by one byte,
>
> "U.S. character" ? You probably mean US-ASCII. But then, the same
> holds for strings in other single-byte charsets like the ISO8859-*
> ones. Nothing "U.S." in them..
Mr. Tor, I need to correct you. It is not a confusing way to say it.
It is simply another way to express it in order look at it with another
perspective. If you read the docs, you may understand it at first
glance, but their are others who may not. I am only re-expressing it to
help them visualize it another way: distinguish following aspects of
internationalizing strings: 1)storage size in terms of bytes 2)length of
the displayed string 3)conversion services available in win32,
4)conversion services available in POSIX(unix/posix/linux/ibm) via C or
C++. That's it.

In fact, Mr. Smorigo just took my advice because he understood my train
of thought.
> The Glib::locale_from_utf8 is perfect! I convert the string
> and then send to the stdout. The receiver get the string and use
> fopen_s to open it. it WORKED!!

You're welcome Mr. Smorigo.

>> a Chinese or Japanese character may be represented by two or more bytes.
>
> No need to go that "exotic", even fully acceptable English words like
> façade and séance are spelled with non-ASCII letters. Not to mention
> all other European languages.
There is a need to go exotic as you say because, utf8 is the way to go.
The sooner you adapt, the less headaches you'll have. It's the only
encoding format you can use to display all known language characters
into one html page without display issues.
That's why I set my encoding in the email/web/whatever to utf8.

>> UTF16 strings are wide character strings. A UTF16 character is a wide
>> character made of exactly 4 bytes. wchar is 4 bytes == 4 chars in terms
>> of storage size.
>
>
Please try your best not to get hung up on my reexpression. It's not
constructive. To reexpress it UTF8 means 8bit representation mechanisms
and UTF16 mean 16bit representation mechanisms for the same thing:
UNICODE. Historically, a byte(unsigned 8bit) to represent one char, but
later on it became redefined as an int internally which is 16bits.
So 16bits are actually used for each character typed char in win32, but
the name utf8 stuck.
So when you take two char types to make a UTF16 Unicode character, you
get an int plus another int which is actually 16bits+16bit = 32bits/8 =
4bytes.
So one wide char was defined in the headers as WORD = 32 bits.
WORD = WCHAR = wchar
== 2 16-bit char(i.e. assember 8088 ax
== 4 8-bit char(i.e. 8088 assembler al/ah)
> Sorry, but here you are completely wrong. The "16" in the name
> "UTF-16" isn't just a random number. What might it mean? Think!
I'm actually correct. Given the context of what I was talking about.
UTF8 is all about 8-bit char
UTF16 is worth 4 8-bit char.

So Mr. Tor, you are an expert and I am the first to acknowledge it, but
PLEASE focus on helping rather trying to discredit my technical ability.

>> Now here is my recommendation:
>> Use Glib::ustring for all your strings instead of the std::string.
>
> What makes you think he is interested in using GLib?
Rather than questioning my ability to read Mr. Smorigo's mind, please
understand Mr. Lillqvist, I'm providing just one way to fix the problem
quickly. There are other ways, but this one is good.
Again, he's using C++, and using Glib::ustring is the recommended way to
go for internationalization in a platform-independant manner. Besides
it doesn't need a pre-compiler like moc which is a bonus.
In fact he did use it to fix his problem as I mentioned above.

Have a good day, and hopefully one day we could talk about something
else over a beer instead.

Cheers,
David Marceau

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T11:44:57Z

Genial!!! The Glib::locale_from_utf8 is perfect! I convert the string
and then send to the stdout. The receiver get the string and use
fopen_s to open it. it WORKED!!

Thanks for all!

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T09:56:06Z

> A utf8 character is a sequence of bytes to describe a single character
> in any language.

Well... yes and no. There is no such thing as a "UTF-8 character".
What you mean is the UTF-8 representation of a Unicode code point
("character").

> What distinguishes a utf8 string from a normal std::string is that it's
> storage size may in fact be larger than the actually displayed to
> console/gui string.

Which is a quite confusing way to say it, what you mean is simply "a
character might take one or several bytes".

> Although a U.S. character is represented by one byte,

"U.S. character" ? You probably mean US-ASCII. But then, the same
holds for strings in other single-byte charsets like the ISO8859-*
ones. Nothing "U.S." in them..

> a Chinese or Japanese character may be represented by two or more bytes.

No need to go that "exotic", even fully acceptable English words like
façade and séance are spelled with non-ASCII letters. Not to mention
all other European languages.

> UTF16 strings are wide character strings. A UTF16 character is a wide
> character made of exactly 4 bytes. wchar is 4 bytes == 4 chars in terms
> of storage size.

Sorry, but here you are completely wrong. The "16" in the name
"UTF-16" isn't just a random number. What might it mean? Think!

> Now here is my recommendation:
> Use Glib::ustring for all your strings instead of the std::string.

What makes you think he is interested in using GLib?

--tml

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: What license is mingwm10.dll?

2009-12-18T09:33:00Z

> From: Katarzyna Matylla <erina@...>

> To: mingw-users@...
> Sent: Fri, December 18, 2009 8:03:39 AM
> Subject: [Mingw-users] What license is mingwm10.dll?

> I have a question - as in the topic: is mingwm10.dll GLP'ed, or is it on
> some more liberal license or public domain (is it a part of the
> runtime?)? May I distribute this file with in my commercial program?
>
> I know it's probably been answered (I have searched the archive and
> site), but I'm not sure if I understand the answers I have found, so I
> ask for a simple, yes/no answer, because I want to be sure and I need to
> have the program ready on Tuesday.
>
> And if I cannot use it, could you explain how to get rid of the
> dependency (I'm using MinGW with Eclipse, on WinXP)? I don't need
> exceptions that much.

Link the main program at least with the option -static-libgcc. This should remove any runtime dependencies. You might need to re-link other libraries you use with -static-libgcc as well, but if the link goes without errors you're probably fine. Then e-mail it to someone else with no compilers on their machine to test it. Good luck.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T09:25:05Z

Paulo Flabiano Smorigo wrote:

> Hi everyone,
>
> Thanks for the support. It's been very helpful!
>
> I'm using CreateProcessWithPipes from Windows API. Now I discovered
> that the client side (the process that get the line from the stdin) is
> getting the code in utf8 format. Now the problem is that the _wfopen_s
> is returning a code 22 (Invalid argument).
>
> The code that I'm using:
>
> int RecFile::openFile(const wchar_t *fileName)
> {
> errno_t err = _wfopen_s(&recFile, fileName, L"wb");
> ...
>

**************************
NOISE
****************************

> If I understood correctly, the wchar_t stores the string in utf8 format, is it?
NO, wchar_t is not a utf8 string.
A utf8 character is a sequence of bytes to describe a single character
in any language. A utf8 string is typed as char * and not wchar *.
What distinguishes a utf8 string from a normal std::string is that it's
storage size may in fact be larger than the actually displayed to
console/gui string. Although a U.S. character is represented by one
byte, a Chinese or Japanese character may be represented by two or more
bytes. The internationalization api's are doing their best to hide this
noise. UTF8 is the UNIX/IBM/LINUX approach. THE WEB and XML has
standardized on UTF8.

UTF16 strings are wide character strings. A UTF16 character is a wide
character made of exactly 4 bytes. wchar is 4 bytes == 4 chars in terms
of storage size. UTF16 is the MICROSOFT approach just because they can$$$.

********************************
What you want
********************************
fileName must be wchar_t in order for _wfopen_s() to compile correctly.
So I imagine you used a std:string object that you passed to
RecFile::openFile().

Now here is my recommendation:
Use Glib::ustring for all your strings instead of the std::string.

std::string somestdstring;
Glib::ustring someglibFileName(somestdstring);

//using this service
//std::string Glib::locale_from_utf8(const Glib::ustring& utf8_string)
int blah = RecFile::openFile(locale_from_utf8(someglibFileName).c_str());

*******************************
NOISE

READ:
http://library.gnome.org/devel/glibmm/stable/classGlib_1_1ustring.html
http://library.gnome.org/devel/gtkmm-tutorial/unstable/chapter-internationalization.html.en

***********************************
MORE NOISE

If all else fails you may try these, but you shouldn't have to because
the above Glib::ustring provides similar platform-independent services.

std::wstring s2ws(const std::string& s)
{
int len;
int slength = (int)s.length() + 1;
len = MultiByteToWideChar(CP_ACP, 0, s.c_str(), slength, 0, 0);
wchar_t* buf = new wchar_t[len];
MultiByteToWideChar(CP_ACP, 0, s.c_str(), slength, buf, len);
std::wstring r(buf);
delete[] buf;
return r;
}

std::string s;

#ifdef UNICODE
std::wstring stemp = s2ws(s); // Temporary buffer is required
LPCWSTR result = stemp.c_str();
#else
LPCWSTR result = s.c_str();
#endif

std::string ws2s(const std::wstring& s)
{
int len;
int slength = (int)s.length() + 1;
len = WideCharToMultiByte(CP_ACP, 0, s.c_str(), slength, 0, 0, 0, 0);
char* buf = new char[len];
WideCharToMultiByte(CP_ACP, 0, s.c_str(), slength, buf, len, 0, 0);
std::string r(buf);
delete[] buf;
return r;
}

OR

std::wstring s2ws (const std::string& s)
{
std::wstring ws;
ws.assign (s.begin (), s.end ());
return ws;
}

std::string ws2s (const std::wstring& ws)
{
std::wstring s;
s.assign (ws.begin (), ws.end ());
return s;
}

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: What license is mingwm10.dll?

2009-12-18T08:59:29Z

On Fri, Dec 18, 2009 at 6:32 PM, Greg Chicares <gchicares@...> wrote:

I see no license here:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mthr.c?annotate=1.2&cvsroot=src
so I'd assume that this governs:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/DISCLAIMER?annotate=1.2&cvsroot=src
* This file has no copyright assigned and is placed in the Public Domain.
* This file is a part of the mingw-runtime package.
That's consonant with:
http://mingw.org/license
| MinGW runtime: The MinGW base runtime package has been placed in the
| public domain, and is not governed by copyright. This basically means
| that you can do what you like with the code.

That just means that this specific code is not licensed. At all. Should be trivial to as the two developers (am I reading correct the code..?) to explicitly mention the license.

Greg, this is by far, more "problematic" then having un-properly licensed code at all.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T08:48:30Z

On 12/19/2009 00:45, JonY wrote:

> On 12/19/2009 00:45, Paulo Flabiano Smorigo wrote:
>> Correct... 61 is for 'a', C3 A7 is for 'ç', C3 A3 is for 'ã' and 6F
>> for 'o'.
>>
>>
>
> Hi,
> use MultiByteToWideChar to convert from utf-8 to win32 compatible text.
>
> See: <http://msdn.microsoft.com/en-us/library/dd319072%28VS.85%29.aspx>

I meant win32 definitions of wide strings.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T08:45:13Z

On 12/19/2009 00:45, Paulo Flabiano Smorigo wrote:
> Correct... 61 is for 'a', C3 A7 is for 'ç', C3 A3 is for 'ã' and 6F for 'o'.
>
>

Hi,
use MultiByteToWideChar to convert from utf-8 to win32 compatiple text.

See: <http://msdn.microsoft.com/en-us/library/dd319072%28VS.85%29.aspx>

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T08:45:05Z

Correct... 61 is for 'a', C3 A7 is for 'ç', C3 A3 is for 'ã' and 6F for 'o'.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T08:39:51Z

On 2009-12-18 16:10Z, Paulo Flabiano Smorigo wrote:
>
> Looking at the bytes, the word "ação" came as 61 C3 A7 C3 A3 6F. So,
> this is compatible with wchar_t?

61 is ASCII 'a', and 6f is ASCII 'o', so I'd guess this is UTF-8.
But wchar_t would be UTF-16.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: What license is mingwm10.dll?

2009-12-18T08:32:43Z

On 2009-12-18 16:03Z, Katarzyna Matylla wrote:
>
> [...] is mingwm10.dll GLP'ed, or is it on
> some more liberal license or public domain (is it a part of the
> runtime?)? May I distribute this file with in my commercial program?

I see no license here:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/mthr.c?annotate=1.2&cvsroot=src
so I'd assume that this governs:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/winsup/mingw/DISCLAIMER?annotate=1.2&cvsroot=src
* This file has no copyright assigned and is placed in the Public Domain.
* This file is a part of the mingw-runtime package.
That's consonant with:
http://mingw.org/license
| MinGW runtime: The MinGW base runtime package has been placed in the
| public domain, and is not governed by copyright. This basically means
| that you can do what you like with the code.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T08:10:32Z

Hi again,

Looking at the bytes, the word "ação" came as 61 C3 A7 C3 A3 6F. So,
this is compatible with wchar_t?

The wfopen_s understand it?

Thanks,
Paulo

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

What license is mingwm10.dll?

2009-12-18T08:03:39Z

Hello everyone, I'm new on this list. And pretty new in serious
programming, too.

I have a question - as in the topic: is mingwm10.dll GLP'ed, or is it on
some more liberal license or public domain (is it a part of the
runtime?)? May I distribute this file with in my commercial program?

I know it's probably been answered (I have searched the archive and
site), but I'm not sure if I understand the answers I have found, so I
ask for a simple, yes/no answer, because I want to be sure and I need to
have the program ready on Tuesday.

And if I cannot use it, could you explain how to get rid of the
dependency (I'm using MinGW with Eclipse, on WinXP)? I don't need
exceptions that much.

Thank you very much in advance and sorry for my poor English, I'm not a
native speaker.

--
Katarzyna Matylla

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T07:22:05Z

2009/12/18 Tor Lillqvist <tml@...>:
> (Actually, I guess one should say "Unicode code point" instead of
> "Unicode character"?)

http://unicode.org/glossary/#code_point

I guess that would be a ”yes”?

--
R

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T05:47:49Z

> I'm using CreateProcessWithPipes from Windows API.

Huh? There is no such API.

> If I understood correctly, the wchar_t stores the string in utf8 format, is it?

Nope. On no platforms I know wchar_t would be UTF-8. That would be rather odd.

On Windows, a "wide" or wchar_t string is UTF-16 (one 16 bit integer
(little endian on Windows) per wchar_t "element", with those rare
Unicode characters that are outside the BMP thus requiring a so-called
surrogate pair, taking two wchar_t elements). On modern Unixes it is
UCS-4 (32 bits, one Unicode character per wchar_t element).

UTF-8 consists of *bytes* in a well-defined platform-independent
sequence, so it can be stored in plain C char strings just fine.

(Actually, I guess one should say "Unicode code point" instead of
"Unicode character"?)

--tml

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-18T05:22:57Z

Hi everyone,

Thanks for the support. It's been very helpful!

I'm using CreateProcessWithPipes from Windows API. Now I discovered
that the client side (the process that get the line from the stdin) is
getting the code in utf8 format. Now the problem is that the _wfopen_s
is returning a code 22 (Invalid argument).

The code that I'm using:

int RecFile::openFile(const wchar_t *fileName)
{
errno_t err = _wfopen_s(&recFile, fileName, L"wb");
...

If I understood correctly, the wchar_t stores the string in utf8 format, is it?

Thanks in advance,
Paulo Flabiano Smorigo

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Here are the mingw compile experience notes

2009-12-17T14:55:05Z

>> But I thought what you wanted to do was to build a GTK+ *application*
>> (a gtkmm one), not GTK+ itself?
> These links have the words cygwin inside them, but they seem to discuss
> mingw and no cygwin at all:
> http://kemovitra.blogspot.com/2009/06/setting-up-cygwin-for-software.html
> http://kemovitra.blogspot.com/2009/06/cygwin-tutorial-compiling-gtk-2162-for.html

Hmm. There doesn't seem to be much actual communication of the
old-fashioned "reply with something related to the question" sort
going on here. I give up.

--tml

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Here are the mingw compile experience notes

2009-12-17T14:46:59Z

uticdmarceau2007@... wrote:
> Tor Lillqvist wrote:
> These links have the words cygwin inside them, but they seem to discuss
> mingw and no cygwin at all:
> http://kemovitra.blogspot.com/2009/06/setting-up-cygwin-for-software.html
> http://kemovitra.blogspot.com/2009/06/cygwin-tutorial-compiling-gtk-2162-for.html
Oops I made a mistake with the two links. Here are the correct ones:
http://kemovitra.blogspot.com/2008/01/installing-mingw-on-windows.html
http://kemovitra.blogspot.com/2009/06/compiling-gtk-2-for-windows.html

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

GDBM and cross-compiling on Gentoo with crossdev/Portage

2009-12-17T13:56:41Z

I try to maintain this Wiki page for Gentoo:
http://en.gentoo-wiki.com/wiki/Mingw . Relevant section is
http://en.gentoo-wiki.com/wiki/Mingw#Using_Portage . This is definitely the best
way to do package management on Gentoo even for this ROOT.

I do strongly want to keep some USE flags that I use (some would not be used for
Mingw such as ALSA) basically dependencies to link with automatically, such as
zlib. The SDL example method is not the way I want to be getting my packages but
I have had to resort to it because Portage often wants to do the following
things even with i686-pc-mingw32 CHOST:

- Link to X, ALSA, or anything else that is truly Linux/non-Windows only
- Build and link to GDBM

I have Googled a bit but I think the main problem right now is that the ebuild
for GDBM does not handle for when the CHOST is i*86-pc-mingw32. I have heard
about this building successfully and tried to find relevant patches. The log of
the build for GDBM:

i686-pc-mingw32-gcc -c -I. -I. -march=k8 -msse3 -O2 -pipe gdbmfetch.c
-DDLL_EXPORT -DPIC -o .libs/gdbmfetch.lo

gdbmopen.c: In function 'gdbm_open':

gdbmopen.c:171: error: storage size of 'flock' isn't known

gdbmopen.c:171: error: 'F_RDLCK' undeclared (first use in this function)

gdbmopen.c:171: error: (Each undeclared identifier is reported only once

gdbmopen.c:171: error: for each function it appears in.)

gdbmopen.c:171: error: 'F_SETLK' undeclared (first use in this function)

gdbmopen.c:177: error: storage size of 'flock' isn't known

gdbmopen.c:177: error: 'F_WRLCK' undeclared (first use in this function)

An overlay could easily be maintained for building a nice Mingw32 root to build
packages from. Right now I cannot build my whole example application; Portage
thinks a LOT of stuff is missing because it assumes this is just another chroot.

For example, if I try to emerge just audacity (which of course can build for
Windows):

CBUILD=x86_64-pc-linux-gnu ROOT=/usr/i686-pc-mingw32 CHOST=i686-pc-mingw32
emerge -pv libsdl

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] sys-libs/gdbm-1.8.3-r3 to /usr/i686-pc-mingw32/ USE="-berkdb" 0 kB
[ebuild N ] app-misc/mime-types-8 to /usr/i686-pc-mingw32/ 12 kB
[ebuild N ] app-misc/pax-utils-0.1.19 to /usr/i686-pc-mingw32/ USE="-caps" 76 kB
[ebuild N ] dev-libs/libffi-3.0.8 to /usr/i686-pc-mingw32/ USE="-debug
-static-libs -test" 706 kB
[ebuild N ] dev-libs/libpthread-stubs-0.1 to /usr/i686-pc-mingw32/
USE="-debug" 190 kB
[ebuild N ] sys-apps/sandbox-1.6-r2 to /usr/i686-pc-mingw32/ 300 kB

[ebuild N ] sys-apps/attr-2.4.43 to /usr/i686-pc-mingw32/ USE="nls" 115 kB

[ebuild N ] dev-libs/popt-1.15 to /usr/i686-pc-mingw32/ USE="nls" 0 kB

[ebuild N ] dev-lang/tcl-8.5.7 to /usr/i686-pc-mingw32/ USE="-debug
-threads" 4,319 kB
[ebuild N ] sys-libs/gpm-1.20.5 to /usr/i686-pc-mingw32/ USE="(-selinux)"
1,269 kB
[ebuild N ] x11-libs/libXdmcp-1.0.3 to /usr/i686-pc-mingw32/ USE="-debug" 0
kB
[ebuild N ] x11-libs/libICE-1.0.6 to /usr/i686-pc-mingw32/ USE="-debug
-ipv6" 0 kB
[ebuild N ] x11-proto/inputproto-1.5.1 to /usr/i686-pc-mingw32/ 61 kB

[ebuild N ] media-libs/audiofile-0.2.6-r4 to /usr/i686-pc-mingw32/ 371 kB

[ebuild N ] x11-proto/damageproto-1.2.0 to /usr/i686-pc-mingw32/ 52 kB

[ebuild N ] x11-proto/fixesproto-4.0 to /usr/i686-pc-mingw32/ 38 kB

[ebuild N ] x11-proto/printproto-1.0.4 to /usr/i686-pc-mingw32/ 49 kB

[ebuild N ] x11-proto/randrproto-1.3.1 to /usr/i686-pc-mingw32/ 0 kB

[ebuild N ] x11-proto/renderproto-0.11 to /usr/i686-pc-mingw32/ 0 kB

[ebuild N ] sys-libs/ncurses-5.6-r2 to /usr/i686-pc-mingw32/ USE="gpm
unicode -debug -doc -minimal -nocxx -profile -trace" 2,353 kB

[ebuild N ] sys-apps/acl-2.2.47 to /usr/i686-pc-mingw32/ USE="nls (-nfs)"
152 kB
[ebuild N ] virtual/libffi-0 to /usr/i686-pc-mingw32/ 0 kB

[ebuild N ] x11-libs/libxcb-1.4-r1 to /usr/i686-pc-mingw32/ USE="-debug -doc
(-selinux)" 299 kB
[ebuild N ] x11-libs/libdrm-2.4.15 to /usr/i686-pc-mingw32/ USE="-debug" 0
kB
[ebuild N ] x11-proto/xextproto-7.0.5 to /usr/i686-pc-mingw32/ 79 kB

[ebuild N ] x11-libs/libX11-1.2.2 to /usr/i686-pc-mingw32/ USE="xcb -debug
-ipv6" 1,833 kB
[ebuild N ] sys-libs/readline-6.0_p3 to /usr/i686-pc-mingw32/ 2,224 kB

[ebuild N ] virtual/acl-0 to /usr/i686-pc-mingw32/ 0 kB

[ebuild N ] app-shells/bash-4.0_p35 to /usr/i686-pc-mingw32/ USE="net nls
-afs -bashlogger -examples -mem-scramble -plugins -vanilla" 0 kB

[ebuild N ] sys-apps/sed-4.2 to /usr/i686-pc-mingw32/ USE="acl nls -static"
862 kB
[ebuild N ] dev-lang/tk-8.5.7 to /usr/i686-pc-mingw32/ USE="truetype -debug
-threads" 3,692 kB
[ebuild N ] dev-db/sqlite-3.6.21 to /usr/i686-pc-mingw32/ USE="doc readline
threadsafe -debug -fts3 -icu -soundex -tcl" 0 kB
[ebuild N ] net-misc/rsync-3.0.6 to /usr/i686-pc-mingw32/ USE="acl iconv
-ipv6 -static -xattr" 761 kB
[ebuild N ] x11-libs/libXext-1.0.5 to /usr/i686-pc-mingw32/ USE="-debug" 265
kB
[ebuild N ] x11-libs/libXfixes-4.0.4 to /usr/i686-pc-mingw32/ USE="-debug" 0
kB
[ebuild N ] x11-libs/libXrender-0.9.5 to /usr/i686-pc-mingw32/ USE="-debug"
0 kB
[ebuild N ] x11-libs/libXrandr-1.3.0 to /usr/i686-pc-mingw32/ USE="-debug"
257 kB
[ebuild N ] x11-libs/libXxf86vm-1.0.2 to /usr/i686-pc-mingw32/ USE="-debug"
235 kB
[ebuild N ] x11-libs/libXi-1.2.1 to /usr/i686-pc-mingw32/ USE="-debug" 274
kB
[ebuild N ] x11-libs/libXdamage-1.1.2 to /usr/i686-pc-mingw32/ USE="-debug"
0 kB
[ebuild N ] x11-libs/libXp-1.0.0 to /usr/i686-pc-mingw32/ USE="-debug" 239
kB
[ebuild N ] dev-libs/openssl-0.9.8l-r2 to /usr/i686-pc-mingw32/ USE="(sse2)
zlib -bindist -gmp -kerberos -test" 4,082 kB
[ebuild N ] sys-apps/debianutils-3.1.3 to /usr/i686-pc-mingw32/
USE="-static" 130 kB
[ebuild N ] app-admin/python-updater-0.7 to /usr/i686-pc-mingw32/ 7 kB

[ebuild N ] sys-devel/gettext-0.17 to /usr/i686-pc-mingw32/ USE="acl nls
openmp -doc -emacs -nocxx" 11,369 kB
[ebuild N ] app-admin/eselect-python-20090824 to /usr/i686-pc-mingw32/ 5 kB

[ebuild N ] dev-lang/python-2.6.4 to /usr/i686-pc-mingw32/ USE="doc examples
gdbm ncurses readline sqlite ssl threads tk (wide-unicode) xml -berkdb -build
-ipv6 -wininst" 0 kB

[ebuild N ] sys-apps/portage-2.1.6.13 to /usr/i686-pc-mingw32/ USE="-build
-doc -epydoc (-selinux)" LINGUAS="-pl" 680 kB
[ebuild N ] dev-python/python-docs-2.6.4 to /usr/i686-pc-mingw32/ 3,772 kB
[ebuild N ] sys-apps/coreutils-7.5-r1 to /usr/i686-pc-mingw32/ USE="acl nls
-caps -gmp (-selinux) -static -vanilla -xattr" 9,731 kB
[ebuild N ] sys-apps/file-5.03 to /usr/i686-pc-mingw32/ USE="python" 602 kB
[ebuild N ] app-admin/eselect-1.2.8 to /usr/i686-pc-mingw32/
USE="bash-completion -doc" 151 kB
[ebuild N ] dev-libs/libxml2-2.7.3-r2 to /usr/i686-pc-mingw32/ USE="doc
examples python readline -debug -ipv6 -test" 4,678 kB
[ebuild N ] app-misc/ca-certificates-20090709 to /usr/i686-pc-mingw32/ 151 kB
[ebuild N ] media-libs/alsa-lib-1.0.20-r1 to /usr/i686-pc-mingw32/
USE="python -alisp -debug -doc" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix
dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter
mmap_emul mulaw multi null plug rate route share shm softvol" 777 kB
[ebuild N ] app-admin/eselect-opengl-1.1.1-r2 to /usr/i686-pc-mingw32/ 58 kB
[ebuild N ] sys-devel/libperl-5.8.8-r2 to /usr/i686-pc-mingw32/ USE="gdbm
-berkdb -debug -ithreads" 9,887 kB
[ebuild N ] dev-lang/perl-5.8.8-r8 to /usr/i686-pc-mingw32/ USE="gdbm
-berkdb -build -debug -doc -ithreads -perlsuid" 0 kB
[ebuild N ] app-admin/perl-cleaner-1.05 to /usr/i686-pc-mingw32/ 6 kB
[ebuild N ] sys-apps/util-linux-2.16.1 to /usr/i686-pc-mingw32/ USE="crypt
loop-aes nls perl unicode -old-linux (-selinux) -slang (-uclibc)" 0 kB
[ebuild N ] x11-libs/libSM-1.1.1 to /usr/i686-pc-mingw32/ USE="uuid -debug
-ipv6" 257 kB
[ebuild N ] x11-libs/libXt-1.0.7-r1 to /usr/i686-pc-mingw32/ USE="-debug" 0 kB
[ebuild N ] x11-libs/libXmu-1.0.5 to /usr/i686-pc-mingw32/ USE="-debug
-ipv6" 0 kB
[ebuild N ] x11-libs/openmotif-2.3.2 to /usr/i686-pc-mingw32/ USE="jpeg png
unicode -doc -examples -xft" 5,803 kB
[ebuild N ] media-libs/mesa-7.5.2 to /usr/i686-pc-mingw32/ USE="motif nptl
pic -debug -xcb" VIDEO_CARDS="-intel -mach64 -mga -none -r128 -radeon -radeonhd
-s3virge -savage -sis (-sunffb) -tdfx -trident -via" 0 kB
[ebuild N ] virtual/glu-7.0 to /usr/i686-pc-mingw32/ 0 kB
[ebuild N ] virtual/opengl-7.0 to /usr/i686-pc-mingw32/ 0 kB
[ebuild N ] media-libs/glew-1.5.1 to /usr/i686-pc-mingw32/ 386 kB
[ebuild R ] media-libs/libsdl-1.2.13-r1 to /usr/i686-pc-mingw32/ USE="X*
alsa* audio* joystick* opengl* video* xinerama* xv* -aalib -custom-cflags -dga
-directfb -esd -fbcon -ggi -libcaca -nas -oss -pulseaudio (-svga) -tslib%
(-arts%)" 3,295 kB

Problems: GDBM will fail of course. libpthread-stubs (or regular pthread in
general) is not for Windows; sandbox is strictly for Portage; X deps; Bash, and
a whole lot more problems.

Is there a work around for all this? My only slight solution is USE="-*" but it
does not work for everything nor does everything out of the tree successfully build.

Thanks for any help

--
Tatsh
www.tatsh.net
ddrtist@...

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Here are the mingw compile experience notes

2009-12-17T12:25:52Z

Tor Lillqvist wrote:
> But I thought what you wanted to do was to build a GTK+ *application*
> (a gtkmm one), not GTK+ itself?
These links have the words cygwin inside them, but they seem to discuss
mingw and no cygwin at all:
http://kemovitra.blogspot.com/2009/06/setting-up-cygwin-for-software.html
http://kemovitra.blogspot.com/2009/06/cygwin-tutorial-compiling-gtk-2162-for.html

I followed above and here are my observations:
1)needed to download and compile the unzip sources and adjust the
2)cflags in makefile.gcc and in my
3)/home/user/.profile
to have the following flags:
-march pentium3 -mtune i586
4)zlib needs to be compiled before glib
5)bug in the glib configure:
checking mswsock.h usability... no
checking mswsock.h presence... yes
configure: WARNING: mswsock.h: present but cannot be compiled
configure: WARNING: mswsock.h: check for missing prerequisite headers?
configure: WARNING: mswsock.h: see the Autoconf documentation
configure: WARNING: mswsock.h: section "Present But Cannot Be Compiled"
configure: WARNING: mswsock.h: proceeding with the preprocessor's result
configure: WARNING: mswsock.h: in the future, the compiler will take
precedence
configure: WARNING: ##
-----------------------------------------------------
-------------- ##
configure: WARNING: ## Report this to
http://bugzilla.gnome.org/enter_bug.cg
i?product=glib ##
configure: WARNING: ##
-----------------------------------------------------
-------------- ##
checking for mswsock.h... yes
6)make/make install for glib succeeded.
7)libpng done
8)libjpeg-7 done
9)libtiff cd port;make;cd ../libtiff;make done
10)libfreetype done
11)libexpat done
12)libxml done
13)libfontconfig done
14)libatk done
15)libpixman done
16)libcairo
giving me issues with the configure/Makefile. I know that libpng-config
exists, but I don't know how to connect it to the configure script.
I changed the respective libpng cflags and libs in the Makefile along
with adding -lpng14 to the cairo libs in the Makefile to get it to
compile successfully.
done
16.2)libpango done
16.3)gtk+2
changed the configure script to use png instead of png12
done
17)libcairomm
/mingw/lib/pkg-config/cairo.pc changed libpng12 to libpng
it wants libsig++

I installed the gtkmm.exe package you told me in your previous email:
export PKG_CONFIG_PATH=/c/gtkmm/lib/pkgconfig:/c/mingw/lib/pkgconfig
export LD_LIBRARY_PATH=/c/gtkmm/redist:/c/gtkmm/bin
export PATH=/c/gtkmm/bin:/c/gtkmm/redist:$PATH
gcc -Wall -o anomos.exe `pkg-config --cflags gtkmm-2.4 pangomm-1.4`
anomos.cc `pkg-config --libs gtkmm-2.4 pangomm-1.4` -lstdc++

I ran anomos.exe with no hitches, twice in a row with no exceptions raised.

BTW I tried to compile cadaver sources using mingw and was missing some
stuff about glob/regex/signals. Is there a repository of mingw compiled
gnu tools like wget and cadaver around? Cygwin has these. I needed to
use cygwing cadaver to move these notes over from the windows laptop to
the linux box. I prefer not to use nfs/samba/ftp. cadaver knows https
out-of-the-box.

Cheers,
David Marceau

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-17T06:29:06Z

> I have an application that has two modules that communicates by stdin and stdout.

Please note that "module" can mean more or less anything... You mean
two programs, one writing to the other through a pipe? You mean they
are started from a shell with an explicit pipe created by the shell
between them, like "prog1 | prog2 "?

Passing the filename through a pipe should not affect it, the same
bytes that were written to the pipe will be read from the pipe. The
only "mangling" that might happen is related to line endings, i.e. LF
turning into CRLF when writing and/or vice versa when reading.
Reliable code should be prepared for either just LF or CRLF line
endings and handle both.

Where does the file name come from initially? From user input in a
console window? Such input indeed (as far as I know) is in the
"console" codepage which often is the so-called "OEM" codepage, so it
might need to be converted to the "system" ("ANSI") codepage before
passed to fopen().

(Yeah, this codepage stuff is pure crack. Ideally, one should use
libraries (GLib, Qt, ...) or programming environments (C#, Java, ...)
that hopefully hide all that crap and offer a Unicode-based
environment. Although come to think of it, I don't think GLib actually
offers any Windows-specific functionality to read from the console
that would turn console codepage input into Unicode. Sorry.)

But if the file name comes from some C library or Win32 API (like
readdir() or FindNextFile() etc) then it should already be in the
system codepage and should be fine to pass to fopen().

If the filename is hardcoded in your source code (as in your initial
example), you just need to figure out yourself what codeset the source
code is in;) It depends on your editor etc. Is it UTF-8 for instance?
Passing UTF-8 file names to fopen() would not work.

> When I try to send the command with bt stdout the "core" gets a string with
> strange chars in it...

What do you mean with "bt stdout" ?

--tml

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-17T06:18:02Z

Op 12/17/2009 02:33 PM, Paulo Flabiano Smorigo schreef:

> Hi Erwin, JonY and Tor,
>
> I have an application that has two modules that communicates by stdin
> and stdout. It's an interface that sends commands to the "core". In
> this communication, there is a command to save a file that could be in
> a path with special characters, like the example.
>
> When I try to send the command with bt stdout the "core" gets a string
> with strange chars in it...
>
> I'm trying to solve by implementing the suggestions from the
> previously messages.
>

Don't forget to set the font of the console to "true type lucida
console" to make the 8bit characters appear correctly.

Erwin

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-17T05:33:41Z

Hi Erwin, JonY and Tor,

I have an application that has two modules that communicates by stdin and stdout. It's an interface that sends commands to the "core". In this communication, there is a command to save a file that could be in a path with special characters, like the example.

When I try to send the command with bt stdout the "core" gets a string with strange chars in it...

I'm trying to solve by implementing the suggestions from the previously messages.

Again, thanks for the support!
Paulo Flabiano Smorigo

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-17T05:30:58Z

For Windows,

fopen, _wfopen

http://msdn.microsoft.com/en-us/library/yeby3zcb(VS.80).aspx

fopen_s, _wfopen_s

http://msdn.microsoft.com/en-us/library/z5hh6ee9(VS.80).aspx

______________________________________________________________________

Kizza George Mbidde

Interconnect Billing Systems Analyst

cell: +256 77 212 0982

email: mbiddeg@...

From: Paulo Flabiano Smorigo [mailto:pfsmorigo@...]
Sent: December 17, 2009 15:42
To: MinGW Users List
Subject: [Mingw-users] Problems with charset on Windows

Re: Problems with charset on Windows

2009-12-17T05:20:57Z

> if ((file = fopen("f:/ação/file.txt", "w")))

> But on Windows, the charset appears to be wrong,,, I printed the string in
> the screen and saw strange characters...

You printed what string? Did the fopen succeed, and it's the contents
of the file which looks strange if printed to stdout (the console
window)? Or did the fopen fail (and it's the file name that looks
strange if printed to the console window)?

--tml

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-17T05:05:05Z

On 12/17/2009 20:42, Paulo Flabiano Smorigo wrote:

> Hi everyone,
>
> I trying to compile on linux an application for windows that has to open a
> file inside a directory with special characters. My code is:
>
> #include<stdio.h>
> #include<windows.h>
>
> int main(int argc, char* argv[])
> {
> FILE *file;
> if ((file = fopen("f:/ação/file.txt", "w")))
> printf("worked!\n");
> else
> printf("not worked!\n");
> return 0;
> }
>
> But on Windows, the charset appears to be wrong,,, I printed the string in
> the screen and saw strange characters...
>

Hi,

have you tried _wfopen?

_wfopen(L"f:/ação/file.txt", L"w");

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Re: Problems with charset on Windows

2009-12-17T05:05:00Z

Op 12/17/2009 01:42 PM, Paulo Flabiano Smorigo schreef:

> Hi everyone,
>
> I trying to compile on linux an application for windows that has to
> open a file inside a directory with special characters. My code is:
>
> #include <stdio.h>
> #include <windows.h>
>
> int main(int argc, char* argv[])
> {
> FILE *file;
> if ((file = fopen("f:/ação/file.txt", "w")))
> printf("worked!\n");
> else
> printf("not worked!\n");
> return 0;
> }
>
> But on Windows, the charset appears to be wrong,,, I printed the
> string in the screen and saw strange characters...
>

The default code page in a command prompt is a DOS code page.
Make the code page in the console equal to the system code page. For
instance:
chcp 1252

I have the same issue in my program. See also:
http://www.xs4all.nl/~waterlan/wcdbeta/wcd.html#windows_code_pages

Erwin

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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

Problems with charset on Windows

2009-12-17T04:42:14Z

Hi everyone,

I trying to compile on linux an application for windows that has to open a file inside a directory with special characters. My code is:

#include <stdio.h>
#include <windows.h>

int main(int argc, char* argv[])
{
    FILE *file;
    if ((file = fopen("f:/ação/file.txt", "w")))
        printf("worked!\n");
    else
        printf("not worked!\n");
    return 0;
}

But on Windows, the charset appears to be wrong,,, I printed the string in the screen and saw strange characters...

Thanks in advance!
Paulo Flabiano Smorigo

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
MinGW-users mailing list
MinGW-users@...

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