After installing the MongoDB, on the server-side, I attempted to configure my client which, resides on a CentOS 5.6 OS using the C++ driver code, from the link below:
http://dl.mongodb.org/dl/cxx-driver/
The install went well ! I worked through the tutorials with no problems but, at this point, I need to build this in with my group's build process. When I attempt to compile, I receive the following error:
/usr/local/include/mongo/base/error_codes.h:36: error: expected identifier before numeric constant
/usr/local/include/mongo/base/error_codes.h:36: error: expected '}' before numeric constant
....
At this point, I said to myself there must be another #define that is colliding with this code. So, I ran the g++ ... -E command and found that, in /usr/include/X11/X.h, there is a #define BadValue.
This seems weird to me because I would not expect this to happen if the code was enclosed in some namespace which error_codes.h is enclosed in the mongo namespace. So, I searched my entire filesystem looking for something like using namespace mongo thinking that the global namespace was polluted but, this is not the case. I do not see any instances of this occurring and I am wondering - because both of these are third-party - how to resolve.
Thoughts?
Related
I'm trying to port a simple Go macOS application over to Kotlin Native. After struggling with various errors I decided to take a step back, and have a look at the official examples provided with Kotlin Native.
I found a basic OpenGL example here:
https://github.com/JetBrains/kotlin-native/tree/master/samples/opengl
But so far I haven't been able to get this to compile.
I tried downloading the complete sources for Kotlin, but that wont build. I followed a few suggestions generated at build time, including the change to 'ignoreXcodeVersionCheck' and downloading prebuilt binaries for the compiler, but at this point I'm wondering if this just isn't supported by my environment? I do understand that this is all experimental.
I've attached a sample of errors below, but I'm not sure whats relevant.
Question: Does anyone else have this setup / environment working please? can I expect to get it working?
macos 10.12.4, kotlin 1.3.11, xcode 8.2.1
.konan/dependencies/clang-llvm-6.0.1-darwin-macos/include/c++/v1/cmath:551:28: error: expected a qualified name after 'typename'
_LIBCPP_CONSTEXPR typename enable_if<is_floating_point<_A1>::value, bool>::type
.konan/dependencies/clang-llvm-6.0.1-darwin-macos/include/c++/v1/cstddef:44:15: fatal error: 'stddef.h' file not found
#include_next <stddef.h>
A problem occurred evaluating root project 'kotlin-native-master'.
expected Xcode version 10.1, got 8.2.1, consider updating Xcode or use "ignoreXcodeVersionCheck" variable in konan.properties
kotlin-native-master/runtime/src/main/cpp/ObjCExportErrors.mm:73:23: error: no type or protocol named 'NSErrorUserInfoKey'
NSMutableDictionary<NSErrorUserInfoKey, id>* userInfo = [[NSMutableDictionary new] autorelease];
.konan/dependencies/clang-llvm-6.0.1-darwin-macos/include/c++/v1/cmath:313:9: error: no member named 'signbit' in the global namespace
using ::signbit;
I did manage to get a "hello world" working under the above environment, but I have given up with the OpenGL stuff. I cant update my environment currently, and I guess this issue doesn't affect many people. So I'm going to close it with this 'answer'.
I have been trying to compile a basic tensorRT project on a desktop host -for now the source is literally just the following:
#include <nvinfer.h>
class Logger : nvinfer1::public ILogger
{
} glogger;
Upon running make, though, I receive the following message:
fatal error: nvinfer.h: No such file or directory #include <nvinfer.h>
The error is correct, too - I used locate to try to find it, but there's nothing on my machine that matches. I followed the install instructions for desktop installation of TensorRT 2.1 as described here: https://developer.nvidia.com/nvidia-tensorrt-download
So my question is, does anyone know where nvinfer.h is supposed to be? In other words, am I missing a needed package that contains it, or did I miss something else that's essential?
Small addendum: one thing I noticed is that libgie1 is not installed, and it was not included as a debian with the provided TensorRT download like the other packages such as gie-dev were.
Before using locate, if you recently added new files is a good practice to run sudo updatedb, if the file is on the pc you should see it after.
Anyway googling a bit it looks like the header your looking for is NvInfer.h, caps matters.
I have developed a ShinyApp that is built around a C++ program. In short, what the app does is :
provides a nice interface to setup the parameters (in a text file) for the C++ app
runs the C++ compiled code using the system(...) command
displays the output of the C++ code using ggplot2
The C++ compiled code is stored into the www folder. Locally it works fine, but when I load the app to the shinyapp website (I have a free subscription), I got the following error:
sh: 1: ./a.out: Permission denied
with a.out being my compile c++ code. Any idea if
I am doing something wrong?
It is possible call a compiled c++ code within shinyapp.io?
This is a super old question, but since I stumbled on it looking for an answer for my identical problem, I would share what worked for me.
I didn't try the .bat suggestion mentioned in the comments, because that seemed to be tied to Windows OS and Shiny uses Linux.
Instead, I used R's Sys.chmod() function. In your case, if you are calling system("a.out"), before that line, put Sys.chmod("a.out", mode="777"). Note that you may want to look more into what chmod does with regards to permissions. But the code would look like:
// ...
Sys.chmod("a.out", mode="777")
system("a.out")
// ... remaining code
My goal is to create a package in R with C++ code: So my questions is how?
I am following the tutorial http://www.stat.columbia.edu/~gelman/stuff_for_blog/AlanRPackageTutorial.pdf on creating an R package containing C++ code. The specific code Im trying to compile and package is exactly as described in the tutorial.
R CMD SHLIB seems to be working creating .dll file.
I can load in R using dyn.load() and test it on simulated data (as described in tutorial)
R CMD INSTALL is where the problem begins. I have done two things encountering two different errors supposedly related:
1) The tutorial says the NAMESPACE file is supposed to contain the code:
useDynLib(XDemo)
export(XDemoAutoC)
When it does R CMD INSTALL fail resulting in error:
Error in inDL(x,as.logical(local), as.logical(now),...): unable to
load shared object 'C:/.../libs/i386/XDemo.dll': Loadlibrary failure:
1% is not a valid Win32-program
2) Removing the above mentioned lines in NAMESPACE file will result in installation of package. I can succesfully load it in R but when I try to use the R function that makes a .C() call to the C++ written function I another error:
library(newpackage)
ls(package:newpackage)
[[1]] "XDemoAutoC"
Warning message:
In ls(package:newpackage) :
‘package:newpackage’ converted to character string
XDemoAutoC(c(1,2,3,4))
Error in .C("DemoAutoCor", OutVec = as.double(vector("numeric", OutLength)), :
C symbol name "DemoAutoCor" not in load table
Im running version R2.15.2 on windows 64-bit and using R64 bit.
I read the following post with a similar problem:
http://r.789695.n4.nabble.com/Include-C-DLL-error-in-C-symbol-name-not-in-load-table-td3464021.html
Except they mention nothing about the NAMESPACE-matter.
Also I read this post:
Problem with loading compiled c code in R x64 using dyn.load
So I am thinking: that based on the fact that I am able to use dyn.load() in Rx64 means that I have succesfully created x64 .dll. Assuming that the NAMESPACE file is supposed to be left as in the tutorial - hopefully fixing the >>not in load table<< error - this would mean I should focus on fixing problem one. This problem seems to be caused by something related to 32-bit. I have used Dependency Walker on the .dll file but I am not sure how to interpret the results
I really don't have any ideas on how to fix this problem so any suggestion on what to do would be welcome?
I think you are doing it wrong. Two quick suggestions:
Read the Writing R Extensions manual written to explain just this: writing R extensions including those with compiled code
Have a look at Rcpp which makes R and C++ extensions, including package building so much easier. Or so we think. Writing a package is as easy as calling Rcpp.package.skeleton(). The documentation in 1) still help.
That said, if R CMD INSTALL fails you may have some mixup in your $PATH. Never ever mix MinGW and Cygwin. Make sure no Cygwin DLLs are found when you build or call R. Path order matters greatly. See the manual for details.
I have a C++ application that I am porting to MacOSX (specifically, 10.6). The app makes heavy use of the C++ standard library and boost. I recently observed some breakage in the app that I'm having difficulty understanding.
Basically, the boost filesystem library throws a runtime exception when the program runs. With a bit of debugging and googling, I've reduced the offending call to the following minimal program:
#include <locale>
int main ( int argc, char *argv [] ) {
std::locale::global(std::locale(""));
return 0;
}
This program fails when I run this through g++ and execute the resulting program in an environment where LANG=en_US.UTF-8 is set (which on my computer is part of the default bash session when I create a new console window). Clearing the environment variable (setenv LANG=) allows the program to run without issues. But I'm surprised I'm seeing this breakage in the default configuration.
My questions are:
Is this expected behavior for this code on MacOS 10.6?
What would a proper workaround be? I can't really re-write the function because the version of the boost libraries we are using executes this statement internally as part of the filesystem library.
For completeness, I should point out that the program from which this code was synthesized crashes when launched via the 'open' command (or from the Finder) but not when Xcode runs the program in Debug mode.
edit The error given by the above code on 10.6.1 is:
$ ./locale
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Abort trap
Ok I don't have an answer for you, but I have some clues:
This isn't limited to OS X 10.6. I get the same result on a 10.4 machine.
I looked at the GCC source for libstdc++ and hunted around for _S_create_c_locale. What I found is on line 143 of config/locale/generic/c_locale.cc. The comment there says "Currently, the generic model only supports the "C" locale." That's not promising. In fact if I do LANG=C the runtime error goes away, but any other value for LANG I try causes the same error, regardless of what arguments I give to the locale constructor. (I tried locale::classic(), "C", "", and the default). This is true as far back as GCC 4.0
That same page has a reference to libstdc++ mailing list discussion on this topic. I don't know how fruitful it is: I only followed it a little way down, and it gets very technical very fast.
None of this tells you why the default locale on 10.6 wouldn't work with std::locale but it does suggest a workaround, which is to set LANG=C before running the program.
I have encountered this problem very recently on Ubuntu 14.04 LTS and on a Raspberry Pi running the latest Raspbian Wheezy.
It has nothing to do with OS X, rather with a combination of G++ and Boost (at least up to V1.55) and the default locale settings on certain platforms. There are Boost bug tickets sort of related to this issue, see
ticket #4688 and ticket #5928.
My "solution" was first to do some extra locale setup, as suggested by this AskUbuntu posting:
sudo locale-gen en_US en_US.UTF-8
sudo dpkg-reconfigure locales
But then, I also had to make sure that the environment variable LC_ALL is set to the value of LANG (it is advisable to put this in your .profile):
export LC_ALL=$LANG
In my case I use the locale en_US.UTF-8.
Final remark: the OP said "This program fails when I run this through g++". I understand that this thread was started in 2009, but today there is absolutely no need to use GCC or G++ on the Mac, the much better LLVM/Clang compiler suite is available from Apple free of charge, see the XCode home page.
The situation is still the same. But some functionality may be gained by
setlocale( LC_ALL, "" );
This gets you UTF-8 coding on wide iostreams but not money formatting, for my two data points.
locale::global( locale( "" ) );
should be equivalent, but it crashes if subsequently run in the very same program.
I had the same problem, checked LANG and LC_MESSAGES and they are not set when you lunch the application through Finder, so the following lines saved the day:
unset("LANG");
unset("LC_MESSAGES");
The _S_create_c_locale exception seems to indicate some sort of misconfiguration: check that whatever your LC_ALL or LANG environment variable is set to, exists in the output of locale -a.
$ env LC_ALL=xx_YY ./test
terminate called after throwing an instance of 'std::runtime_error'
what(): locale::facet::_S_create_c_locale name not valid
Aborted
$ env LC_ALL=C ./test
$ echo $?
0
But since you're on OS X, I'm not really sure how locale information is supposed to be handled.
Quoting the accepted answer:
It has nothing to do with OS X
I encountered this issue on MacOS Big Sur using an outdated MacOS utility. The specific utility was VMWare's ovftool, but none of the above LANG/LC_ALL workarounds fixed it. Updating the tool was the only way to get the error to go away. No combination of locale workarounds would fix this.
In my specific case, the error occurred using ovftool 4.1.0, and the error went away using ovftool 4.4.3.