I have written a programm in C and GTK3. I am using Arch Linux and everything works fine. However, I have to use my program also on a rather old Ubuntu machine.
gtk+-3.0 3.10.8
GCC 4.8.4
With this setup the program does not compile
In the Header file of a custom GTK-Widget I have:
#ifndef __LAYER_ELEMENT_H__
#define __LAYER_ELEMENT_H__
#include <gtk/gtk.h>
G_BEGIN_DECLS
G_DECLARE_FINAL_TYPE(LayerElement, layer_element, LAYER, ELEMENT, GtkListBoxRow)
/* Rest of file comes here */
When compiling it throws the error message:
expected ')' before GtkListBoxRow in the line with the G_DECLARE_FINAL_TYPE macro.
How can I fix this issue?
G_DECLARE_FINAL_TYPE was added to GLib in version 2.44 (see the documentation). If you want to compile on an old version of Ubuntu, you will either have to get hold of a backport of GLib 2.44 (or later) for that version of Ubuntu, and compile against that; or you will have to modify your code to not use any GLib APIs added after version 2.40.
Related
I realize a CMSIS Project solution with VS Code but I've an error on an include file :
#include "stm32f10x.h"
And I've got this error :
In included file: "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"clang(pp_hash_error)
core_cm3.h(90, 6): Error occurred here
The path of this file is here :
C:\Users\"name"\AppData\Local\Arm\Packs\Keil\STM32F1xx_DFP\2.4.0\Device\Include
But I think I forgot something during the configuration.
I justa want to build my C file but VS code doesn't make the link between my .h and my CMSIS project.
You are never supposed to #include "stm32f10x.h"
You only #include "stm32f1xx.h" and it will include the other headers you need.
You must also define a macro on the command line, one of STM32F101x6, STM32F101xB, STM32F101xE or STM32F101xG.
For most compilers you can define this with an argument like -DSTM32F101xB.
After that you will need particular command line arguments that match your chosen processor, such as -mthumb -mcpu=cortex-m3 -mfpu=none.
Maybe your error was specifying an incorrect -mfpu=.
I have the following setup:
Eclipse Mars 4.5 (Build id:20150621-1200)
MinGW 201310 with g++ 4.8.1
Windows 10
I followed few post to add std=c++11 in Project property and make sure __cplusplus is 201103L. Here is the result:
I can see that std::map compile and run ok.
If I #include , there is no syntax error. But the declaration of thread in main() shows error "Type thread could not be resolved". Then I open up thread header file located in c:/MinGW/lib/gcc/mingw32/4.8.1/include/c++/thread, it seems that the whole class is dimmed due to that _GLIBCXX_HAS_GTHREADS is undefined. If I manually define it in the path and symbols, then the thread class is fully defined. But there comes more errors in the thread itself. Did I missed something? Or if the C++11 thread isn't ready on eclipse+MinGW? Thank you!
To get support for std::thread, you will want a MinGW build equipped with posix threading model support.
I'm not sure if there's a "classic" MinGW build with that feature,
but it's available with MinGW-w64.
You can get a MinGW-w64 installation in a number of ways, but the installer under the "Mingw-builds" link should be sufficient to get you started (and will let you pick which release GCC you want).
I have a whole bunch of working C++ code that I want to write Python bindings for. I'm trying to use Boost.Python since it seems to be the easiest way to get this working, but it isn't cooperating. Here's part of the code for the extension module I'm trying to build:
BOOST_PYTHON_MODULE(libpcap_ext) {
using namespace boost::python;
class_<PacketEngine>("PacketEngine")
.def("getAvailableDevices", &PacketEngine_getAvailableDevices);
}
Bjam seems to be a pain and refuses to recognize my Pythonpath or allow me to link with libpcap, so I'm using CMake. Here's my CMakeLists file, which can import and build everything just fine (outputs libpcap.so as expected):
CMAKE_MINIMUM_REQUIRED(VERSION 2.8)
IF(NOT CMAKE_BUILD_TYPE)
SET(CMAKE_BUILD_TYPE "DEBUG")
#SET(CMAKE_BUILD_TYPE "RELEASE")
#SET(CMAKE_BUILD_TYPE "RELWITHDEBINFO")
#SET(CMAKE_BUILD_TYPE "MINSIZEREL")
ENDIF()
FIND_PACKAGE(Boost 1.55.0)
find_package(PythonLibs REQUIRED)
IF(Boost_FOUND)
INCLUDE_DIRECTORIES("${Boost_INCLUDE_DIRS}" "${PYTHON_INCLUDE_DIRS}")
SET(Boost_USE_STATIC_LIBS OFF)
SET(Boost_USE_MULTITHREADED ON)
SET(Boost_USE_STATIC_RUNTIME OFF)
FIND_PACKAGE(Boost 1.55.0 COMPONENTS python)
ADD_LIBRARY(pcap_ext MODULE PacketWarrior/pcap_ext.cc PacketWarrior/PacketEngine.h PacketWarrior/PacketEngine.cc PacketWarrior/Packet.h PacketWarrior/Packet.cc)
TARGET_LINK_LIBRARIES(pcap_ext pcap)
TARGET_LINK_LIBRARIES(pcap_ext ${Boost_LIBRARIES} ${PYTHON_LIBRARIES})
ELSEIF(NOT Boost_FOUND)
MESSAGE(FATAL_ERROR "Unable to find correct Boost version. Did you set BOOST_ROOT?")
ENDIF()
ADD_DEFINITIONS("-Wall")
And my pcap.py file that attempts to utilize the module:
import libpcap_ext
engine = libpcap_ext.PacketEngine()
print engine.getAvailableDevices()
But whenever I try to run the module, I get the following error:
Traceback (most recent call last):
File "../pcap.py", line 2, in <module>
engine = libpcap_ext.PacketEngine()
TypeError: __init__() should return None, not 'NoneType
I'm assuming it's because Boost.Python is trying to use Python 3 and my system default is Python 2.7.3. I've tried changing my user-config.jam file (in my boost_1_55_0 directory) to point to Python 2.7 and tried building:
# Configure specific Python version.
# using python : 2.7 : /usr/bin/python2.7 : /usr/include/python2.7 : /usr/lib ;
Boost.Python's installation instructions [0] seem to fail for me when I try to build quickstart with bjam (lots of warnings), so I tried following the Boost Getting Started instructions [1] to build a Python header binary, which is I think what is causing this problem. Any recommendations as to how to fix this would be amazing, I've spent hours on this.
This error is probably due to linking against the wrong Python library. Make sure your extension as well as the Boost Python library are linked against the Python installation you are using to import the module.
On Linux you can check against which libraries you've linked with ldd. On OS X otool -L does the same thing. So, for example
otool -L libpcap_ext.so
otool -L /path/to/libboost_python-mt.dylib
should list the Python library they are linked against.
With CMake you can use the variable PYTHON_LIBRARY to change which Python library is used. As an example, on the command line you can set it with
cmake -DPYTHON_LIBRARY="/path/to/libpython2.7.dylib" source_dir
Lastly, on OS X a quick and dirty way (i.e. without recompiling) to change the dynamically linked libraries is install_name_tool -change.
Update
Thank you Vladimir for the usefull insights in libraries. I took another approach, developping first in ubuntu (which was a lot easier then messing around with Eclipse/Cygwin/... and now I'm trying to port to windows, which goes rather ok, however I have some questions about that too, posted here: Problems with porting a fortran program from ubuntu to windows
Question
I currently have the following setup and can't get the lapack library configured so that my fortran code can compile:
Windows 7
Cygwin installation (for GNU fortran), added to the windows PATH
lapack and liblapack-devel installed with cygwin
resulting in liblapack.a and libblas.a in the folder C:/cygwin/lib
In my program I call the lapack library using the following code
program myProgram
!use lapack (stays commented now)
...
In Eclipse I used the following setup (with the Photran package):
Fortran Project: executable GNU fortran on Windows (GCC toolchain)
GNU fortran compiler: gfortran ${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
GNU fortran linker: gfortran ${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}
I compiled the libraries libblas.a and liblapack.a, to use as a static library, for windows and they are located in the C:/cygwin/lib folder. In the GNU fortran linker properties, the libraries were called lapackand blasin the folder C:/cygwin/lib. This results in a part -L"C:/cygwin/lib" -llapack -lblas in the {$COMMAND} section of the compiler and linker. (thanx to #vladimir-f for the help)
In the output there are no error messages left anymore. Only I got now the following error in Eclipse and no final .exe or bins:
Errors occured during the build.
Errors running builder 'CDT Builder' on project 'Hamfem'
Internal error building project Hamfem configuration
Release
java.lang.NullPointerException
Internal error building project Hamfem configuration
Release
java.lang.NullPointerException
However, the result of the build is still an executable, in this case called Hamfem.exe. Running this file results in the error message (instead of the routine): The program can't start because cyglapack-0.dll is missing from your computer. Try reinstalling the program to fix this problem.
That file is currently located in C:/cygwin/lib/lapack/ but I want that this file isn't needed to run the program, so I can run it on different computers. Can someone collaborate on this?
Second, when copy-pasting the .dll file in the folder where the .exe is located, it runs for a brief second, generating a stackdump file. I can't use the debugger in Eclipse-Photran due to the 'Building Workspace' error. Eclipse gives the message Binary not found when I want to run it in Eclipse as a local Fortran program. Any ideas how to resolve this problem?
The problem is here
L/lib/lapack –llapack
try to change it for
-L/lib/lapack –llapack
probably it is in you Makefile.
i.e.
gfortran -funderscoring -O3 -Wall -c -fmessage-length=0 -L/lib/lapack -llapack -o
And make sure lapack.mod is really in /lib/lapack which is probably C:\cygwin\lib\lapack on Cygwin.
Is there a way to get Eclipse (Indigo) to know about the built-in variables and functions that are available to CUDA kernels?
Consider the following simple kernel
__global__ void myKernel()
{
int x = threadIdx.x;
__syncthreads();
}
The Eclipse IDE highlights "threadIdx" and "__syncthreads" with a "Symbol 'the built-in symbol' could not be resolved" error message. Is there a way to tell Eclipse these are actually implicitly defined?
flipchart is correct. #include <cuda_runtime_api.h> does the trick if the symbol __CUDACC__ is defined beforehand.
In cuda 11.3 you can add:
#include <device_launch_parameters.h>