I'm trying to use libssh on Windows 10 with gcc. The work is being done from the command line.
I don't know how to make libssh/ part of the search path.
The #include was libssh/libssh.h, but that failed. (The brackets were left out of this sentence.)
#include <libssh.h>
#include <stdlib.h>
int main()
{
ssh_session my_ssh_session = ssh_new();
if (my_ssh_session == NULL)
exit(-1);
...
ssh_free(my_ssh_session);
}
When I modify the include statement to be just libssh.h and use the following on the command line:
gcc -IC:\libssh\include\libssh ssh.c -oout.exe
That works to get past the libssh.h file not found.
But, the other files that are called, such as libssh/legacy.h are not found.
How do I get the libssh to be part of the search path?
I added c:\libssh\include\libssh to the environment path. That didn't work.
You need to let #include <libssh/libssh.h>
because libssh.h call a header legacy.h which is also located in the libssh folder so if you put directly the header libssh.h it won't be able to locate legacy.h
#include <libssh/libssh.h>
#include <stdlib.h>
int main()
{
ssh_session my_ssh_session = ssh_new();
if (my_ssh_session == NULL)
exit(-1);
// remove the dots it'll create an error
ssh_free(my_ssh_session);
}
to have libssh a part of the path you should do
gcc -I/path/to/libssh/include/directory -L/path/to/libssh/lib/directory -lssh ssh.c oout.exe
I also got stuck into that, now I face another issue, the one to link the libssh.dll or ssh.dll inside the compiled code to use it as stand-alone.
Related
I'm trying to run this code and im a beginner at this im really struggling I don't know what to do.
NB: A "MinGW" version of Code::Blocks was used here.
#include <stdio.h>
#include <omp.h>
int main() {
printf ("Hello, world:");
#pragma omp parallel
printf (" %d", omp_get_thread_num ());
printf ("\n");
return 0;
}
Change a debugger setting in the following way.
From the Settings menu click on Debugger..., then on the left of the screen select Default, a debugger type. This should show Executable paths set to:
C:\MinGW\bin\gdb.exe
change this to:
C:\Program Files\Codeblocks\MinGW\bin\gdb.exe
You should then be able to use the debugger.
NB: Other Information
The above type of fix is required if you install the "MinGW" version of 'Code::Blocks 20.03' on Windows, using 'codeblocks-20.03mingw-setup.exe' ( the version relevant on 8th April 2021 , with the default installation type used ).
Is there a pre-existing WinAPI to check if some_app.exe can run w/o providing full-path and running it at any point?
For example, let's say I want to run cmd.exe or git.exe, but I don't provide with full path . Before I run it, is it possible of me to know prematurely if I can run it without knowing its full path?
One idea that comes to my mind is to emulate the way Windows does it, i.e. to check the current path, then to iterate through %PATH% variable and so on, but is there perhaps a Winapi for this exact purpose?
#RbMm has already pointed out the solution: Use SearchPath API.
The following is an example (a console application) of how to use that API, you can refer to.
#include <windows.h>
#define BUF_SIZE 260
int main()
{
WCHAR appFullPath[BUF_SIZE];
DWORD result = SearchPath(NULL, L"git.exe",NULL, BUF_SIZE, appFullPath, NULL);
if(result == 0)
wprintf(L"SearchPath call get an error: %d \n", GetLastError());
wprintf(L"App full path: %s \n", appFullPath);
getchar();
}
The output of above code:
When 32bit app like java or python is trying to open c:\windows\system32\bash.exe this file simply not found.
How ever, it works perfectly if process ir 64bit. I've created a simple C app to check how it works.
#include <stdio.h>
#include <windows.h>
int main(int argc, char *argv[]) {
char* path;
OFSTRUCT junk;
if (argc != 2) {
printf("provide path to file");
return 1;
}
path = argv[1];
if( fopen( path, "r")) {
printf("OK: Runtime reports file exists");
} else {
printf("ERR: Runtime reports file does not exist");
}
printf("\n");
if (OpenFile(path, &junk,OF_EXIST) != HFILE_ERROR) {
printf("OK: Win32API reports file exists");
} else {
printf("ERR: Win32API reports file does not exist");
}
return 0;
}
It reports OK/OK when compiled and linked as x64 and ERR/ERR when compiled as x86. How could it be? Does there is some way to "hide" file from 32 bit apps in Windows?
This is the file system redirector in action.
In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64.
So, your 32-bit application is looking for C:\Windows\SysWOW64\bash.exe instead, which presumably doesn't exist.
The recommended way to override it:
32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access.
Note that there are similar redirections for the registry as well.
Im using fanotify to track disk changes.
fanotify associates file descriptor to my process, which I need to close once Im done dealing with the event.
However, even though the close(fd) is successful, It seems that the file descriptor remains open.
Im using the man fanotify example
The close(..) returns with no errors, but looking at /proc/<pid>/fdinfo tells a different story.
Is there a way to overcome this?
Without clearing the descriptors associated with a process, a read(..) call may encounter read: Too many open files
The error Im receiving is:
EMFILE The per-process limit on the number of open files has been reached. See the description of RLIMIT_NOFILE in getrlimit(2).
I expected to test it with this sample code, but here it works OK:
#include <iostream>
#include <cstdio>
#include <string>
#include <unistd.h>
int main ()
{
close(2);
std::string line; std::getline(std::cin, line);
return 0;
}
I am looking for a simple solution to open a file, probably using CreateFile and being sure that nobody can read/write to it and still being able to obtain a std::iostream object, which is needed later.
I think you can do the following:
#include <iostream>
#include <fstream>
fstream my_stream;
my_stream.open("my.file", std::ios_base::in | std::ios_base::out, _SH_DENYRW);
my_stream << "test";