[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    wine/windows/tchar.h - error "You must use msvcrt when building in Unicode/MBCS mode"
From:       Ilya Konstantinov <future () shiny ! co ! il>
Date:       2012-07-30 23:56:34
Message-ID: CA+dzQZ1xAbxB4uUyAtD8EUirTT2TbdV4tCeEtJ3-ncrEtPei+Q () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


In 2004, somebody has asked a question:
http://www.winehq.org/pipermail/wine-devel/2004-October/030349.html

The reply from Alexandre was:

> > Either there should be a overriding "wine/include/msvcrt/tchar.h"
> > file with different defintions. Or the error message "You must use
> > msvcrt when building in Unicode/MBCS mode" is simply superfluous.
> It's not superfluous, but it probably needs a !defined(__MSVCRT__) in
> there.


From what I see, today the situation is still the same.
Is it simply because nobody has dealt with it?

In any case, I've implemented Alexandre's change locally (in tchar.h).

Now I'll be trying to use winelib's msvcrt with my code. It seems like a
"damned if you do,
damned if you don't" kind of thing. One issue I'm having now is wine/msvcrt
being in the
system includes path, thus causing libstdc++ to load winelib's <wchar.h>.
Of course,
this didn't go too well :-)

My goal is to have a Linux app that's, generally speaking, a native app. I
have the cooperation
of the codebase developers, so they can follow directions to keep the code
reasonably portable.
At the same time, I don't want to burden them with mundane changes, so if
Winelib can bridge
over the two worlds sometimes, it'd be great.

Perhaps we can have tchar.h operate in two modes:
1) a MSVCRT mode, where all the MSVCRT goodies are available,
2) a glibc mode, where it tries to map as many functions to glibc as
possible?

[Attachment #5 (text/html)]

<div dir="ltr"><div>In 2004, somebody has asked a question:</div><div><a \
href="http://www.winehq.org/pipermail/wine-devel/2004-October/030349.html" \
target="_blank">http://www.winehq.org/pipermail/wine-devel/2004-October/030349.html</a>
 </div><div><br></div><div>The reply from Alexandre was:</div><div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px \
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">



&gt; Either there should be a overriding \
&quot;wine/include/msvcrt/tchar.h&quot;<br>&gt; file with different defintions. Or \
the error message &quot;You must use<br>&gt; msvcrt when building in Unicode/MBCS \
mode&quot; is simply superfluous.<br>


It&#39;s not superfluous, but it probably needs a !defined(__MSVCRT__) \
in<br>there.</blockquote></div><div><br></div><div>From what I see, today the \
situation is still the same.</div><div>Is it simply because nobody has dealt with \
it?</div>


<div><br></div><div>In any case, I&#39;ve implemented Alexandre&#39;s change locally \
(in tchar.h).</div><div><br></div><div>Now I&#39;ll be trying to use winelib&#39;s \
msvcrt with my code. It seems like a &quot;damned if you do,</div>

<div>damned if you don&#39;t&quot; kind of thing. One issue I&#39;m having now is \
wine/msvcrt being in the</div><div>system includes path, thus causing libstdc++ to \
load winelib&#39;s &lt;wchar.h&gt;. Of course,</div><div>

this didn&#39;t go too well :-)</div><div><br></div><div>My goal is to have a Linux \
app that&#39;s, generally speaking, a native app. I have the cooperation</div><div>of \
the codebase developers, so they can follow directions to keep the code reasonably \
portable.</div>

<div>At the same time, I don&#39;t want to burden them with mundane changes, so if \
Winelib can bridge</div><div>over the two worlds sometimes, it&#39;d be \
great.</div><div><br></div><div>Perhaps we can have tchar.h operate in two \
modes:</div>

<div>1) a MSVCRT mode, where all the MSVCRT goodies are available,</div><div>2) a \
glibc mode, where it tries to map as many functions to glibc as possible?</div></div>





[prev in list] [next in list] [prev in thread] [next in thread]