I would like to compile some C++ code from source and then run a Python wrapper on my web hosting server as a cron job. I compiled it on my Mac, uploaded onto the server and, unsurprisingly, the server running Linux complained saying:
OSError: [Errno 8] Exec format error
I do not have the rights to run g++ sptree.cpp tsne.cpp -o bh_tsne -O2 on the server. Is there a way for me to obtain a compiled binary that would be compatible with whatever OS (Linux) the server is running on? Thanks!
This is essentially the reason people moved to java, which is platform independent.
For C++, you need the specific link libraries for the target machine. Some compilers have the option of choosing the linker objects by flag (or setting) and allowing someone to "script" the final executable output. I cant say if the Mac does...
Related
I'm about to release a library (.so) to my client.
However, my client's platform is a very old debian(9.1 released on 2017).
My libray only works with >= glibc-2.27.
I managed to run program by the following tricks
// copy libm-2.27.so from my computer to the old debian
ln -sf ./libm-2.27.so libm.so.6
gcc ./test.c -o ./test -lmylib -L ./ -lm
LD_LIBRARY_PATH=`pwd` ./test
But my client don't accept this solution.
Is it possible to link to an older version of math library ?
For instance, the client gives me the math library and I link my library against it in my computer.
thanks!
My libray only works with >= glibc-2.27.
Is it because you actually require functionality that was added to GLIBC-2.27, or because you system just happens to have that version installed and you don't know how to build for an older system?
From the comments, it appears that you don't actually need GLIBC-2.27.
In that case, the simplest solution is to install a VM with Debian 9.1 in it, and build you library inside that VM.
This has an added advantage that you can test your library before you ship it to your client, in the environment that matches that of the client.
If you do not want a VM, other solutions are listed here.
I managed to run program by the following tricks ... But my client don't accept this solution.
Your client is smart to reject that solution: it can not generally work, and running in such environment would expose your client to a multitude of potential undefined behaviors and crashes. To understand why this is so, read this answer.
I am trying to run a compiled C++ program on my webserver (Debian), but the terminal is outputting the following error message:
-bash: ./program.bin: Permission denied
The rights on program.bin are set to -rwxr-xr-x, which means that it should have the permission to be executed. I already tried running /bin/bash program.bin, but this is giving me this error:
ovInterface.bin: ovInterface.bin: cannot execute binary file
The hosting provider of the webserver probably has forbidden this, since there are a lot of websites/accounts hosted on my webserver. If that's the case, is it possible to bypass this restriction? I was able to run .php files in the background of the webserver, which had an infinite for loop and handled socket connections etc.
Any help would be appreciated!
EDIT:
I found out that the cannot execute binary file error from /bin/bash program.bin means that the compiled program is not built for the system architecture. program.bin was compiled on another machine (however both are 64-bit).
If it is possible to run the .bin file using /bin/bash: How do I compile C++ code to executables without access to gcc, g++, make and apt-get? Can I upload a compiler executable to my webserver and compile the C++ source then?
I want to know how to cross compile nginx-1.0.11.
I have already tried : --with-cc option
but it is giving me an error : checking for C compiler ... found but is not working
./configure: error: C compiler arm-linux-gcc is not found
--with-cc-opt is also not working.
I tried to change compiler manually too(by changing a Makefile).
I have already install arm-linux-gcc and its working fine with openssl(It successfully cross compiled openssl. so problem is not with arm-linux compiler).
Any help will be highly appreciated ..
Thanks in advance. :)
There is no easy answer. nginx has it's own non-autoconf configuration system which currently doesn't support cross compilation.
Either hack or avoid the configuration system, or wait until nginx adds support for cross compilation.
See http://forum.nginx.org/read.php?29,220607 where the issue has been recently discussed.
I ran ./configure for my ia32 Linux host, and built it (to make sure it worked), then
1) deleted all object files,
2) edited objs/Makefile to change the value of CC, add include paths for my compiler and library paths for my linker
3) copied some header files from /usr/include to a local directory
There is a problem in that if /usr/include is in the search path, it is searched before the header files for my compiler. This became a problem when x86 assembler instructions were pulled into the definition of htonl().
An alternative is to hack conf/cc/gcc to add an option and do configurations there, includeing supporting a shell variable of CROSS. I haven't done that yet.
Have you considered settng up QEMU - http://wiki.qemu.org/Main_Page and a lightweight image from linaro - http://www.linaro.org/. I have not tested this approach, but i can tell you that I have successfully compiled and running nginx on my Pandaboard ARM v7a.
I successfully cross-compiled nginx by first creating a config on my desktop machine (./configure --without-pcre --without-http_rewrite_module), then just editing the 'cc' command in /objs/Makefile to point to the correct gcc. The Makefile the configure produces is incredibly simple. Just make sure you have all your environment variables set properly as well (CC, LD, LIBS, etc)
I just build v 1.4.7 this way
./configure --with-ld-opt=-L/path/to/libfolder \
--with-cc-opt=-I/path/to/include --prefix=./nginx
make CC=arm-linux-gnueabi-gcc
make install
--prefix nginx installs everithing in ./nginx and one just need to move created nginx folder on device but has to start server from relative path.
./nginx/sbin/nginx
It's not often two things I love so much come together to cause me so much annoyance (besides my kids). I've written a Haskell program at work that uses libraries like text, xml-enumerator, attoparsec-text, etc. I have it working properly on my Windows machine at work, my Ubuntu virtual machine at work (32-bit), my Ubuntu desktop (32-bit again) and an EC2 instance running Ubuntu (64-bit).
Our client is running CentOS 5.3, 64-bit. I can't for the life of me get this executable to run properly. I tried creating a static executable using:
ghc --make myprog.hs -optl-static -optl-pthread
But when I try to run that executable on the CentOS server, I get an error message:
openFile: invalid argument (Invalid argument)
I'm assuming this is related to the bug described here. I've tried compiling from both 32 and 64 bit Ubuntu, tried static and shared builds, nothing works (though I occasionally get segfaults instead of the above error message). I can try downloading CentOS 5.3 and creating a virtual machine for it, but it will take a while to download, and I'm not sure which version of GHC will work on it (I tried getting GHC 7 on their server, but I ran into a libc issue).
At this point, I've come up with a few possible approaches, but I'd like to avoid these if at all possible:
Rewrite in a different language (the thought of doing this in Java makes me queasy, though it could be a nice time to try out Cal/OpenQuark).
Maybe try out an alternate compiler, like jhc. But I'm not quite certain how to get started installing all the dependencies for this program in jhc; if people have experience and know that text/attoparsec/etc work in jhc, I'd love to hear it.
Hack of all hacks: build a Windows executable, install wine on their server and run it that way.
As a total aside, these are the situations where I really wish we had a JVM backend for GHC. I suppose I could try out LambdaVM as well. But I'd love to hear community advice on what to do here.
This simple example "works for me":
$ cat A.hs
main = print "yes"
$ ghc -O2 --make -static -optc-static -optl-static A.hs -fvia-C -optl-pthread
$ ldd A
not a dynamic executable
$ ./A
"yes"
(and I've used this process, via .cabal, to ship executables for clients in the past couple of years).
I think the best bet is to file bugs, and get this working. The IHG can also fund work like this, but I'm fairly sure the GHC team would consider this a high priority, if you're trying to ship products.
It is related to the old glibc library in CentOS. You have to compile with the same version of glibc as installed on CentOS.
I had exactly the same problem. Haskell executable compiled on arch (or ubuntu) won't run on CentOS. In my case though i was lucky, because our admin just removed CentOS and installed Arch for application server.
I found out the problem. It seems that the link to the Biohaskell page is accurate: this is a problem loading iconv. This occurs when calling openFile, but not when calling openBinaryFile. Since xml-enumerator uses the latter, it worked just fine. Switching over the rest of the code to use openBinaryFile instead (via Data.Enumerator.Binary.enumFile) got everything to work.
This is a good workaround for my use case, but the bug still exists.
All,
My host supports Perl CGI scripts, how do I use a compiled CGI script on the host?
I tried setting execute permissions via chmod, but when I try and run it via the browser, I get a server error.
Thanks in advance for all help.
It's possible with a few restrictions:
You're compiling statically or don't have any external dependencies
You're using a glibc that's no newer than theirs
If you're compiling under gcc, you might also need to provide libgcc_s.so which might mean you need a LD_LIBRARY_PATH in which case you'd probably run your binary through a shell script.
You can check the dependencies on your binary with ldd. My recommendation is to compile statically with no dependencies on a system with a glibc at least as old as theirs.
NOTE: (1) above isn't strictly a requirement if you can set LD_LIBRARY_PATH and can run everything through a wrapper script, but things get much more complicated if you need such functionality.
perhaps i'm missing something, but the fact that your host supports "perl cgi" doesn't mean that they support "compiled cgi" (which i would presume is a C CGI program).
Some details about what the server error was would be helpful.