I am using Rstudio to create a package, and exploring the use of the Rcpp package to gain access to C++ code, however, when trying to build the package, and error is being thrown as follows:
fatal error: Rcpp.h: No such file or directory
Inline C++ code compiles fine, its only when considering standalone C++ files in the src folder, obviously referring to the #include <Rcpp.h> directive at the head of the .cpp file.
I think it may have something to do with environment variables, does anyone know what the correct configuration is and how to fix for Rstudio operating in an Ubuntu 12.04 LTS environment?
The commands sourceCpp('./src/xyz.cpp') execute as to be expected, the error is being thrown when Build and Reload is executed from within the RStudio IDE.
It is hard to say without having the package available. I guess you miss:
LinkingTo: Rcpp
in your DESCRIPTION file.
Did you by chance start with 'Create a package' in RStudio? If so, are you aware that you may have missed its sibbling option 'Create a package w/ Rcpp' ?
See the page on Using Rcpp with RStudio site for details, and particularly the final section on package building.
Also note that we wrote an entire vignette on using Rcpp with your own packages so I suggest you have a look at that too.
I encountered this same symptom (Rcpp.h: No such file or directory) when trying to install the "xml2" package on an Ubuntu 14 system. In my case the root cause appeared to be a bad installation of package "Rcpp". Some of the files were there (Rcpp/libs) but others were not (Rcpp/include). I am not sure how the system got into this state but I suspect an installation of that package terminated part way through. Re-installing package "Rcpp" cleared up the issue for me.
This is because your GCC has been updated, and it is different than the one you had when you installed R. I had the same problem.
I removed the package "Rccp" by using:
remove.packages("Rcpp")
Then you need to install it again. Just run:
source("https://bioconductor.org/biocLite.R")
biocLite("Rcpp")
Related
While helping my friend spin up MinGW and a C++ environment on his Windows 8 computer, I ran the get-mingw script and waited as it ran through all the mirrors for required downloads. However, three downloads completely failed:
libltdl - installer script hung and then moved on after pressing "OK"
automake-1.11 - installer script tried finding 1.10, then 1.9, then 1.8, then 1.7 (all of which failed) until finally settling on 1.6
mktemp - script hung and moved on after pressing "OK"
In all three cases, the script gave me a nice error log upon completion, showing that a majority of packages had been downloaded and installed except for these three, which showed up as errors. However during the installation process I had simply gone to the MinGW sourceforge page and manually found and downloaded each .bin.tar.lzma file that was missing.
Now that I have them, is there a good accepted way to unpack and plug them into my friend's existing MinGW install? In case it's tough, I'm comfortable with unix and dos command line so I'll be able to move executables into the MinGW/bin folder if that's what's needed, I just want to check for the best way to 'fix' the install.
As a side note - even though the error log says these are required packages, adding MinGW/bin/ to the PATH still allows for use of gcc and g++, although not make (possibly because of automake failure?). Is this standard behavior?
Firstly, the package issue can be fixed by using the MinGW installer - keep the packages selected and go to "apply changes" and the script will probably try to redownload the missing packages. I think the original problem was probably just a shoddy wifi connection during repository connection.
However, I then ran into a problem where I tried to run gcc and it gave me a missing -lpthread error ... but this question was able to help me fix that, and gcc and g++ are working fine now (haven't opened and tested Eclipse yet though). Just in case of link decay, the issue I cited arises from the MinGW installer script not downloading the lpthread library upon installation. To fix that issue, quoted from link:
Just run and open MinGW Installation Manager, which should be pre-installed with MinGW, select "All Packages" on the left panel, and on the right panel, search for "mingw32-pthreads-w32" packages and install them.
I think the Installation Manager has libpthread and pthread available for install, and pthread libs were the ones that seemed to solve it for me.
I am trying to build syntaxnet using bazel without root rights. I have downloaded bazel 0.2.2b and pulled the syntaxnet git repository as suggested on its website. I have managed to pass the new gcc for the bazel build and set my environment variables to include the local gcc as well as my local python version (2.7). I also added swig and jdk to PATH. Still, I get the following error when trying to run bazel test syntaxnet/... util/utf8/...:
INFO: Found 65 targets and 12 test targets...
ERROR: /home/davba/.cache/bazel/_bazel_debauscd/33ff1ccf943e8d1167bc44c81c9ea8f4/external/org_tensorflow/tensorflow/python/BUILD:1023:1: output 'external/org_tensorflow/tensorflow/python/pywrap_tensorflow.cc' was not created.
ERROR: /home/davba/.cache/bazel/_bazel_debauscd/33ff1ccf943e8d1167bc44c81c9ea8f4/external/org_tensorflow/tensorflow/python/BUILD:1023:1: output 'external/org_tensorflow/tensorflow/python/pywrap_tensorflow.py' was not created.
ERROR: /home/davba/.cache/bazel/_bazel_debauscd/33ff1ccf943e8d1167bc44c81c9ea8f4/external/org_tensorflow/tensorflow/python/BUILD:1023:1: not all outputs were created.
After that, none of the tests are run which means all twelve tests are skipped. Any ideas are highly appreciated.
Edit: I have realized that I used an old version of protobuf. Unfortunately, the problem remains even after updating.
Since it seems to be a python related problem and I had built python from source, I tried to use anaconda but ended up with the same error.
Some more information: I am using CentOS 6.5 and tried python 2.7.11.
I set the environment variables as follows and changed the CROSSTOOL file for building bazel accordingly:
CXX=/soft/csw/linux64/rel6/gccs-4.8.5/bin/c++
CC=/soft/csw/linux64/rel6/gccs-4.8.5/bin/gcc
LDFLAGS="-L/soft/csw/linux64/rel6/gccs-4.8.5/lib -L/soft/csw/linux64/rel6/gccs-4.8.5/lib64":"-L/home/davba/syntaxnet-utils/pcre/lib"
CXXFLAGS="-L/soft/csw/linux64/rel6/gccs-4.8.5/lib -L/soft/csw/linux64/rel6/gccs-4.8.5/lib64"
LD_LIBRARY_PATH=/soft/csw/linux64/rel6/gccs-4.8.5/lib:/soft/csw/linux64/rel6/gccs-4.8.5/lib64:/home/davba/AnacondaPython/lib:$LD_LIBRARY_PATH
SWIG_PATH=/home/davba/syntaxnet-utils/compiled-swig/bin
Thanks!
I tried running it on a different machine with CentOS 7.0, but wound up with the same error.
Finally, I had the opportunity to switch to an Ubuntu machine with sudo rights which enabled me to run the bazel installer and compile syntaxnet without a problem. This solves the problem in my case. For a "real" fix I think we have to wait for someone experiencing the same issue.
As title,
Build successful, but the exe can't run. can not found msvcr100.dll.
I can put msvcr100.dll with exe in the same dir, the exe can run.
But I just want only one exe file.
Anyone know how to do?
Has solved. This is a bug of pyinstaller3.2, the new in the git has solved this bug. Down the newest source in the github, erverything works fine.
Has solved. This is a bug of pyinstaller3.2, the new one in the git has solved this bug. Down the newest source in the GitHub, everything works fine.
This is correct, I cant tell you how much that answer helped me out. I have been trying to build a single exe Exploit to execute on Windows XP with-out it crashing for my OSCP Labs/Exam. I followed so many tutorials and nothing seems to work. I was able to build the EXE but could not get it to run under a single EXE.
If anyone who reads this is getting "This Program cannot be run in DOS mode" try running it from another machine with the same build (Windows XP). There is not much info out there on how to solve that from a Reverse Shell on a End Of Life Operating System using an EXE exploit built with Pyinstaller. (Lots of Trial and Error and determination)
Microsoft Visual C++ 2008 Redistributable Package (or some other version depending on python version) is needed in any case, python27.dll requires it
I was also receiving an error about msvcr100.dll when ran from the GUI on my build machine(WinXP SP2). This is corrected in the 3.3 Dev version on GitHub.
I installed the C++ 2008 Package but this didn't solve my problem when I re-built the EXE, the 3.3 Dev Pyinstaller was the solution.
What I did was:
Zip down the Dev version of Pyinstaller 3.3 Dev(GitHub) is the newest for 11/14/16 that I could tell. Make sure you have Python 2.7.x (I used 2.7.11) and pywin32 installed that matches (Python 2.7.x) version. (And it does matter if its 64-bit or 32-bit) Use the setup.py to install Pyinstaller, make sure you do not have a previous version already installed, if so use pip or etc. to remove. I installed with pip first and this was my whole issue.
I was able to get all of my 32-bit Single EXE Exploits to run on 64-bit/32-bit Windows machines up to Windows 10.
Once that is completed, make sure Pyinstaller is in your $PATH and follow the standard tutorials on creating a --onefile EXE. Copy to your Windows Target machine and it should work with-out error. I did not need to pull any dependencies over but you may have to include some with the --hidden command. Its greatly detailed in the Pyinstaller documentation on how to include hidden .dlls
If this still doesn't work for you try using py2exe. Its a little more complicated but it your determined you will figure it out.
If you have code written in python 2.x.x and 3.x.x you can have multiple environments of Python and have Pyinstaller installed in each. This is in the documentation as well.
Thank you jim ying. Your 2 sentence answer was exactly what I needed.
Firstly, I know nothing about C/C++, but I am trying to compile LCI https://github.com/justinmeza/lci under Windows 10 with Visual Studio 2015, but I'm getting the following error:
Cannot open include file: 'getopt.h': No such file or directory.
I see that getopt is not part of Visual C so people are saying you have to implement your own. It looks like this is what I need:
https://github.com/skandhurkat/Getopt-for-Visual-Studio/blob/master/getopt.h
Problem is, I don't really know what to do with this file. I've been reading a fair bit and messing around for ages just to compile lci.exe!
Already emailed the OP about this, but here's the steps I followed in order to build lci successfully. The missing step seemed to be that Justin Meza neglected to mention that you need to install CMake as well in order for the install script to work. CMake will allow you to build C code against the glibc headers.
Install MinGW
Install Python 3.5.1 (or latest Windows version)
Install Git for Windows (if you haven't already)
Make sure to enable Git for the Windows command prompt
Install CMake
Add MinGW and Python to your PATH environment variable. I'd double check that your paths to the executables are correct, mine looked like this:
C:\Program Files\mingw-w64\mingw64\bin
C:\Users{username}\AppData\Local\Programs\Python\Python35-32
Run a command prompt as administrator, and go to your Documents folder and clone the lci repository (if you haven't already):
git clone https://github.com/justinmeza/lci.git
Go into the lci directory, and run:
install.py --prefix="C:/Program Files/lci"
Add lci to you PATH, if using the default location add this to the end of your PATH:
C:\Program Files\lci\bin
I would have included some links to the various programs above in steps 1-4 but apparently I don't have enough reputation on StackOverflow for that...you should be able to find them easily enough in a quick Google search.
You should now be able to run lci from any command prompt. A good test would be to run the "HAI WORLD" code at lolcode.org.
Just copy getopt.h to the directory where .c files are, so the compiler can find it.
Based on the linked source code and it's contents, the project you're trying to build appears to be written for Linux. It might be possible to sufficiently rewrite it to be able to compile under Microsoft Windows, and Microsoft's compiler; or perhaps install something like MinGW.
However, given your stated lack of development experience, this does not appear to be something that you could easily handle on your own.
I was trying to install RandomWords which requires ujson, at some point in the installation I received the following notification: "error: Unable to find vcvarsall.bat" I searched here, on stackoverflow, and came across some answers as the to root of this problem. In this answer https://stackoverflow.com/a/8705722, near the end, the OP pointed out that Microsoft had released a C++ compiler package for Python 2.7 (http://www.microsoft.com/en-us/download/details.aspx?id=44266).
I installed this package but still haven't had any success in installing ujson. So far I've tried the following:
Adding the location of vcvarsall.bat to the path environment variable
Manually tried loading the VC++ compiler's environment into the session by executing vcvars64.bat (aI've tried vcvars32.bat as well) as recommended here: https://stackoverflow.com/a/18045219
I've also tried installing the compilers found in "Windows SDK for Windows 7 and .NET Framework 3.5 SP1" found here: http://www.microsoft.com/en-us/download/details.aspx?id=3138
Not sure where to go from here, any suggestions/help would be greatly appreciated.
For reference here's some relevant specs:
Windows 8.1 (64-bit)
Python 2.7 (64-bit)
I've been trying to install said package using pip from the command prompt (e.g. '> pip install ujson')
I've uninstalled all the C++ compiler packages I've tried except this one: http://www.microsoft.com/en-us/download/details.aspx?id=44266
Really don't feel like installing mingw, but I'll try it if it seems like it's the only solution.
-UPDATE-
I ended up modifying "msvc9compiler.py" and manually setting the location of vcvarsall.bat by setting the value of the vcvarsall variable to the location of that batch file. Everything compiled fine but this is not a recommended solution. I'm pretty sure the compiler version I have matches the one python 2.7 uses, but as mentioned in an answer, in another question on this topic, if these don't match it can cause problems since "the compilers will probably have incompatible C runtime libraries."