I’m trying to install the Nsis on Linux,
I found a great guide to install from: http://www.xdevsoftware.com/blog/post/How-to-Install-the-Nullsoft-Installer---NSIS-on-Linux-.aspx
The problem is that its failing in the final step:
scons SKIPSTUBS=all SKIPPLUGINS=all SKIPUTILS=all SKIPMISC=all NSIS_CONFIG_CONST_DATA=no PREFIX=/usr/local/nsis/nsis-2.46 install-compiler
this is the output that i get:
Source/script.cpp:6460:1: required from here
Source/util.h:145:1: error: 'close' was not declared in this scope,
and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive]
The error is : ‘close’ was not declared in this scope….
I tried to run it a few times, and look up solution in the internet but I think there is a problem with that this a 64bit machine and not 32.
any idea?
Try adding #include <unistd.h> to util.h
There is a recent bug report about close() but that is on OSX and related to compiler/c++ library changes so I'm not sure if it applies but it might be worth looking into...
Related
So I am trying to compile this flip fluids addon with blender, so I followed this tutorial, https://www.youtube.com/watch?v=TVKM1egDoGs , So I first ran cmake.exe -G "MinGW Makefiles" .. and it was telling me that it was missing a CMakeLists File... So I added one... then I ran cmake.exe --build . and it got to 3 percent than showed me errors like ...
In file included from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/threadutils.h:29,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshlevelset.h:65,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshobject.h:30,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/fluidsimulation.h:38,
from C:\Users\N\Downloads\Blender-FLIP-Fluids-master\src\engine\c_bindings\fluidsimulation_c.cpp:25:
C:/PROGRA~2/MINGW-~1/I686-8~1.0-P/mingw32/lib/gcc/i686-w64-mingw32/8.1.0/include/c++/mutex:93:9: note: previous definition of 'class std::recursive_mutex'
class recursive_mutex : private __recursive_mutex_base
^~~~~~~~~~~~~~~
In file included from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.condition_variable.h:25,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/threadutils.h:31,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshlevelset.h:65,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/meshobject.h:30,
from C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/fluidsimulation.h:38,
from C:\Users\N\Downloads\Blender-FLIP-Fluids-master\src\engine\c_bindings\fluidsimulation_c.cpp:25:
C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.mutex.h:142:44: error: conflicting declaration 'typedef class std::_NonRecursive<std::recursive_mutex> std::mutex'
This is the full error https://pastebin.com/KTnALG1E, where is this coming from?? is it a mingw error or what? Can someone help please?
Your full error message includes a more interesting bit:
C:/Users/N/Downloads/Blender-FLIP-Fluids-master/src/engine/mingw32_threads/mingw.thread.h:32:2:
error: #error This version of MinGW seems to include a win32 port of
pthreads, and probably already has C++11 std threading classes
implemented, based on pthreads. It is likely that you will get class
redefinition errors below, and unfortunately this implementation can
not be used standalone and independent of the system header,
since it relies on it for std::unique_lock and other utility classes.
If you would still like to use this implementation (as it is more
lightweight), you have to edit the c++-config.h system header of your
MinGW to not define _GLIBCXX_HAS_GTHREADS. This will prevent system
headers from defining actual threading classes while still defining
the necessary utility classes.
So either install a different version of mingw or edit your mingw files according to the instructions above.
I am running a fresh install of Linux Mint 20.1 and I'n trying to compile a program for a GPS tracker, but it won't compile:
In file included from /usr/include/c++/9/bits/stl_algo.h:59,
from /usr/include/c++/9/algorithm:62,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/qglobal.h:142,
from /usr/include/x86_64-linux-gnu/qt5/QtCore/QtCore:4,
from pch.h:27:
/usr/include/c++/9/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
75 | #include_next <stdlib.h>
| ^~~~~~~~~~
compilation terminated.
I have installed a number of additional libraries (libusb, libmarble and a few others) and qmake.
Of course, stdlib.h is present on the system:
$ find /usr -name stdlib.h
/usr/include/x86_64-linux-gnu/bits/stdlib.h
/usr/include/bsd/stdlib.h
/usr/include/stdlib.h
/usr/include/c++/9/tr1/stdlib.h
/usr/include/c++/9/stdlib.h
/usr/include/tcl8.6/tcl-private/compat/stdlib.h
After looking at the other questions about this, I re-installed build-essential, which didn't help.
I re-installed the g++ compiler, no luck either.
I copied /usr/include/c++/9/stdlib.h to /usr/local/include, but it still complains about a missing stdlib.h
I changed the
#include_next <stdlib.h>
in cstdlib into
#include <stdlib.h>
only to find that the next include cannot find stdlib.h; changing that one produced the third include and so on. So that does not work either.
The program compiles and works on Slackware 14.2 by the way.
What am I missing?
Hello-world compiles normally; a simple program that does a malloc also compiles and runs.
I used to #anastaciu 's solution.
As it was a fresh install without much customization, I resorted to the option of a complete re-install. Bizarre that that works a bit, as it was already a fresh install. I still had to copy stdlib.h and a few others (math.h etc.) to /usr/local/lib` to get to the point where it would at least compile.
I am trying to set up openFrameworks with QT, but it seems that i had no success so far. I included all the necessary files i.e. includes, libs etc, but as soon as i compile the program it's showing an error
/home/kalyan/of_v0.9.3_linux64_release/libs/openFrameworks/utils/ofXml.h:204: error: 'class Poco::XML::Element' has no member named 'getNodeByPath'
Poco::XML::Element *e = (Poco::XML::Element*) element->getNodeByPath(path);
^
I even asked in openFrameworks forum, but haven't got any reply.
I am running an example "3dPrimitivesExample" that has been included in openFrameworks build. I built that particular example using make, it generated object files and finally generated an .exe file.
Are you having the same problem I had last week? Old version?
See here:
'Keywords' is not a namespace-name
There is an excellent writeup on how to link QT to Poco using CMAKE in this link here (I never figured out how to do it using QMake):
Clion, cMake and POCO
I'm working on my coin at the moment, following the guide posted here:
http://devtome.com/doku.php?id=scrypt_altcoin_cloning_guide
I've used the same libraries, installed them correctly -- everything! However, I get the following error during compilation.
Commands used are:
qmake "USE_UPNP=-" syncoin-qt.pro
make -f Makefile.Release
c:\deps\boost/boost/system/error_code.hpp: At global scope:
c:\deps\boost/boost/system/error_code.hpp:222:36: warning: 'boost::system::posix
_category' defined but not used [-Wunused-variable]
c:\deps\boost/boost/system/error_code.hpp:223:36: warning: 'boost::system::errno
_ecat' defined but not used [-Wunused-variable]
c:\deps\boost/boost/system/error_code.hpp:224:36: warning: 'boost::system::nativ
e_ecat' defined but not used [-Wunused-variable]
mingw32-make: *** [build/bitcoin.o] Error 1
After reading on bitcoin forums, I found a post by shakezula that mentioned this was frequently a result of missing "__NO_SYSTEM_INCLUDES". However, that is included in my .pro file, which you can find here:
http://pastebin.com/4p4BMPAE
Thanks for your help.
I managed to fix this by downloading the CoinLab build environment; for those interested, the QT version was 4.8.4, with MinGW as the version bundled with GCC 4.6.2.
I'm right where you are when you posted this atm. Kinda stuck here as well... Are you using Qt 5.2? I think we may need to use 4.8.5 to get anything done.
First some background - I have three VS2010 C++/OpenCL projects that compile and run fine on Windows 7 64-bit. I've been trying to compile and run each of them on Linux 64-bit (Ubuntu/Debian). The first two are compiling and running on linux and don't really use any external libraries. The third uses only Boost 1.50.0 and isn't compiling using the same method as the first two. So first let me go through what I did to get the first two to work.
I extracted only the source from the myriad of folders.
I ported windows specific code to linux specific code.
I wrote a bash script to generate the g++ command with all sources to compile them.
I ran the compile script to generate an output target file.
The bash script is as follows.
#!/bin/bash
SOURCE=""
for i in `ls *.h *.cpp *.hpp`; do
SOURCE+="${i} "
done
COMMAND="g++ -I/home/junkie/downloads/boost_1_51_0 -o out ${SOURCE} -L/opt/AMDAPP/lib/x86_64/ -I/opt/AMDAPP/include -lOpenCL -fpermissive"
echo -e "\n"
echo -e "${COMMAND}"
echo -e "\n"
$COMMAND
exit $?
And it generates and runs a command similar to following.
g++ -I/home/junkie/downloads/boost_1_51_0 -o out blah.cpp blah.h foo.hpp baz.cpp etc.cpp -L/opt/AMDAPP/lib/x86_64/ -I/opt/AMDAPP/include -lOpenCL -fpermissive
I compile using the following command.
./compile.sh &> log; echo $?; grep -ci error log; wc -l log
Now you may be wondering why I've adopted such unconventional and redundant means of getting a C++ project to compile and run on linux. Well because I'm new to the linux c and c++ toolchain and this was the quickest and simplest route I could figure out to get the job done and it did get the first two projects up and running. However, the third uses boost and this method isn't working and I need your help in figuring out what all these strange errors are.
The errors I'm getting are not actually from the project code but instead from Boost and AMD's opencl libraries code which is strange because the other projects were using opencl too and those worked fine.
Some examples of boost errors are below.
foo.hpp:2331:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
In file included from main.cpp:4:
foo2.hpp:1610:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: variable or field ‘BOOST_PP_CAT_I’ declared void /home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp: At global scope:
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: variable or field ‘BOOST_PP_CAT_I’ declared void
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘;’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘;’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected unqualified-id at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
/home/junkie/downloads/boost_1_51_0/boost/preprocessor/cat.hpp:22: error: expected ‘}’ at end of input
foo.hpp:2331:1: error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
Some examples of opencl errors are below.
In file included from /opt/AMDAPP/include/CL/cl_platform.h:35,
from /opt/AMDAPP/include/CL/cl.h:30,
from bar.h:7,
from fooGPU.hpp:6,
from main.cpp:4:
/usr/include/stdint.h:49: error: expected ‘;’ before ‘typedef’
In file included from /opt/AMDAPP/include/CL/cl.h:30,
from bar.h:7,
from fooGPU.hpp:6,
from main.cpp:4:
/opt/AMDAPP/include/CL/cl_platform.h:41: error: expected unqualified-id before string constant
main.cpp:136: error: expected ‘}’ at end of input
main.cpp:136: error: expected unqualified-id at end of input
main.cpp:136: error: expected ‘}’ at end of input
main.cpp:136: error: expected ‘}’ at end of input
The boost includes I'm Using are as follows.
#include <boost/preprocessor/punctuation/paren.hpp>
#include <boost/preprocessor/punctuation/comma.hpp>
#include <boost/static_assert.hpp>
#include <boost/type_traits/is_same.hpp>
#include <boost/type_traits/is_base_of.hpp>
#include <boost/mpl/not.hpp>
#include <boost/mpl/int.hpp>
#include <boost/mpl/logical.hpp>
#include <boost/mpl/eval_if.hpp>
#include <boost/mpl/identity.hpp>
#include <boost/shared_ptr.hpp>
#include <boost/array.hpp>
So, finally, my questions are as follows.
1) What is the root cause of these errors in light of the building method I'm using and how do I resolve this problem? Does order of files or library inclusion matter? I'm using a local source download of boost as part of my g++ command as instructed by boost documentation rather than prebuilt binaries as I'm not using anything that requires prebuilt binaries.
2) I realise that my way of building things is pretty primitive. I'm learning make and I've seen some recommendations to use cmake and kdevelop which I need to look into. The primary problem with using make is that these projects weren't written with make in mind so I'm not aware of the dependency graph between source files to create the makefile (if I'm thinking correctly; I'm still fairly new to it). If you have any recommendations of how to do things better please do enlighten me.
Thanks.
I finally managed to overcome this problem and here I provide a brief account of how. To be clear I don't know what the root cause of the original problem was. In other words - I don't know why the problem occurred. All I'm saying is that my workaround allowed me to resolve the issue and move onto other problems (compile time errors).
Essentially, to reiterate, the problem was that for whatever reason a project using boost wasn't compiling on Linux because all instances of the use of the BOOST_PP_CAT() function produced the following error.
error: unterminated argument list invoking macro "BOOST_PP_CAT_I"
For whatever reason the compiler wasn't able to correctly process the use of this function but was able to process the use of other boost functions such as BOOST_PP_LPAREN(), BOOST_PP_RPAREN() and BOOST_PP_COMMA. The problem looked almost certainly related to the preprocessing stage where the combined use of the aforementioned boost functions was resulting in an unterminated argument list.
To elaborate on the nature of the relevant code (which was not written by me thankfully) the prior developers had essentially used boost preprocessor functions to create a DSL that they could then re-use multiple times to generate a list of functions. It would have seemed a lot easier to me to simply write the functions directly but anyway that's another concern.
My work around was to change the relevant section of code so that it didn't use any BOOST_PP_CAT() functions but ultimately defined the exact same functions as before. I did this by substituting the use of BOOST_PP_CAT() with the code that was being generated by it. This overcame all instances of the error quoted above but left me with hundreds of other compile time errors in my efforts to migrate this project from windows to linux.
Although this was a very specific and unusual question with an equally specific and unusual answer I wanted to feed this back to dispel the mystery behind this problem. As to why this particular function was failing to preprocess/compile on linux but passing on Windows I don't know but would very much like to know. I can only assume it is a fundamental difference in the way VC++ performs preprocessing as opposed to g++ and clang or more specifically perhaps a difference in the order of resolution of nested functions in preprocessor directives. Who knows. Anyway, thanks for your help guys.
The unterminated argument list invoking macro error suggests a lacking closing parenthesis. Use your editor's parenthesis matcher to check it. Be sure that your source files are in Unix format, not in DOS format (e.g. with \n à la Unix, not with\r\n à la MSDOS, at each end-of-line). Use dos2unix if needed.
Otherwise, don't forget that you can run g++ -Wall -C -E -H -I/home/junkie/downloads/boost_1_51_0 yoursourcecode.cc to get the preprocessed form of yoursourcecode.cc, and, by redirecting that command, you can inspect that preprocessed form with the editor of your choice (like emacs).
As I commented, learn to use Gnu make (and if in trouble debugging your Makefile, which you should edit with a good editor like emacs, use remake -x to debug it).
And the -I/home/junkie/downloads/boost_1_51_0 looks very suspicious: even if Boost is often a header only library, it has, as far as I remember, an installation procedure on Unix (and Linux distributions often package Boost libs). You should install your Boost libraries as documented (and after having configured them), and likewise for OpenCL.