I have to C program which is compiled using gcc in ubuntu. I want to run that executable in android terminal. When i run it is showing either "file or directory is not found" or "not executable:ELF32".
I want to run the code in android terminal. Is there any way or flags in gcc or using any other compiler so that i can run my code in the android terminal.?
Android does not use the same system libraries as Ubuntu, so they will not be found.
There are two solutions:
Copy the libraries you need.
If you can place them in the same filesystem locations they have in Ubuntu then great, otherwise you'll need to run the ld-linux.so manually and tell it where to find the libraries. Or, you could relink the program such that it expects to find the dynamic linker and libraries in a non-standard place. You might also use a chroot, but that requires root, and you'd need to find a chroot binary that works.
Use a static link.
This usually just means passing -static to GCC. You get a much larger binary that should be entirely self-contained, with no dependencies. It requires that static versions of all your libraries are available on your build system. Also, some features (such as DNS lookup) always expect a shared library, so they won't work this way.
Even then, you should expect some Linux features to not work. Basically, anything that requires hardware features or configuration files in /etc are going to need a lot of effort. There are various projects that have done this already (search "linux chroot android").
I'm not sure what the "not executable:ELF32" message means, but you should check whether you're building 32 or 64-bit executables, and which the Android binaries are using (file <whatever> should tell you).
Related
I downloaded the clang compiler directly from the prebuilt binary tar provided on the llvm website here. The tar file contains a standard directory hierarchy with bin, include, lib etc. Now I want to configure macports to use this compiler in such a way that when a subsequent port requires clang then this compiler's binary is used. Note that I do not want macports to download and install a separate copy of clang. Is it possible to do so?
DETAILS: The reason why I want to keep the clang installation in a separate place is because I often use scientific code, or other code, like chromium, and I use anaconda. I also have xcode installed and that provides its own version of compilers. Adding macports' compilers to the system makes my system almost unmanageable because it is often very difficult to ensure that the right runtime library and compilation time library are being used.
MacPorts does not support this, and there is also no unsupported way to get this done that I am aware of.
However, C++ software installed through MacPorts should always end up using the libc++ runtime (if you're on a system where it is the default). MacPorts is aware of the C++ runtime its ports use and tries to make sure all its ports use the runtime set as the cxx_stdlib in macports.conf (which defaults to your system's default).
I am learning to build a compiler using LLVM as back end.
I followed the steps on getting started with the LLVM system until setting up your environment
What is the specific location for [/path/to/your/bitcode/libs] ?
Was this mistake cause the command not found when I type in lli in a Terminal?
//I am trying to build a hello world to see through the total compiling procedure
You can put LLVM_LIB_SEARCH_PATH wherever you want. For now, you probably don't need to worry about it at all; as the documentation says, it is optional. Later, you may create bitcode (i.e. compiled VM code) functions which you would like to link into the bitcode your compiler produces. For example, you may need to create some kind of standard library and runtime environment for your executables.
That has nothing to do with the lli not found error, which is the result of the LLVM binaries either not having been installed, or having been installed somewhere which is not in your $PATH.
By default, the llvm package will configure itself for installation under the prefix /usr/local, which means that after you gmake install you should find lli and friends in places like /usr/local/bin/lli. That may or may not be in your $PATH; to find out, type
echo "$PATH"
and see if it has :/usr/local/bin: somewhere in it. If it doesn't, then you could change your PATH:
export PATH="/usr/local/bin:$PATH"
To make that permanent, you'll have to add it to your bash startup files.
But you might not want it to be installed there. I usually install software I'm playing with in my local directory tree, so that I don't have to sudo all the time. You can change the root of the installation directory tree with the --prefix argument to ./configure. (You have to do that before you build LLVM.) ./configure --help will provide some more information about configure options, but --prefix is certainly the most important one.
Whatever you do, don't do it blindly. Make sure you understand what this all means before doing it. If you plan on making a compiler, you'll need to understand some of the details of a typical build- and runtime- environment; PATH and configure scripts are on the unfortunately long list of things you should at least be somewhat familiar with.
As I understand it, some version of LLVM is already installed on Mac OS X, so you'll need to be careful that your installation doesn't interfere. The fact that bash is report that lli can't be found probably indicates that not all the tools are installed, which will make things less complicated.
I'm afraid that I don't really have any experience with installing LLVM on a Mac, but if you run into specific problems (like "my compiler doesn't work after I install LLVM") then you could ask a specific question with appropriate tags.
Upon finishing a COBOL program, how do I compile it into an executable file that may be run on other PCs? I'm using OpenCOBOL via cygwin.
Check out this getting started page from the user manual for OpenCOBOL:
But in case the link is broken, just do this:
$ cobc -x hello.cob
$ ./hello
cobc is the compiler. hello.cob is the source file. The output is simply the file hello which can be run by calling ./hello. The -x option is necessary to build an executable.
However, with all compiled programs, it is compiled for the machine is was built on. It will work on machine with similar architectures, but you don't true cross-platform ability unless you're using an interpreted language like Python or Java.
If you compile with Cygwin, the target computers also need Cygwin, or in particular the cygwin dynamic libraries along with the OpenCOBOL runtimes.
Many times, you can also compile under MinGW, which lessens the dependencies, but also lessens the available POSIX features.
Easiest path, install OpenCOBOL and Cygwin on the target machines, and you'll be good to go, otherwise you'll need to produce release packages with all the dependencies and instructions for PATH settings.
I'm trying to get something of an environment on a usb stick to develop C++ code in. I plan to use other computers, most of the time linux, to work on this from a command line using g++ and make.
The problem is I need to use some libraries, like Lua and OpenGL, which the computers don't have. I cannot add them to the normal directories, I do not have root on these computers. Most of the solutions I've found involve putting things in /usr/lib/ and the like, but I cannot do that. I've also attempted adding options like '-L/media//lib', which is where they are kept, and it didn't work. When compiling, I get the same errors I got when first switching to an OS with the libraries not installed.
Is there somewhere on the computer outside of /usr/ I can put them, or a way to make gcc 'see' them?
You need more than the libraries to be able to compile code utilizing those libraries. (I'm assuming Linux here, things might be slightly different on e.g. OSX,BSDs,Cygwin,Mingw..)
Libraries
For development you need these 3 things when your code uses a library:
The library header files, .h files
The library development files, libXXX.so or libXXX.a typically
The library runtime files , libXXX.so.Y where Y is a version number. These are not needed if you statically link in the library.
You seem to be missing the header files (?) Add them to your usb stick, say under /media/include
Development
Use (e.g.) the compiler flag -I/media/include when compiling source code to refer to a non-standard location of header files.
Use the compiler/linker flag -L/media/lib to refer to non-standard location of libraries.
You might be missing the first step.
Running
For dynamically linked libraries, the system will load those only from default locations, typically /lib/ , /usr/lib/
Learn the ldd tool to help debug this step.
You need to tell the system where to load additional libraries when you're running a program, here's 3 alternatives:
Systemwide: Edit /etc/ld.so.conf and add /media/libs there. Run ldconfig -a afterwards.
Local, to the current shell only. set the LD_LIBRARY_PATH environment variable to refer to /media/lib, run export LD_LIBRARY_PATH=/media/lib
Executable: Hardcode the non-standard library path in the executable. You add this to the linking step when creating your executable: -Wl,-rpath,/media/lib
Etc.
There could be other reasons things are not working out, if so,
show us the output of ls -l /media/libs , and where you put the library header files, the command line you use to compile/link, and the exact errors you get.
Missing the headers and/or development libraries (for dynamic libraries there is usually a symlink from a libXXX.so to a libXXX.so.Y , the linker needs the libXXX.so , it will not look directly at libXXX.so.Y)
using libraries not compatible with your current OS/architecture. (libraries compiled on one linux distro is often not compatible with another distro, or even another minor version of the same distro)
using an usb stick with a FAT32 filesystem, you'll get in trouble with symlinks..
What is the best method in bash to check to se if a c library is installed?
Per comments, to be more clear:
I run an install script that looks for the libexpat header file (expat.h)
Currently it is doing this via:
if ! locate libexpat.so 1> /dev/null; then
However, it should be looking for expat.h, but this still required the mlocate db to be updated first.
Any better way?
You can do as autoconf does (or, more accurately, configure scripts generated by autoconf do), and test whether you can compile a C program that uses the library.
If you don't have a compiler or the development tools installed, your options are more limited.
It also isn't clear whether you want to search in out of the way locations for the library, or if you are only concerned with it being installed in the main library directories. Also, are you looking only for shared libraries, or are you looking for static libraries - the naming conventions differ wildly depending on what you're up to, and which machine type you are doing it on (Linux and Solaris vs AIX vs MacOS X vs HP-UX (older, for PA-RISC) vs Windows, for instance). If you're looking for static libraries, you'll be hard-pressed to use them without the compiler (and probably the headers). If you're looking for shared libraries, you can use those without the development paraphernalia if you compile the program on some other machine and copy it to the target machine.
The best one I found was with #cnicutar's comment, thanks.
Specifically to do this in a bash script:
expat_loc=`whereis -b expat.h | cut -c8-`
if [[ -e "$expat_loc" ]]; then
#Something something
fi;
If you need runtime, you'll need a specific version for running some stuff. Try to run that stuff.
If you need headers, try to compile something.