I am trying to get the memory used by another process. From what I've read it seems like I need to use mach_vm_regeion. I found some code on a random forum and tried compiling to make sure I understood how it was working, but I get this error.
error: use of undeclared identifier 'mach_vm_region'
kret = mach_vm_region(task, &address, &size, VM_REGION_BASIC_INFO, (vm_regio...
^
1 error generated.
I am on OS X 10.11.2 compiling using clang++ --std=c++11 file.cpp.
clang --version returns
Apple LLVM version 7.0.2 (clang-700.1.81)
Target: x86_64-apple-darwin15.2.0
Thread model: posix
You don't have the correct includes. I find that
#include <mach/mach.h>
#include <mach/mach_vm.h>
works. You also need to change: vm_size_t size to mach_vm_size_t size, which is the type the function expects. Then it compiles and works as expected (when run as root, as the comment suggests).
Related
For some reason when I try to get the ast-dump of any C/C++ code with Clang, I get an infinite loop which eventually results in clang: error: linker command failed with exit code 1136 or some similar error code.
I'm running Windows 10 with Clang version 13.0 (Also tried Clang 12.0 with same issues). I run the command clang -Xclang -ast-dump filename.c.
I've tried multiple files, but at this point I'm just trying to get a hello world ast (which compiles and runs fine via clang).
#include <stdio.h>
int main()
{
printf("Hello, World!\n");
return 0;
}
I'm sure I'm missing something simple, but I'd appreciate any help, thanks!
It's not an infinite loop if it terminates. :-)
The dumped AST includes stdio.h, which you included, so it's quite big (about 800 lines, when I tried it).
The error message is because the clang compiler (cc1) does not produce an object file when you pass it the -ast-dump option, but the clang driver (clang) doesn't know that. The driver is expecting to be able to link the generated object file into an executable, but it doesn't find the object file so it complains.
Use
clang -Xclang -ast-dump -fsyntax-only filename.c
to terminate the driver after the AST has been dumped.
Having this error using c++17 on Mac OS.
As far as I can tell, code is correct and should work fine (compiles without issue w/ g++ and clang++ on linux).
Also, as far as I can tell, the current default mac version of clang [10.0.1] should support c++17 (full version info printout below).
So, my question is: is this actually a bug in my code, but it works by fluke on linux? Or is it an issue with MacOS clang e.g., not full c++17 implementation?
From cppref:
Defined in header (since C++17):
int abs( int n );
Other c++17 features seem to work completely fine.
#include <cmath>
// #include <cstdlib> //works if included
int main() {
int i = 1;
// return std::abs(1); // Works fine
return std::abs(i); // Fails
}
Compile with:
clang++ -std=c++17 test.cpp
Get this error:
test.cpp:7:10: error: call to 'abs' is ambiguous
return std::abs(i);
^~~~~~~~
/Library/Developer/CommandLineTools/usr/include/c++/v1/math.h:761:1: note:
candidate function
abs(float __lcpp_x) _NOEXCEPT {return ::fabsf(__lcpp_x);}
^
(... etc.)
1 error generated.
If you #include <cstdlib>, it works without error.
using -std=gnu++17 or -std=c++1z doesn't remove the problem either.
In the actual code (which is obviously more complex than the above, and actually uses c++17 features), the error happens depending on the order of my include files.
I can't replicate that in the simple example, but I assume it boils down to calling the cstdlib version instead of the cmath version.
Currently, my 'workaround' is to just put the header includes into the order that works..but this is hardly a long-term solution.
Does anyone know the cause?
Version info (error not specific to this MacOS version, also happens on my students' laptops):
Bens-iMac:test ben$ clang++ -v
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.5.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
See LWG Issue 2912
This has been fixed in libc++ trunk. I don't know if Apple has shipped this fix yet. As you found, including <cstdlib> is a workaround.
Earlier, I posed a related question.
I have the following program extracted from a large project in my Mac OS
#include <iostream>
int main(){
std::cout<<"hello"<<std::endl;
return 0;
}
Compiling it with Clang fails with the following error:
$ clang test.cpp
test.cpp:1:10: fatal error: 'iostream' file not found
#include <iostream>
^
1 error generated.
For information,
A) I have already installed xcode command line tools, using xcodeselect --install. But it seems iostream does not locate in the default search path of clang.
B) Using g++ instead of clang compiles the program. But in my problem, I am not allowed to use other compiler than clang, or to change the source program.
C) I can see workaround techniques, e.g, by tweaking the search path in .bashrc or with some symbolic link, etc. But I feel reluctant to use them, because it seems that I have an installation problem with my Clang and tweaking the path only helps to avoid one of these path issues.
clang and clang++ do different things. If you want to compile C++ code, you need to use clang++
Alternatively you can invoke c++ compiler directly by providing language name explicitely:
clang -x=c++
When trying to compile Protobuf-2.6.1 on Solaris 10 SPARC 64, I get:
./google/protobuf/stubs/once.h: In function `void google::protobuf::GoogleOnceInit(google::protobuf::ProtobufOnceType*, void (*)())':
./google/protobuf/stubs/once.h:125: error: cannot convert `google::protobuf::ProtobufOnceType*' to `const volatile google::protobuf::internal::Atomic32*' for argument `1' to `google::protobuf::internal::Atomic32 google::protobuf::internal::Acquire_Load(const volatile google::protobuf::internal::Atomic32*)'
./google/protobuf/stubs/once.h: In function `void google::protobuf::GoogleOnceInit(google::protobuf::ProtobufOnceType*, void (*)(Arg*), Arg*)':
./google/protobuf/stubs/once.h:134: error: cannot convert `google::protobuf::ProtobufOnceType*' to `const volatile google::protobuf::internal::Atomic32*' for argument `1' to `google::protobuf::internal::Atomic32 google::protobuf::internal::Acquire_Load(const volatile google::protobuf::internal::Atomic32*)'
I followed the Official README, ./configure and make.
The compiler version(GCC):
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: /sfw10/builds/build/sfw10-patch/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/ccs/bin/as --without-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
I also read the question protobuf generated files does not compile on Solaris SPARC 64 and tried, but it didn't work. That article works on Protobuf-2.4.1, but Protobuf-2.6.1 changes:
2014-10-20 version 2.6.1:
C++
* Added atomicops support for Solaris.
Is there any way to make GCC do force pointer conversion?
I solved the problem according to the github issue #789
The main reason is methioned in the 4th point of this issue. The predefined SOLARIS_64BIT_ENABLED macro takes no effect at all.
The problem can be solved simply by adding -m64 -DSOLARIS_64BIT_ENABLED to CXXFLAGS and CFLAGS. But it's better to do whole modification as the issue suggested.
I was working a project in C++ and all of the sudden my Mac said that Xcode was finished updating, so I just exited out of the popup and didn't think anything of it. I went back to my project and tried to run my makefile and it said I need to be root to accept Xcode's terms. So, I just booted up Xcode, accepted the terms, and quit. Now, when I work on my project in Vim, I am getting all kinds of errors. E.g.
#include<iostream> // 'iostream' file not found
#include<string>
int main()
{
std::cout << "hello" << std::endl; // use of undeclared identifier 'std'
return 0;
}
I have no idea what has happened. Can anybody help me?
I use g++ to compile and this is the output of g++ --version:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx- include-dir=/usr/include/c++/4.2.1
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.3.0
Thread model: posix
My Xcode version is now 6.0.1.
All this being said, I still seem to be able to compile my code. I am just getting all types of errors in Vim, related somehow to this Xcode update.
I use YouCompleteMe for error highlighting.
I believe I have found the solution. I am assuming that when Xcode updated, its folder structure changed.
I fixed this issue by changing my .ycm_extra_conf.py. I changed the flag line
'/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/c++/v1'
to
'/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1',