The title more or less describes the problem I'm having on my Ubuntu box.
I followed the following steps in installing libssh2, as given in the instructions:
./configure
make
make check (all 3 tests passed)
sudo make install (I have to use sudo due to permissions)
I then try to use some of the examples given in libssh2 page and they all have the following:
#include "libssh2_config.h"
Which isn't found. The following 3 files are created in usr/local/include:
libssh2.h
libssh2_publickey.h
libssh2_sftp.h
Is there anything I am doing wrong?
Thank you!
I still can't figure out why the file isn't created, but it is not really necessary, since removing the following #ifdefs:
#ifdef HAVE_WINDOWS_H
#include <windows.h>
#endif
#ifdef HAVE_WINSOCK2_H
#include <winsock2.h>
#endif
#ifdef HAVE_SYS_SOCKET_H
#include <sys/socket.h>
#endif
#ifdef HAVE_NETINET_IN_H
#include <netinet/in.h>
#endif
#ifdef HAVE_UNISTD_H
#include <unistd.h>
#endif
#ifdef HAVE_ARPA_INET_H
#include <arpa/inet.h>
#endif
and simply replacing (on linux) with:
#include <sys/socket.h>
#include <netinet/in.h>
#include <unistd.h>
#include <arpa/inet.h>
as well as removing the rest of #ifdefs in the code solves the problem.
libssh2_config.h is in the example dir, you need to copy into your projects.
There are libssh2_config.h files in the win32 dir, the vms dir and the os400 dir. You need to copy one of these into your projects.
Related
MSVC keeps telling me that ParseNetworkString is undefined.
But I've done:
#include <Winsock2.h>
#include <Ws2tcpip.h>
#include <iphlpapi.h>
as expressed in the remark part of the docs
Thank you.
I've had a look inside "iphlapi.h" and it states (line 1287)
// app must include winsock2.h, ws2ipdef.h, and windns.h to use this API
So when I use
#include <WinSock2.h>
#include <ws2ipdef.h>
#include <WinDNS.h>
#include <iphlpapi.h>
ParseNetworkString becomes available.
So it seems you were on the right track, just missing the include of <WinDNS.h>
I have a 3-dr party project that I'd like to build. The author said to build it I have to use the MSBuild. Here is the exact citation from him:
Clone https://github.com/NovaRain/DXSDK_Collection.git to some
Copy \DXSDK_Aug2007\Lib\x86\dinput.lib to \DXSDK_Jun2010\Lib\x86\
Set environment variable DXSDK_DIR to "\DXSDK_Jun2010" (trailing slash is important)
In sfall directory (where ddraw.sln is), create empty PostBuild.cmd
Run VS installer and add "MSVC v140 - VS 2015 C++ build tools (v14.00)" if you don't have it already
Find MSBuild.exe and run: MSBuild.exe path\to\ddraw.sln -p:Configuration=ReleaseXP -p:Platform=Win32 -p:PlatformToolset=v140_xp
I've followed all the steps carefully but when i run the MSBuild command I'm getting followin error: "Cannot open include file: 'algorithm': No such file or directory"
here is the stdafx.h header content for a reference:
#pragma once
#pragma message("Compiling precompiled headers.\n")
#define WINVER _WIN32_WINNT_WINXP
#define _WIN32_WINNT _WIN32_WINNT_WINXP
#include <algorithm>
#include <functional>
#include <initializer_list>
#include <memory>
#include <vector>
#include <unordered_map>
#include <map>
#include <string>
//#define WIN32_LEAN_AND_MEAN
#define NOCRYPT
#define NOSERVICE
#define NOMCX
#define NOIME
#include <Windows.h>
#include <intrin.h>
How could it be that the Standard Library headers isn't available since I've done a standard VS c++ installation?
I'm having a strange linking issue after I included inotify in my program to monitor changes to a filesystem. The project includes <fcntl.h> in many other source files. However, when I include <sys/inotify.h> in the source file which is doing the directory monitoring, I get this error:
/usr/include/fcntl.h:30:1: error: expected initializer before ‘extern’
__BEGIN_DECLS
My project uses CMake, although that doesn't seem to be relevant for finding inotify. It IS finding the inotify declarations to my knowledge, since when I included , it threw an error that inotify_init() and the other functions I used were not defined. Inotify includes fcntl and is partially built on top of some of the functionality there, so my first thought was that it's importing a different version of fcntl than the rest of my program.
In ObjectManager.h:
#ifndef MANAGE_OBJECT_H
#define MANAGE_OBJECT_H
#include "config.h"
//includes all lua headers under extern 'C'
#include <lua.hpp>
#include <list>
#include <unordered_map>
#include <pthread.h>
class ObjectManager //...
The only thing that changed was ObjectManager.cc, with the addition of sys/notify and the implementation of the watcher (not included because this is a linking issue):
#include "config.h"
#include "ObjectManager.h"
#include "Control.h"
#ifdef OBJECT_MANAGER_ENABLED
#include <string.h>
#include <stdio.h>
#include <dirent.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <vector>
#include <unistd.h>
#include <fstream>
#include <sys/inotify.h>
//... inotify implementation
Where Control.h declares #include <fcntl.h>.
This is the closest issue I found, related to some problems in the implementation of different fcntl headers for userspace usage. https://lkml.org/lkml/2008/9/16/98
The same problem occurs on Linux 2.6 running on Centos 6 and Linux 4.0 running on Centos 7.
Any ideas on what is causing this error and how to successfully include inotify?
Resolution: A function definition lacked a semicolon at the END of ObjectManager.h right before a #endif, and the resulting GCC error that propagated through the next includes in a complicated manner, resulting in a strange preprocessor error in fcntl.h.
I'm trying to port a TCP application (specifically tcpsockets), however im getting this error:
error: 'fcntl' was not declared in this scope
I already wrote those includes
#ifdef WIN32
#define _WIN32_WINNT 0x0600 //enable
#include <Ws2tcpip.h>
#pragma comment(lib, "ws2_32.lib")
typedef int socklen_t;
void close(int socket){closesocket(socket);}
#else
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#endif
Which solved most part of the references, however fcntl was not found.
How can I find a proper reference to it? Or naybe is there another windows method that could replace it?
fcntl() does not exist on Windows. For sockets, the equivalent function is ioctlsocket(). However, file controls on sockets in Linux are very different than in Windows, so not all of the fcntl() commands you are using may port to Windows, or may require different APIs.
Not sure why you are trying to use native sockets. But if there's no real reason, have a look at QTcpSocket instead. It's the Qt class for sockets and works on all platforms.
I have vim and clang_complete installed but for some reason when I try to auto complete it doesn't see some of OpenGL's functions, such as glBindBuffer, or glEnableVertexAttribArray. I press CTRL + X and CTRL + U to force the auto complete and it shows the function names and parameters, but it's just missing some of the functions.
Even with glfw, I try auto completing GLFW_KEY_ESC but it's not there, I don't know why, it just says User defined completion (^U^N^P) Pattern not found
Does anyone have a solution to this problem? It's very annoying because I use these functions a lot and need the auto complete.
Thanks.
EDIT: Also my include header files are this:
#include <iostream>
#include <string>
#include <GL/glew.h>
#include <GL/glfw.h>
#include <glm/glm.hpp>
I'm on Arch Linux x64 by the way.
All right I found the answer. Because of clang_complete not being able to complete the arguments created by GLEW (because the functions are defined as #define FOO somefunction, and not defined as: #define FOO(arg1, arg2, arg3) someFunction(arg1, arg2, arg3))
To fix this, you have to add this option to your ~/.vimrc file.
let g:clang_complete_macros = 1
Now, you'll get function completion, but still no argument completion. So, you'll have to replace GLEW (sadly) with
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
This will finally complete the arguments, although, if there's an alternative to doing fixing this problem, I'd like to hear.
To expand on zero57's answer.
You could add a clang_complete specific compile flag to define a macro for clang_complete
let g:clang_user_options = ' -DCLANG_COMPLETE_ONLY'
Then in your code you could use
#ifdef CLANG_COMPLETE_ONLY
#define GL_GLEXT_PROTOTYPES
#include <GL/gl.h>
#include <GL/glext.h>
#else
#include <GL/glew.h>
#endif
This isn't a perfect solution but clang_complete should now complete your parameters and when compiling you will be using glew. This worked for me with the YouCompleteMe (YCM) plugin so I assume it works with clang_complete.