I’m trying to develop some plotting apps for Windows platform. I’m using Debian and built wxWidgets for cross-compiling as described here.
With MinGW compiler it works perfect and I have no problem with creating Win32 apps under Linux. But I faced some troubles with wxFreeChart.
I run ./configure --host=i386-mingw32 --with-wx-config=/usr/local/i586-mingw32/bin/wx-config
Then I run 'make' and getting error about
unrecognized command line option ‘-mthreads
Full output here:
~/dev/freechart/bk-deps g++ -c -o wxfreechart_lib_legend.o -I./include -I/usr/local/i586-mingw32/lib/wx/include/i586-mingw32msvc-msw-unicode-static-3.0 -I/usr/local/i586-mingw32/include/wx-3.0 -D_LARGEFILE_SOURCE=unknown -D__WXMSW__ -mthreads -O2 ./src/legend.cpp
g++: error: unrecognized command line option ‘-mthreads’
make: *** [wxfreechart_lib_legend.o] Error 1
The only advice I've seen was to remove '-mthreads' from code, but I have no idea where is it(
Problem described above is solved, but still no luck with building wxFreeChart.
Next errors I get were about some additional libs, which I finally solved by
CPPFLAGS="-I/usr/i586-mingw32msvc/include -I~/dev/wxWidgets-3.0.2/include" ./configure --host=i386-mingw32 --with-wx-config=/usr/local/i586-mingw32/bin/wx-config
I'm not sure that including .h from source folder ~/dev/wxWidgets is a good idea, but at least it solved some problems.
Now make crashing with messages like:
In file included from /usr/local/i586-mingw32/include/wx-3.0/wx/wx.h:17:0,
from ./include/wx/wxfreechartdefs.h:20,
from ./include/wx/legend.h:13,
from ./src/legend.cpp:10:
/usr/local/i586-mingw32/include/wx-3.0/wx/list.h: In constructor ‘wxListKey::wxListKey(const wxString&)’:
/usr/local/i586-mingw32/include/wx-3.0/wx/list.h:381:40: error: invalid use of incomplete type ‘class wxString’
or
/usr/local/i586-mingw32/include/wx-3.0/wx/containr.h:247:13: error: incomplete type ‘wxNavigationEnabled<wxControl>::BaseWindowClass {aka wxControl}’ used in nested name specifier
make: *** [wxfreechart_lib_legend.o] Error 1
Related
I am trying to compile grpc_python_plugin. I downloaded the latest grpc package in Github. Following the instruction, I went into the grpc directory, and start to compile with
make grpc_python_plugin
, and get the following error:
wcf#wcf-OptiPlex-7060:~/resq/grpc$ make grpc_python_plugin
[C] Compiling third_party/address_sorting/address_sorting.c
cc1: error: command line option ‘-std=c++11’ is valid for C++/ObjC++ but not for C [-Werror]
cc1: all warnings being treated as errors
Makefile:2972: recipe for target '/home/wcf/resq/grpc/objs/opt/third_party/address_sorting/address_sorting.o' failed
make: *** [/home/wcf/resq/grpc/objs/opt/third_party/address_sorting/address_sorting.o] Error 1
Since the Makefile for grpc is so giant, I cannot find any way to solve the problem. Could you share some idea on my problem? Thank you for your time.
The problem may be that I install the protobuf outside the grpc git program. When I install protobuf in grpc's third_party. All things go well.
The way I made it work was deleting "-Werror" from CPPFLAGS in the Makefile. But yes, I also installed protobuf outside of grpc.
I've been trying unsuccessfully for a week to get a build of Assimp that is linkable with a project I'm compiling with MinGW.
It seems that the makefiles that cmake generates to build Assimp 4.1.0 are flawed somehow because when I try to use them I get some warnings which ultimately lead to a failure when trying to link "libassimp.dll"
CMakeFiles\assimp.dir/objects.a(Exporter.cpp.obj):Exporter.cpp:(.text+0x1571): undefined reference to `Assimp::ExportScene3MF(char const*, Assimp::IOSystem*, aiScene const*, Assimp::ExportProperties const*)'
collect2.exe: error: ld returned 1 exit status
code\CMakeFiles\assimp.dir\build.make:3159: recipe for target 'code/libassimp.dll' failed
mingw32-make[2]: *** [code/libassimp.dll] Error 1
CMakeFiles\Makefile2:289: recipe for target 'code/CMakeFiles/assimp.dir/all' failed
mingw32-make[1]: *** [code/CMakeFiles/assimp.dir/all] Error 2
Makefile:131: recipe for target 'all' failed
mingw32-make: *** [all] Error 2
Before it gets to this the only error it seems is a format error in certain header files which use the %llu conversion type when referencing the ai_snprintf function.
warning: unknown conversion type character 'l' in format [-Wformat=]
warning: too many arguments for format [-Wformat-extra-args]
I'm using the latest MinGW which has g++ version 6.3.0, by default using the c++14 standard. I did a test to see if this standard on windows didn't support %llu but when I wrote a CMakeLists.txt file, generated a makefile, and compiled using the makefile, it gave no errors and ran as expected.
I've tried using cmake to generate a Visual Studio 2017 project and building it there and it links fine when used in Visual Studio. If I call the same functions and compile with MinGW it doesn't link, I guess this is just an interoperability problem, but it suggests I have everything assimp needs to be built properly.
My thoughts are, somehow assimp's cmake modules are defining what standard assimp should be compiled with, and that standard doesn't support %llu, but that sounds silly. I don't like to assume something is a bug but these warnings don't seem like they're thrown because I forgot to do something.
I've tried editing the makefile it gives me and adding to the front:
CXX = g++
CXXFLAGS = -Wall -std=c++11 $(DEBUG)
Cause somewhere it said that could work, but it didn't change anything.
I also tried defining the macro __USE_MINGW_ANSI_STDIO 1 for cmake but that didn't do anything either.
But I really don't know much about building binaries (though I've learned more than I expected to recently), so any advice, information, guidance is appreciated.
I'm triing to compile the superoptimizer on windows. (https://github.com/bonzini/superopt)
Unfortunatly my knowledge of make is very limited. I tried:
make CPU=-D386 superopt
Which gives me the error:
cc superopt.c -o superopt
process_begin: CreateProcess(NULL, cc superopt.c -o superopt, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [superopt] Fehler 2
After setting the compiler to gcc manually with:
make CPU=-D386 superopt CC=gcc
I get the following error:
gcc superopt.c -o superopt
In file included from superopt.c:27:0:
superopt.h:104:2: error: #error You have to choose target CPU type (--with-arch).
#error You have to choose target CPU type (--with-arch).
^
In file included from superopt.h:130:0,
from superopt.c:27:
longlong.h:1465:14: error: unknown type name 'UQItype'
extern const UQItype __clz_tab[];
^
superopt.c:32:21: fatal error: version.h: No such file or directory
compilation terminated.
make: *** [superopt] Fehler 1
It seems it does't properly selects i386.
Any hints would be greatly appreciated.
That is not the source code of
GNU superopt. It is the source code of someone's project
to patch GNU superopt, last updated 2008, and seemingly
abandoned a hard-hat area.
This is the source code of
GNU superopt. Extract the tarball and build as you have attempted
with:
make CC=gcc CPU=-DI386 superopt
Note: I386, not 386.
You will see warnings like:
warning: incompatible implicit declaration of built-in function 'foo'
because the 20 yearold C code does not diligently include the standard
headers that prototype the standard functions that it calls, but superopt will build successfully.
I want to compile opentracker(https://erdgeist.org/arts/software/opentracker) on my machine osx 10.9. when run "make" command I get this error:
cc -c -o opentracker.o -I../libowfat -Wall -pipe -Wextra -O3 -DWANT_FULLSCRAPE
opentracker.c
opentracker.c:25:10: fatal error: 'io.h' file not found
#include "io.h"
^
1 error generated.
make: *** [opentracker.o] Error 1
what is the problem? Is there any way to install io.h through homebrew?
You may have sorted this out already but i'll put this here for anyone else who has the same problem.
The "-I../libowfat" tells the compiler to include that path in the search path for header files. io.h is part of libowfat which you need to compile opentracker.
You can get libowfat here http://www.fefe.de/libowfat/
Unpack it and place it one directory up from where you are compiling opentracker. Alternatively you can change the -I to point to where you have libowfat unpacked.
I'm trying to create a project as a shared library in OS X using CMake 2.8 and gcc 4.6 (from macports). When CMake gets to the point of linking my library into a .dylib, I get the following error from gcc:
g++ -dynamiclib -headerpad_max_install_names -o libmycoollibrary.dylib etc...
g++: error: unrecognized option '-h'
make[2]: *** [libnrtCore.dylib] Error 1
make[1]: *** [CMakeFiles/nrtCore.dir/all] Error 2
make: *** [all] Error 2
This -headerpad_max_install_names seems to be the problem, but I've never seen it before. Does anyone know how to either get CMake to not include this option, or to get GCC to accept this option?
You can re-build cmake to fix this -- it's apparently generating code for the XCode / Darwin version of g++ (a special version of 4.2), which accepts a number of non-standard linker flags.
Just change the Modules/Platform/Darwin*.cmake files and re-build. The culprit lines look like this:
SET(CMAKE_CXX_LINK_FLAGS "-Wl,-search_paths_first -headerpad_max_install_names")