error C3861: 'major': identifier not found
-
I have met another error while converting the project:
error C3861: 'major': identifier not found
error C3861: 'minor': identifier not foundthese are defined somewhere into gcc/linux. But can I use it in my win32/mfc project ? I have tried:
#define major(dev) gnu_dev_major(dev)
#define minor(dev) gnu_dev_minor(dev)but then
gnu_dev_major
is the problem. Of course, I have dig in on internet, and I haven't found something that solve the issue: gnu_dev_major(3): manage device number - Linux man page[^], or c++ - major and minor macros defined in sys/sysmacros.h pulled in by <iterator> - Stack Overflow[^] How can I overcome this error ? -
I have met another error while converting the project:
error C3861: 'major': identifier not found
error C3861: 'minor': identifier not foundthese are defined somewhere into gcc/linux. But can I use it in my win32/mfc project ? I have tried:
#define major(dev) gnu_dev_major(dev)
#define minor(dev) gnu_dev_minor(dev)but then
gnu_dev_major
is the problem. Of course, I have dig in on internet, and I haven't found something that solve the issue: gnu_dev_major(3): manage device number - Linux man page[^], or c++ - major and minor macros defined in sys/sysmacros.h pulled in by <iterator> - Stack Overflow[^] How can I overcome this error ?Could the definitions from [glibc/sysmacros.h at master · git-mirror/glibc · GitHub](https://github.molgen.mpg.de/git-mirror/glibc/blob/master/sysdeps/unix/sysv/linux/sys/sysmacros.h) help you?
-
Could the definitions from [glibc/sysmacros.h at master · git-mirror/glibc · GitHub](https://github.molgen.mpg.de/git-mirror/glibc/blob/master/sysdeps/unix/sysv/linux/sys/sysmacros.h) help you?
If I wrote:
#define major(dev) gnu_dev_major(dev)
#define minor(dev) gnu_dev_minor(dev)then I got following error:
error C3861: 'gnu_dev_major': identifier not found
error C3861: 'gnu_dev_minor': identifier not foundI have arrived in a kind of same error ...
-
If I wrote:
#define major(dev) gnu_dev_major(dev)
#define minor(dev) gnu_dev_minor(dev)then I got following error:
error C3861: 'gnu_dev_major': identifier not found
error C3861: 'gnu_dev_minor': identifier not foundI have arrived in a kind of same error ...
Didn't you read the link I have posted? There are some definition of the functions... Just try something like
unsigned int gnu_dev_major (unsigned long long int __dev)
{
return ((__dev >> 8) & 0xfff) | ((unsigned int) (__dev >> 32) & ~0xfff);
} -
Didn't you read the link I have posted? There are some definition of the functions... Just try something like
unsigned int gnu_dev_major (unsigned long long int __dev)
{
return ((__dev >> 8) & 0xfff) | ((unsigned int) (__dev >> 32) & ~0xfff);
} -
Ahh, I didn't read whole source code. I am struggle to solve another errors. But I implemented what you said and I get rid of that error. Thank you Victor !!!
You are welcome! But be sure that this function definition is correct! ;)
-
I have met another error while converting the project:
error C3861: 'major': identifier not found
error C3861: 'minor': identifier not foundthese are defined somewhere into gcc/linux. But can I use it in my win32/mfc project ? I have tried:
#define major(dev) gnu_dev_major(dev)
#define minor(dev) gnu_dev_minor(dev)but then
gnu_dev_major
is the problem. Of course, I have dig in on internet, and I haven't found something that solve the issue: gnu_dev_major(3): manage device number - Linux man page[^], or c++ - major and minor macros defined in sys/sysmacros.h pulled in by <iterator> - Stack Overflow[^] How can I overcome this error ?It looks like you're trying to use a GCC/linux function under Windows. Does that even make any sense? I mean, I've seen that you got it to compile now, but that doesn't mean your program will do what you expect it to! I'm not familiar with gcc/linux and these functions, but if what Victor posted corresponds to the original implementation, it looks like dev is some version identifier composed of a major and minor version number. The way such versions are composed in Windows may be entirely different! There's no common scheme for it between different applications, compilers, or the OS itself. So don't expect any correct results from a Linux implementation! To properly solve this issue you should find out who uses these functions and what are they expected to return. Only then will you be able to implement a proper replacement. Or, better, find the corresponding functions provided in Windows.
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)
-
It looks like you're trying to use a GCC/linux function under Windows. Does that even make any sense? I mean, I've seen that you got it to compile now, but that doesn't mean your program will do what you expect it to! I'm not familiar with gcc/linux and these functions, but if what Victor posted corresponds to the original implementation, it looks like dev is some version identifier composed of a major and minor version number. The way such versions are composed in Windows may be entirely different! There's no common scheme for it between different applications, compilers, or the OS itself. So don't expect any correct results from a Linux implementation! To properly solve this issue you should find out who uses these functions and what are they expected to return. Only then will you be able to implement a proper replacement. Or, better, find the corresponding functions provided in Windows.
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)
-
"find the corresponding functions provided in Windows" I am perfectly agree with you. This is another part of work. And I am not sure that I'll find such replacement.
Yes, it's entirely possible you won't find a match. That is the problem with language extensions, and the reason why many projects insist on staying compatible to the C++ standard instead.
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)