When including a Linux header file, ucontext.h in this case, in a Linux C++ Project on Visual Studio 2017 for my C program, it does not recognize the header file. Even when I include sys/ucontext.h, it does not recognize functions that I should be able to use for a ucontext_t object, such as getContext() and setContext(). Shouldn't I be able to use these functions in a Linux C++ project?
Code I'm writing:
#include <stddef.h>
#include <string.h>
#include <sys/ucontext.h>
// If I use ucontext.h instead, it gives the error: cannot open source file ucontext.h
//TCB structure
typedef struct TCB_t {
struct TCB_t *next;
struct TCB_t *prev;
ucontext_t context;
} TCB_t;
void init_TCB(TCB_t *tcb, void *function, void *stackP, int stack_size)
{
memset(tcb, '\0', sizeof(TCB_t));
tcb->context.uc_stack.ss_sp = stackP;
tcb->context.uc_stack.ss_size = (size_t)stack_size;
int c = getcontext(tcb->context); // Cannot resolve field getcontext()
}
On this answer to do the following you need Visual Studio Community 2017 15.9.7+ - Tested this solution on Visual Studio Enterprise
2019 Preview 4.
Visual Studio needs to download all remote headers in your localmachine for correct behavior of intellisense.
New method 'rsync_ssh' doesn't download all headers. You can use old method .zip via sftp_ssh.
0. Add remote connection.
Tools->Options->Cross Platform->Connection Manager
1. Select your connection
Update from Tools->Options->Cross Platform->Connection Manager->Remote Headers Intellisense Manager.
Next click on Explore button.
2. C:\Users[YourUser]\AppData\Local\Microsoft\Linux\HeaderCache\1.0[IdNumber]
Rename the HeaderCache settings.xml.unused file to settings.xml
3. In the settings.xml file Change the syncMethod to sftp_ssh.
4. Update headers cache from Tools->Options->Cross Platform->Connection Manager->Remote Headers Intellisense Manager.
5. Enjoy.
Before
After
On my Linux system (Debian Jessie) ucontext.h is in usr/include which in turn includes sys/ucontext.h which gcc will find in usr/include/i386-linux-gnu/sys. The first defines the functions getcontext and setcontext. The second defines the data structures ucontext_t etc.
On the Windows host, VCLinux has installed a copy of the second ucontext.h (which defines the data structures) in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Linux\include\usr\include\x86_64-linux-gnu\sys . But the first ucontext.h is not present.
VCLinux/Visual Studio will compile and run this program on the Linux remote:
#include <ucontext.h>
#include <iostream>
int main()
{
ucontext ucxt;
::getcontext (&ucxt);
std::cout << ucxt.uc_flags << std::endl;
return 0;
}
But IntelliSense will not know about the functions getcontext and setcontext or the associated data structures. So you will get little red squiggles under the names and no completion assistance.
You can take a copy of the first ucontext.h and put it in C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\Linux\include\usr\include on your Windows host. Then everything will work as it should. And you could raise an issue for the missing header on the VCLinux GitHub site.
Note: Windows paths are for Visual Studio 2015. They will be different for 2017.
Applies to VCLinux 1.0.6.
==============
Update 10-Apr-18
Microsoft have addressed the issue of differences in standard include file locations between Linux systems. As explained in this Visual C++ blog post, the headers specific to the GCC setup are copied from the Linux remote and stored on the Windows host on a per-connection basis.
Related
I'm new in winAPI and I was learning how code programs with some special functions and such, so I downloaded the Windows's SDK.
Problem is, GCC decided to put the blind glasses and say:
Documents_path.c:6:25: fatal error: KnownFolders.h: No such file or directory
#include<KnownFolders.h>
^
compilation terminated.
I said "OK, next one then" and there's another header with the same problem:
thread.c:3:30: fatal error: processthreadsapi.h: No such file or directory
#include<processthreadsapi.h>
^
compilation terminated.
I checked if these headers are even in my PC and here they are setting with windows.h, which it was working when I tried basic functions with it.
I searched an answer for this problem but didn't find any, either it was a external\binary libraries problem, is it local or not or a macro fix (which it didn't work).
How can I fix the problem?
EDIT:
I'm using VS Code
EDIT2:
This is the code of "Documents_path.c" example:
#include<stdio.h>
#include<stdlib.h>
#include<Windows.h>
#include<ShlObj.h>
#include<initguid.h>
#include<KnownFolders.h>
#pragma comment(lib, "user32.lib")
int main(){
int a;
PWSTR path = NULL;
HRESULT hr = SHGetKnownFolderPath(&FOLDERID_Documents, 0, NULL, &path);
if(SUCCEEDED(hr)){
printf("path for Documents is: %ls", path);
}
scanf("%d",&a);
CoTaskMemFree(path);
return 0;
}
And I'm reading the basics of winAPI from this website:
https://zetcode.com/gui/winapi/
as for structure of project folder:
C:\Users\ %USER%\Documents\C\dawd
MSVC uses Windows SDK while GCC does not.
On Windows GCC uses MinGW or MinGW-w64 as standard library, which is an open source implementation of Windows API.
So GCC+MinGW will use its own headers and will not look for any Windows SDK. So GCC+MinGW on Windows works without having any Microsoft developer tools installed at all.
MinGW-w64 - which is more recent than MinGW and which supports both Windows 32-bit and 64-bit - exists in a standalone package that can be downloaded from https://winlibs.com/. But you can still use it from an IDE like VSCode or Code::Blocks.
MinGW-w64 has the files like knownfolders.h and processthreadsapi.h which you had issues with.
But be aware that #pragma comment(lib, "user32.lib") is MSVC-specific and will not work in other compilers like GCC. Instead you must use linker flag -luser32. Because you call CoTaskMemFree() you will also need to add -lole32.
I tried your code on my system and it compiles and links fine with:
gcc -c -o Documents_path.o Documents_path.c
gcc -o Documents_path.exe Documents_path.o -luser32 -lole32
I tried to compile on windows c program with tenserflow c api and tenserflow.dll from https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-cpu-windows-x86_64-1.12.0.zip founded on https://www.tensorflow.org/install/lang_c.
This example:
#include <stdio.h>
#include <tensorflow/c/c_api.h>
int main() {
printf("Hello from TensorFlow C library version %s\n", TF_Version());
return 0;
}
Compiling is success, but when i have run it, i recieved a mistake that libtenserflow.so not found. Its look like that tensorfow,dll from https://storage.googleapis.com/tensorflow/libtensorflow/libtensorflow-cpu-windows-x86_64-1.12.0.zip was builded with some mistakes for windows sistem, becaurse libtensorflow.so is a target for Linux.
Can you explain or fix this?
I guess it looks for tensorflow.so because you were using GCC tools on VS Code's WSL mode (or other IDEs). But in order to load DLL you need to have Visual Studio.
Here's a simple process to run the Tensorflow for C demo:
Create a new project in Visual Studio;
Configure the project properties(assume the Tensorflow path is C:\tensorflow\; replace it with yours):
C/C++ > General > Additional Include Directories, add "C:\tensorflow\include\"
Debugging > Environment, add "PATH=C:\tensorflow\lib\;%PATH%"
Don't forget the "PATH=" before your tensorflow.dll path.
Compile and run.
You may also add the Tensorflow path to system environment (replace C:\tensorflow\ with your path):
SET PATH=%PATH%;C:\tensorflow\lib\
P.S. If you don't like the Visual Studio IDE and prefer to use Tensorflow with command line mode, try Bazel for Windows instead.
I have a Java program which makes use of some native function calls to speed up video encoding. It requires a DLL, which I will write in C (I have just a test one right now).
When I compile the DLL with cl /I "java-path/include" /"java-path/include/win32" -DL -ML Main.c -FeTest.dll it compiles, but I get a 32-bit DLL. After I did some research on the internet, I found out that I would need a 64-bit DLL instead.
After more research, I have found this post which is the only one for C (even C++ was hard to find), but this only works if you are writing/building via Visual Studio 2010. I am using Elipse for the Java, CLion for the C, and compiling via the "Developer Command Prompt." so this does not work for me. How might I recompile as a 64-bit DLL?
EDIT: I am using the cl.exe that comes with Visual Studio 2017
UPDATE: I found the 64-bit cl.exe under C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.13.26128\bin\Hostx64\x64\cl.exe, however when running it, I get an error that the library machine type (x86) conflicts with the target type (x64). How do I change the library machine type?
As I explained at the beginning of [SO]: How to build a DLL version of libjpeg 9b? (#CristiFati's answer) (bullets from 1. Prepare the ground section), there are different ways to deal with building from command line in VStudio. I'm going to focus on vcvarsall.bat. More details on [MSDN]: Setting the Path and Environment Variables for Command-Line Builds (It's VStudio2015 as VStudio2017 link is broken). I prepared a dummy example.
code.c:
#include <stdio.h>
#include "jni.h"
__declspec(dllexport) int func() {
JavaVMInitArgs args;
printf("Pointer size: %lld bits\n", sizeof(void*) * 8);
printf("JNI_GetDefaultJavaVMInitArgs returned: %d\n", JNI_GetDefaultJavaVMInitArgs(&args));
return 0;
}
Build:
e:\Work\Dev\StackOverflow\q050164687>"c:\Install\x86\Microsoft\Visual Studio Community\2017\VC\Auxiliary\Build\vcvarsall.bat" amd64
**********************************************************************
** Visual Studio 2017 Developer Command Prompt v15.6.6
** Copyright (c) 2017 Microsoft Corporation
**********************************************************************
[vcvarsall.bat] Environment initialized for: 'x64'
e:\Work\Dev\StackOverflow\q050164687>dir /b
code.c
e:\Work\Dev\StackOverflow\q050164687>cl /nologo /LD /I"c:\Install\x64\Oracle\Java\jdk1.8.0_152\include" /I"c:\Install\x64\Oracle\Java\jdk1.8.0_152\include\win32" /DWIN64 /DWIN32 code.c /link /LIBPATH:"c:\Install\x64\Oracle\Java\jdk1.8.0_152\lib" /OUT:dummy.dll jvm.lib
code.c
Creating library code.lib and object code.exp
e:\Work\Dev\StackOverflow\q050164687>dir /b
code.c
code.exp
code.lib
code.obj
dummy.dll
Notes:
My vcvarsall path is custom, because I installed VStudio2017 under "C:\Install\x86\Microsoft\Visual Studio Community\2017". Default path is "%SystemDrive%\Program Files (x86)\Microsoft Visual Studio\2017\Community"
After running vcvarsall, I don't have to specify to cl.exe (or link.exe):
The full path
Build options (architecture specific, including paths)
I still have to specify things that it doesn't know about (like Java stuff)
In order to test the newly built .dll, I'm going to use Python, as it's easier than writing another .c program that uses it
Since I linked the .dll to jvm.lib, at runtime it will need jvm.dll, so I'm adding its path into %PATH%
I built my code with VStudio2017 (VCRuntime14.0), but jvm.dll is linked to VCRuntime10.0 (VStudio2010), meaning that there will be (at least) 2 VCRuntimes loaded in my program. That is to be avoided as it could lead to all kinds of nasty problems
e:\Work\Dev\StackOverflow\q050164687>set PATH=%PATH%;c:\Install\x64\Oracle\Java\jdk1.8.0_152\jre\bin\server
e:\Work\Dev\StackOverflow\q050164687>"e:\Work\Dev\VEnvs\py35x64_test\Scripts\python.exe"
Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:17:05) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import ctypes
>>> dummy = ctypes.CDLL("dummy.dll")
>>> dummy.func()
Pointer size: 64 bits
JNI_GetDefaultJavaVMInitArgs returned: -1
0
>>>
Hello I'm trying to build the simplest possible DLL in C using VS2013 community edition. I set "Not using Precompiled Headers" in the options (although somehow the project creation wizard seems to indicate that Using Precompiled Headers is
imposed because it's a greyed check option. Anyway I decide to turn it off uing the menus associated with the project properties anyway.) But I still get this error saying
Error 1 error C1853: 'Release\ExportDLLVars.pch' precompiled header file is from a previous version of the compiler, or the precompiled header is C++ and you are using it from C (or vice versa) D:\devt\CplusPlus\Tests\ExportDLLVars\ExportDLLVars\VarsSource.c 1 1 ExportDLLVars
I have created a default DLL project using the wizard and added the following two source files
#define NAME_SIZE 80
struct _Person
{
char name[NAME_SIZE];
int tel_nb;
int age;
};
#ifdef EXPORTDLLVARS_EXPORTS
#define DLL_VAR __declspec(dllexport)
#else
#define DLL_VAR __declspec(dllimport)
#endif
DLL_VAR int get_age();
DLL_VAR void set_age(int a);
DLL_VAR extern struct _Person ThePerson;
as the header file VarsSource.h and the C file is this:
#include "VarsSource.h"
DLL_VAR struct _Person ThePerson;
DLL_VAR int get_age(){ return ThePerson.age; }
DLL_VAR void set_age(int a){ ThePerson.age = a; }
The wizard creates a C++ project. Your C file cannot share precompiled headers with the C++ files generated by the wizard, which is what this part of the error means: or the precompiled header is C++ and you are using it from C.
Try the following:
Do a full Clean for all configurations.
Remove the stdafx.cpp file from the project.
Recheck the project settings and make sure that Configuration Properties / C/C++ / Precompiled Headers has them turned off both at the project level, and for each C/C++ file individually.
i have simple C source file created and compiled nicely on GNU gcc/cc. However when I wanted to compile in Visual Studio on Windows it gives me lots of errors. Is there any particular settings to set for VS compiler in order to compile nicely C source code.thanks
C source (standard style ?)
#include <..>
//function prototype
int main(){
// my code here
}
/* all my other functions below this */
Just found out I can use cl.exe . would try this first.