I have a cross-platform project that uses the boostless version of Asio. On OSX I use autotools to build the library then include it on my project:
exec_program(COMMAND "./autogen.sh" WORKING_DIRECTORY ${asio_SOURCE_DIR}/asio)
exec_program(COMMAND "./configure --without-boost" WORKING_DIRECTORY ${asio_SOURCE_DIR}/asio)
I could not find instructions for Windows and upon running CMake notices that Asio would generate a Visual Studio file so I fenced the instructions above on to be run on Unix platforms only.
But now I'm getting strange errors on Windows:
asio\include\generic\basic_endpoint.hpp(71): error c2039: 'protocol' is not a member of 'std::basic_string<chr, std::char_traits<<char>, std::allocation<char>>'
I also had an instance of asio::local::stream_protocol::endpoint that I had to change to asio::generic::stream_protocol::endpoint.
All of this code compiled and ran perfectly well on OSX.
Any idea what's going on?
Right, this was a dumb one. I'm compiling on Windows where Unix sockets don't exist.
Ah-to-the-duh.
Related
I'm going to teach students to use SFML with C++, and I'm afraid the school doesn't have visual studio C++ installed, or will be a bit heavy to use for those students.
I want to have a plan B and have the option of a simple makefile that I can build on windows with SFML.
https://www.sfml-dev.org/download/sfml/2.5.1/ this page offers binaries compiled with different, specific versions of mingw with their respective mingw package links, unfortunately mingw doesn't include an unix terminal, like the one included with git-bash, so I can run a makefile.
What are the steps required to have a problem unix terminal, running in windows, minsys, msys2 or not, that can work well with those mingw packages? I have trouble finding help or proper instructions.
You want https://www.msys2.org/
It provides bash terminal and already contains mingw compiler. Perhaps it even has SFML packages already.
I'm trying to run this code:
https://github.com/snukky/news-translit-nmt
I've installed boost and got the following messages:
The Boost C++ Libraries were successfully built!
The following directory should be added to compiler include paths:
C:\Program Files\boost\boost_1_67_0
The following directory should be added to linker library paths:
C:\Program Files\boost\boost_1_67_0\stage\lib
By the comment of #kenba I've added the following environment variables:
Try 1
When I try to run the following cmd:
cmake .. -DCMAKE_BUILD_TYPE=Release
I get:
-- Could NOT find Boost (missing: timer iostreams filesystem system chrono) (found version "1.67.0")
CMake Error at CMakeLists.txt:290 (message):
Cannot find Boost libraries. Terminating.
-- Could NOT find Doxygen (missing: DOXYGEN_EXECUTABLE)
-- Configuring incomplete, errors occurred!
See also "D:/ThesisResources/previous_works/news-translit-nmt-master/tools/marian-dev/build/CMakeFiles/CMakeOutput.log".
Try 2
When I try to give a custom boost by this ref
https://marian-nmt.github.io/docs/#custom-boost:
I run the following cmd:
cmake .. -DBOOST_ROOT="C:\Program Files\boost\boost_1_67_0"
I get the same error.
I've also tried working with Linux WSL (But problems with CUDA installation overthere, their team is working on it), Linux VirtualBox (Not enough resources), and Ubuntu 17.10 I have installed (But Cuda requires Ubuntu 16.04 / 18.04)
What am I missing here? I'm trying any suggestion, stuck on it for a few days. Thanks!
Edit:
I reinstalled Ubuntu 16.04 and the problem was solved. Still don't know how to solve it in windows, but i'll continue use Ubuntu 16.04.
I had this problem earlier while trying to build the Windows version of Marian NMT (the same component that you're having trouble with). I can't remember the exact steps to solve the problem, but the root cause is that the Marian NMT build for Windows does not work with newer versions of Boost, since the source code uses some deprecated calling conventions for timer and chrono libraries (maybe some others as well).
The error message kind of confirms this: it can't find Boost, but on the other hand it says it finds your version 1.67.0. The solution is to use an older version of boost, I've confirmed that it works with 1.60.0.
If you just require a Marian NMT decoder that works in Windows, a project I work on has released a plugin for the Trados Studio translation tool, which contains a compiled marian-decoder executable for Windows: https://object.pouta.csc.fi/fiskmo/TradosStudio/FiskmoTranslationProvider.sdlplugin. You can access the executable by unzipping the sdlplugin file, the StartMtPipe.bat shows how to use the decoder.
EDIT 1
This seems to be related to linking to the mono library, once I remove any kind of reference to mono code and remove the linking to the library from my CMakeList.txt file, debugging works as expected.
EDIT 2
Okay, I've discovered something interesting. This actually might not have anything to do with how I am linking libraries, it appears to be directly related to how I am initialising a class in my unit test. For whatever reason, if I use my normal syntax of TypeDeclaration variableName; the unit test fails immediately with the error code 0xc0000135, but if I change it to read TypeDeclaration variableName(); the code will run. Only problem is that I then get a warning stating empty parenthesis interpreted as a function declaration. I came from linux using g++ to compile my code and there was never an issue, now all of a sudden trying to compile on windows using cygwin or mingw means I can't use the normal standard c++ syntax to actually do work...
Edit 3
I've discovered that this issue is occurring because the libraries I am dependent on aren't actually being copied into the build directory of my unit test project. If I manually copy the required libraries into my build directory debugging works as expected, will need to learn how to express this requirement in CMakeList.txt
More Details
CLion Specifics
CLion 2018.3.1
Build #CL-183.4588.63, built on December 5, 2018
JRE: 1.8.0_152-release-1343-b16 amd64
JVM: OpenJDK 64-Bit Server VM by JetBrains s.r.o
Windows 10 10.0
Toolchain Settings
Cygwin 32 bit version 2.11.2
CMake version 3.13.1
Make version 4.2.1
gcc version 7.3.0
Debugger Cygwin GDB version 8.1.1
catch.hpp for unit testing.
Problem
When debugging a unit test, CLion reports the following error:
During startup program exited with code 0xc0000135.
Google returns a lot of Qt and netbeans related results, everyone suggests to add C:\mingw\bin to the system PATH variable. However I am not using mingw I am using cygwin. I tried adding C:\cygwin\bin to my PATH directory but that does not help. I also tried switching toolchain to use mingw to see if that would help. but the same problem occurs with debugging.
Not sure what else I can do to proceed in resolving this one, any ideas would be most welcome.
Has anybody successful cross compiled the Xalan C++ library for armv7/armv7s arch to be used on iOS device (not simulator)?
I was able to cross compile the xerces library by setting the iOS g++/gcc compilers for armv7 but using the same procedure for Xalan gives me below error while running the make file:
iComp:c iComp$ make
Linux, Solaris, AIX, Compaq Tru64, OS/390, MacOSX, HP-UX, NETBSD, FREEBSD, CYGWIN, and MINGW are the only platforms supported.
Above error clearly states that I cannot target the iOS platform.
So was there some problem in configuring the makefiles?
UPDATE
The above issue was occurring because of incorrect usage of Xalan's runConfigure file.
The correct usage to pass additional options to Configure file via runConfigure is to use '-C' option with "--host=arm-apple-darwin --disable-shared"
This has helped to resolve the above platform detection issue and generated the cross-compile make files.
PROBLEM
But now the issue is while running the make, default MsgLoader (inmeme)executable is generated (target: armv7) and after that the make file tries to run the armv7 executable on Mac OSX obviously giving the error 'Bad CpuType in executable'
How can I either avoid the building of Xalan by creating a armv7 exe of MsgLoader or run this armv7 exe in terminal (doesn't seems possible!) so that it proceeds with the build.
Thanks in advance for any help!!!
In order to use nzmqt on Qt5 (Windows) I downloaded and compiled ZeroMQ 3.2.5 as described on GitHub. My Qt5 application compiles fine but it doesn't run: it complains about the entry point of libstdc++-6.dll.
I guess it's due to the different version of MinGW used to compile ZeroMQ (the one included in the RubyDevKit) and my application.
Thus, I'm trying to compile ZeroMQ with the MinGW which comes with Qt5... Unfortunately it's not enough to run mingw32-make from the Qt5 folders because it doesn't accept the "fail" command in the Makefile:
$(RECURSIVE_TARGETS):
#fail= failcom='exit 1'; \
This is beyond my knowledge.
I'm wondering if anyone was able to use nzmqt with ZeroMQ 3.2.5 under Windows and Qt5.