I got a project from MS VS, and at the moment I'm migrating it to compile using gcc for Windows.
The C code is completely ported, but I'm having a problem using windres to compile the projet resources.
I'm having a syntax error, reported by windres, at those single lines:
CONTROL "Tab1",IDC_FILETAB,"SysTabControl32",TCS_BOTTOM,0,1,336,194
CONTROL "Tab1",IDC_KEYS,"SysTabControl32",TCS_BOTTOM,27,111,73,6
All others use of Control, with similar syntax, works as expected...
According with http://cygwin.com/cygwin-ug-net/windres.html , the follow syntax is used for CONTROL:
CONTROL ["name",] id, class, style, x,y,w,h [,exstyle] [data]
CONTROL ["name",] id, class, style, x,y,w,h, exstyle, helpid [data]
At top of resource.rc I'm including afxres.h,winuser.h and windows.h .
Can any one give me a help? I don't have a clue about what to do....
BTW, if I comment those lines, all ends with no errors, but the executable cannot works properly.
Thanks
Edit: After more search on the internet.. I found that windres already had many problems with syntax accepted on windows resource compiler, mainly because some classes aren't visible for windres. So if any one know an alternative classes/id, or where it are defined to include, I can workaround it.
You might have copied the code happens all the time just open the code in a textviewer and change the format to plain text or edit and replace characters like " , ' etc.
Related
See below for the following code, and below that, the error that follows.
std::string source = "C:\\Users\\cambarchian\\Documents\\tested";
std::string destination = "C:\\Users\\cambarchian\\Documents\\tester";
std::filesystem::path sourcepath = source;
std::filesystem::path destpath = destination;
std::filesystem::copy_options::update_existing;
std::filesystem::copy(sourcepath, destpath);
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot copy: File exists [C:\Users\cambarchian\Documents\tested] [C:\Users\cambarchian\Documents\tester]
Tried to use filesystem::copy, along with trying different paths. No luck with anything. Not too much I can write here as the problem is listed above, could be a simple formatting issue. That being said, it worked on my home computer using visual studio 2022, however using VS Code with gcc 11.2 gives me this issue.
Using:
filesystem::copy_file(oldPath, newPath, filesystem::copy_options::overwrite_existing);
The overloads of std::filesystem::copy are documented. You're using the first overload, but want the second:
void copy(from, to) which is equivalent to [overload 2, below] using copy_options::none
void copy(from, to, options)
Writing the statement std::filesystem::copy_options::update_existing; before calling copy doesn't achieve anything at all, whereas passing the option to the correct overload like
std::filesystem::copy(sourcepath, destpath,
std::filesystem::copy_options::update_existing);
should do what you want.
... it worked on my home computer using visual studio 2022 ...
you don't say whether the destination file existed in that case, which is the first thing you should check.
I put the copy_options within the copy function but it didn't work so I started moving it around, I probably should have mentioned that.
Randomly permuting your code isn't a good way of generating clean examples for others to help with.
In the rare event that hacking away at something does fix it, I strongly recommend pausing to figure out why. When you've hacked away at something and it still doesn't work, by all means leave comments to remind yourself what you tried, but the code itself should still be in a good state.
Still doesn't work when I write std::filesystem::copy(sourcepath, destpath, std::filesystem::copy_options::recursive)
Well, that's a different option, isn't it? Were you randomly permuting which copy_options you selected as well?
Trying recursive and update_existing yields the same issue.
The documentation says
The behavior is undefined if there is more than one option in any of the copy_options option group present in options (even in the copy_file group).
so you shouldn't be setting both anyway. There's no benefit to recursively copying a single file, but there may be a benefit to updating or overwriting one. If the destination already exists. Which, according to your error, it does.
Since you do have an error explicitly saying "File exists", you should certainly look at the "options controlling copy_file() when the file already exists" section of the table here.
Visual Studio 2022 fixed the problem
So i wanted to ask how to get "proper" Code Completion working for CodeBlocks 13.12 for c++, im running mint rosa at the moment.
By this i mean
string buf;
buf. <--This doesnt work - no suggestions
I would like the "." to show me relevant function/attribute names. It autocompletes variables and shows relevant type information, but nothing of the type mentioned above that originates from a library.
For example I see that this works for some cases
MyClass obj;
obj. <--This works
I am compiling a project that uses both ffmpeg and Ogre.
Now on Windows, everything works fine.
But when I want to compile a file with the following line of code:
Ogre::PixelFormat format = Ogre::PF_BYTE_RGBA;
The compiler gives the following error:
error: ‘AVPixelFormat’ is not a member of ‘Ogre’
Which is strange in many ways, as I have not only specified the Ogre namespace with ::, but also there is no AVPixelFormat in Ogre. How does gcc confuse "PixelFormat" with "AVPixelFormat"?
And how can I get rid of that?
I'd love to use int here instead of an enum, but another Ogre function requires format to be in Ogre::PixelFormat.
Preprocess it first using gcc -E, then grep through the file looking for AVPixelFormat or PixelFormat. I suspect you have a #define or a typedef floating around, you just need to find where this happens, and a precompiled source file is the place this will become apparent.
The problem is in avutil/pixfmt.h:
#define PixelFormat AVPixelFormat
This prevents users from using the word "PixelFormat" anywhere in their own code, even if in namespaces.
This is there as a compatibility hack for older software still using the old identifiers.
The solution is quite simple in case you can edit the code. Just add to the C++ code a
#define FF_API_PIX_FMT 0
before including the ffmpeg headers.
This disables the if in the pixfmt.h header:
#if FF_API_PIX_FMT
#define PixelFormat AVPixelFormat
...
Source: https://trac.ffmpeg.org/ticket/4216
P.S. I know the question is old, but somehow I feel that there is no solution and I needed a solution, so I added it.
I have reinstalled emacs 24.2.50 on a new linux host and started a new dotEmacs config based on magnars emacs configuration. Since I have used CEDET to some success in my previous workflow I started configuring it. However, there is some strange behaviour whenever I load a C++ source file.
[This Part Is Solved]
As expected, semantic parses all included files (and during the initial setup parses all files specified by the semantic-add-system-include variables), but it prints this an error message that goes like this:
WARNING: semantic-find-file-noselect called for /usr/include/c++/4.7/vector while in set-auto-mode for /usr/include/c++/4.7/vector. You should call the responsible function into 'mode-local-init-hook'.
In the above example the error is printed for the STL vector but a corresponding error message is printed for every file included by the one I'm visiting and any subsequent includes. As a result it takes quite a long time to finish and unfortunately the process is repeated any type I open a new buffer.
[This Problem Is Solved Too]
Furthermore it looks like the parsing doesn't really work as when I place the point above a non-c primitive type (i.e. not int,double,float, etc) instead of printing the type's definition in the modeline an error message like
Idle Service Error semantic-idle-local-symbol-highlight-idle-function: "#<buffer DEPFETResolutionAnalysis.cc> - Wrong type argument: stringp, (((0) \"IndexMap\"))"
Idle Service Error semantic-idle-summary-idle-function: "#<buffer DEPFETResolutionAnalysis.cc> - Wrong type argument: stringp, ((\"fXBetween\" 0 nil nil))"
where DEPFETResolutionAnalysis.cc is the file & buffer I'm currently editing and IndexMap and fXBetween are types defined in files included by the file I'm editing/some file included by the file I'm editing.
I have not tested any further features of CEDET/semantic as the problem is pretty annoying. My cedet config can be found here.
EDIT: With the help of Alex Ott I kinda solved the first problem. It was due to my horrible cedet initialisation. See his first answer for the proper way to configure CEDET!
There still remains the problem with the Idle Service Error (which, when enabling global-semantic-idle-local-symbol-highlight-mode, occurs permanently, not only when checking the definition of the type at point).
And there is the new problem of how to disable the site-wise init file(s).
EDIT2: I have executed semantic-debug-idle-function in a buffer where the problem occurs and it produces a ~700kb [sic!] output. It looks like it is performing some operations on a data container which, by the looks of it, contains information on all the symbols defined in the files parsed. As I have parsed a rather large package (~20Mb source files) this table is rather large. Can semantic handle a database that large or is this impossible and the reason of my problem?
EDIT3: Deleting the content of ~/.semanticdb and reparsing all includes did the trick. I still need to disable the site-wise init files but as this is not related to CEDET I will close this question (the question related to the site-wise init files can be found here).
You need to change your init file so it will perform loading of CEDET only once, not in the hook that will be called for each .h/.hpp/.c/.cpp files. You can change this config as the base, and read more in following article.
The problem that you have is caused because Semantic is trying to analyze header files, and when it tries to open them, then its initialization routines are called again, and again...
The first problem was solved by correctly configuring CEDET which is discribed on Alex Ott's homepage. His answer solves this first problem. The config file specified in his answer is a great start for a nice config; I have used the very same to config CEDET for my needs.
The second problem vanished once I updated CEDET from 1.1 to the bazaar (repository) version, which is explained here and in Alex' article. Additionaly one must delete the content of the directory ~/.semanticdb (which contains the semantic database and was corrupted I guess).
I'd like to thank Alex Ott for his help and sticking with me throughout my journey to the solution :)
I'm getting a link time error:
WARNING: /home/gulevich/development/camac-fedorov/camac/linux/k0607-lsi6/camac-k0607-lsi6.o (.ctors): unexpected non-allocatable section.
Did you forget to use "ax"/"aw" in a .S file?
Note that for example <linux/init.h> contains
section definitions for use in .S files.
The code causing the error (assembly in C source):
# if defined(__ELF__)
# define __SECTION_FLAGS ", \"aw\" , #progbits"
/* writable flag needed for ld ".[cd]tors" sections bug workaround) */
# elif defined(__COFF__)
# define __SECTION_FLAGS ", \"dr\""
/* untested, may be writable flag needed */
# endif
asm
(
".section .ctors" __SECTION_FLAGS "\n"
".globl __ctors_begin__\n"
"__ctors_begin__:\n"
".previous\n"
);
Is there any way to fix this? The idea is to put a varaible __ctors_begin__ at the beginning of a certain memory section. This code is a legacy that worked fine using a different build system and older compiler.
Meaning of this assembly code explained in an answer to my previous question.
very long shot but is the section .ctors is defined like you want in the linker script? ld iirc has a verbose option to show the linker script.
A long shot:
Perhaps your linker is expecting ELF format (instead of COFF), and for some reason __ELF__ is not defined? Have you checked the preprocessor output for this particular build?
I would dobule check the value of __SECTION_FLAGS just to be sure that it indeed contains ax or aw. I'd also be sure that __COFF__ is not defined and that __ELF__ is. Failing that, it might be time to grab (is possible) a previous or future version of the compiler/linker and see if that fixes your problem. Perhaps you could compile your code as C++ and somehow let the compiler/linker/link scritps do what they are supposed to do? Dunno completely, but this is where I would start.
Sections work fine. So I'll ignore this warning.