MySQL Bugs: #36281: Visual C++ 2005 cannot compile sql

Bug #36281	Visual C++ 2005 cannot compile sql_locale.cc
Submitted:	23 Apr 2008 9:46	Modified:	24 Apr 2018 11:40
Reporter:	Meiji KIMURA	Email Updates:
Status:	Unsupported	Impact on me:	None
Category:	MySQL Server: Compiling	Severity:	S3 (Non-critical)
Version:	5.0.58	OS:	Windows
Assigned to:		CPU Architecture:	Any

Description:
I encountered the following problem when building with source code on Windows. I think that it is caused by changing of Visual C++'s behavior. Visual C++ 2003 can handle with UTF8 without BOM(Byte Order Mark), but Visual C++ 2005 and 2008 cannot hadle with UTF8 without BOM correctly.

Versions:
- MySQL 5.0.58 (Enterprise GPL), MySQL 5.0.54a (Enterprise GPL), MySQL 5.0.54a (OEM/Commercial)
- Windows XP Pro (Japanese), Windows 2003 Server R2 (Japanese), Windows 2003 Server R2 （Winx64) (Japanese)
- Visual C++ Express Edition with Windows SDK (Japanese), Visual Studio 2005 Professional Edition (English), Visual Studio 2005 Team Edition (Japanese)

Problem1: Compiling sql/sql_locale.cc
Compiling causes error because of strings like Arabic character which are included in sql_locale.cc

1>------ Start building: Project: mysqld, configuration: Release Win32 ------
1>Compiling...
1>sql_locale.cc
1>.\sql_locale.cc : warning C4819:
The file contains a character that cannot be represented in the current code page (932), save it as an Unicode file to avoid a data loss.
1>.\sql_locale.cc(28) : error C2146: syntax error : missing '}' before identifier 'ﾙ・ｧﾙ館・'
1>.\sql_locale.cc(28) : error C2146: syntax error : missing ';' before identifier 'ﾙ・ｧﾙ館・'

How to repeat:
Steps: Unzip mysql-5.0.58.tar.gz, and execute the following

win\configure.js WITH_HEAP_STORAGE_ENGINE WITH_MYISAM_STORAGE_ENGINE
WITH_MYISAMMRG_STORAGE_ENGINE WITH_ARCHIVE_STORAGE_ENGINE WITH_BLACKHOLE_STORAGE_ENGINE
WITH_EXAMPLE_STORAGE_ENGINE
WITH_FEDERATED_STORAGE_ENGINE WITH_INNOBASE_STORAGE_ENGINE
MYSQLD_EXE_SUFFIX="-nt" __NT__ 

win\build-vs8.bat

Double click on MySql.sln and launch Visual Studio (C++) . And then specify "Release" on solution configuration and build it. Then the errors are displayed.

Suggested fix:
On Visual Studio, character code is recognized as "Unicode (UTF-8 no siguniture(BOM)) - code page 65001".
When the file is saved with "Unicode (UTF-8 siguniture(BOM)) - code page 65001" and then it can be compiled.

However lots of errors are shown below during compiling, but it completed.
1>.\sql_locale.cc(1652) : warning C4566: character represented by universal-character-name '\u0309' cannot be represented in the current code page (932)
1>.\sql_locale.cc(1652) : warning C4566: character represented by universal-character-name '\u00E2' cannot be represented in the current code page (932)
1>.\sql_locale.cc(1652) : warning C4566: character represented by universal-character-name '\u0323' cannot be represented in the current code page (932)

Meiji,
UTF8 BOM is no good on Unix..I belive adding

#ifdef _MSC_VER
#pragma setlocale "C"
#endif

somewhere at the start of file might help, but I'm not 100% sure about it (have neither Japanese VS nor OS).

Can you verify?

The code fragment in pervious entry should be rather written as

#ifdef _MSC_VER
#pragma setlocale("C")
#endif

I added '#pragma setlocale("C")' immediate before '#include "mysql_priv.h"' of sql_locale.cc, But the situation is not changed. The same errors occurs.

Have you tried the VS2005 SP1 yet, or the corresponding compiler from Vista  Platform SDK?

The knowlegde base article for SP1 (http://support.microsoft.com/kb/918526) states
"FIX: Error message when you use Visual Studio 2005 to compile C++ source code: "Warning C4819: The file contains a character that cannot be represented in the current code page"

I would expect this error to be fixed with the compiler update.

I've already apply SP1 to my Visual C++ 2005. The situation does not change.
(Visual C++ 2008 Express edition's behavior is the same.)

But I found a workaround this situation. If I set OS's language set to 'English_United States.1252', these errors not occur.

I try to find the method not OS but compiler or source code.
But I cannot find parameter of compiler. I found the method to specify on source code like this,

#pragma locale("English_United States.1252")

But this does not change the error situation.

As a result, we have to OS language & codeset in Japanese OS environment.

I submitted a bug for Microsoft compiler here
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=341454

I met the problem at first, and I have made the build successfully. My OS is WinXP SP2 CN, and I think this issue would only be in non-English Windows system.

Open the file sql\sql_locale.cc in vs(mine is VS 2005), then 'File->Advanced save options', put the codeset to 'UTF-8', save the file in the editor by right click on the file name. After this, build can be successful. :-)

Guofeng Zhang just gave feedback on this bug:

> The Language for non-Unicode programs on the computer must be set to
> English (United States), or the re-saved file still cannot be accepted
> by VS 2005.

before open sql_locale.cc in VS 2005, the Language for non-Unicode programs (on the Advanced tab of Regional and Language Options applet) on the computer must be set to English (United States), or the re-saved file still cannot be accepted by VS 2005.

um..........anyone solves it???

Is this still relevant? 5.0 is EOL, we use VS 2005 on 5.1 and VS 2008 for 5.5+.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

This problem is reproduced latest environment.

o VS 2010 Pro
o Vista Business (32-bit) Japanese version
o MySQL 5.5.x

[Workaround]
You can change OS System local from japanese to western (e.g. latin1), then avoid this problem and compile them completely.

Meiji, please comment on bug#11748435 going forward. I have set the internal bug to state 11.

Posted by developer:
 
EOL OS and almost EOL MySQL version. Thus closing this. If this is still observable on recent MySQL versions and environments, please reopen.