I have used older projects with Greek characters in ANSI and code pages without problems.
Indeed unicode will solve the problem, but this specific project is too big and I have to make too many changes to finally make it work fine.
Anyway, I managed to fix the problem changing the title of the title dynamically inside the code.
Take in mind that when I recall strings from the Resource String Table using CString.LoadString(ID) I get gibberish but when I am using CStringW.LoadString(ID) it works. My String Table is not Unicode but inside VS2008 I set it up as Greek code page.
Two possible problems
1. In the project settings, make sure the character set is set to unicode for both debug and release
2. if you use third party libraries (other than MFC), make sure they also use unicode for both Debug and Release.
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
I can't see it either. It seems you've got two options, either use format_sed, if you know that you wont have \1 in the replacement string, or you'll have to turn any single $ into $$ before passing in to regex_replace There really should be a format_no_format flag to turn off format replacements.
Be aware that sed_format uses "\0" to replace matches. In your case if the user input was "A2347\01GBFC", you'd get the same output as for "A2347X$01GBFC" with format_default. If that's not an issue, then you're good to go.
I have now build both project and its library using ARM architecture.
The library compiles and links - no error.
The library contains one test C++ class with only constructor / destructor implemented.
This is important to note - see the NOTEs at the end of the post.
The main program compiles but fails to link with errors indicating problem with "gcov".
The attached partial crosscompiler make output of library build indicates addition of "gcov" related options.
They have been put there as standard IDE options for building library.
I did NOT added these options.
make -j4 all
Building file: ../MODULE/M_ARM_TEST/CARMTEST.cpp
Invoking: Cross G++ Compiler
arm-linux-gnueabihf-g++ -O0 -g3 -p -pg -ftest-coverage -fprofile-arcs -Wall -c -fmessage-length=0 -v -MMD -MP -MF"MODULE/M_ARM_TEST/CARMTEST.d" -MT"MODULE/M_ARM_TEST/CARMTEST.o" -o "MODULE/M_ARM_TEST/CARMTEST.o" "../MODULE/M_ARM_TEST/CARMTEST.cpp"
Using built-in specs.
The attached partial output of main program posts the "gcov" errors.
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/libRPI_BT_LIB_ARM.a(CARMTEST.o): In function `_GLOBAL__sub_I_65535_0__ZNSt10C_ARM_TESTC2Ev':
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/../MODULE/M_ARM_TEST/CARMTEST.cpp:42: undefined reference to `__gcov_init'
/media/z/DEV_COPY_LABEL/ECLIPSE_FOLDER/2019-12/Eclipse_2019_12/eclipse/Workspace_2019_12/RPI_BT_LIB_ARM/Debug/libRPI_BT_LIB_ARM.a(CARMTEST.o):(.data+0x28): undefined reference to `__gcov_merge_add'
collect2: error: ld returned 1 exit status
NOTE The library source code line #42 is where error is actually indicated in output , at the closing bracket of "std" namespace comment
NOTE 42 } /* namespace std */
1. What is the purpose of having -ftest-coverage -fprofile-arcs option SPECIFICALLY for library? I do not have them in any other IDE build programs.
I did not try to delete them, perhaps after I have some more knowledge about their purpose.
2. I did try to add -lgcov to program linker but it did not work.
I understand that gcov is some kind of utility tracking application and not sure why I need it.
It is not clear where that reference is coming from, but most likely in one of the header files if you did not make a specific call to it. Or did you call to some other library which in turn requires gcov? Take a look at __gcov_init - Google Search[^] for some similar issues.
I got sidetracked by another issue, and this one was "FIXED" - see my next post.
From my research - it is optioned / initialized in the library I have build and I really do not understand what it supposedly doing with just the options being set. It is definitely incomplete.
I did try to delete the options, but it is "built-in".
The error is little confusing - skipping and cannot find it - both ?
Not really. The linker found a copy of the lib, but it has the wrong architechture, so it skipped over that one, but then did not find a suitable candidate. If you had x86, x86-64, PowerPC and MIPS versions of that lib, I expect you would get skipped messages for each.
I notice you're calling /usr/bin/ld. If you are cross compiling for an rpi, should that be calling /usr/bin/arm-linux-guneeabihf-ld? I think maybe you've misconfigured your project to produce X86 output, and not ARM.
Last Visit: 31-Dec-99 18:00 Last Update: 27-Jul-21 12:19