I want to compile and install a library using the standard unixy system of configure, make, sudo make install. On the Ubuntu based systems I am used to, I can put libraries in /usr/local/lib and they will be found at run time. This is usually the default install location for most build systems.
I am now using a CentOS system for the first time and I find that /usr/local/lib does not appear to be a standard location, my libraries cannot be loaded at run time as they cannot be found. So, my question, what, if any, are the standard install locations where I can put my libraries on CentOS such that they can be found, without messing around with LD_LIBRARY_PATH?
You probably need to update /etc/ld.so.conf to include /usr/local/lib (and then run ldconfig to regenerate the linker cache). You can also use the -rpath linker argument to embed the lib path into the resultant executable. This can be safer when tinkering with a running system.
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.
I'm trying to install ONLY the Boost Libraries 1.48.0 that are 100% complete from FC17 on an FC16 system. I have scoured the net but can't figure out how to do it. I have attempted to upgrade to rawhide but there are too many broken dependencies. I was hoping to just be able to upgrade that one package, as hopefully I don't believe I have too many programs installed that depend on Boost libraries (just the ones I'm coding).
I need to use the new features in 1.48.0. If I can't install them via an RPM, can I compile them as a normal user, store them in ~/lib and link against them?
I'm on FC16 x86_64.
Yes you can. You just need to export several shell environment variables in your shell profile to tell the compiler where to find your new boost header files and shared object files.
# For C and C++ header files search path
export C_INCLUDE_PATH=$your_new_boost_include_dir:$C_INCLUDE_PATH
export CPLUS_INCLUDE_PATH=$your_new_boost_include_dir:$CPLUS_INCLUDE_PATH
# link path
export LIBRARY_PATH=$your_new_boost_lib_dir:$LIBRARY_PATH
Usually you'll also need to do the following so that the compiled executables can be linked to the right version of shared object files at run time:
# run-time
export LD_LIBRARY_PATH=$your_new_boost_lib_dir:$LD_LIBRARY_PATH
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..
I have installed Cygwin on my system. But when I try to use the gcc command it says:
bash: gcc: command not found
Can anyone provide me the solution, please?
In my installation there was no generic gcc command either, so I made a symlink for it:
cd /usr/bin
ln -s i686-pc-cygwin-gcc-3.4.4.exe gcc
Now check if it worked by doing which gcc which should give you /usr/bin/gcc and then gcc should give you gcc: no input files. Note that your version of i686-pc-cygwin-gcc-3.4.4.exe may be different. Check in /usr/bin for it.
Maybe during installation of Cygwin you have not selected gcc, gdb and make packages.
I had the same problem and it was resolved after I selected above-mentioned packages.
A couple of things:
I always install the whole Cygwin package. Earlier versions had troubles with dependencies that are fixed now, I believe, but it's still a good habit. You never know when you may need the most esoteric bit of Cygwin.
You may have to change your path. All the tools can generally be found okay if you're running inside the Cygwin bash shell but that's not necessarily the case from cmd.exe.
It's unlikely to be that last one since your error message is coming from bash itself, so I'm pretty certain that's how you're running it.
Have a look to make sure you have /usr/bin/gcc from within bash and that your path includes /usr/bin somewhere:
pax> echo $PATH
/usr/local/bin:/usr/bin:/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS
pax> which gcc
/usr/bin/gcc
If it's not there, go back and re-install everything (or the relevant development package if you don't want everything). If it is there and your path doesn't have its location, change your path, in either /etc/profile or the equivalent in your home directory.
Another related issue that wasn't mentioned here, is from the command line the compiler needs the environment path variable updated to find the location of the c++ header files. In windows you can just update the path environment using the 'advanced system properties' GUI and add the location of the c++ include files. This will update the PATH environment variable in Windows cmd & Cygwin automatically upon restarting the shell.
To update your PATH from Linux or the Cygwin shell type... PATH=$PATH:/your_path_here Example:PATH=$PATH:/cygdrive/c/cygwin/lib/gcc/i686-pc-mingw32/4.7.3/include/c++ Also a good idea to add just the include directory as well: PATH=$PATH:/cygdrive/c/cygwin/lib/gcc/i686-pc-mingw32/4.7.3/include/ ...or check the proper directories for the location of your installation's include files, I recommend installing mingw for use with Cygwin, which is envoked with g++.
To install additional needed packages in Cygwin re-run the Cygwin install utility & check install from Internet to add packages from web repositories and add mingw-gcc-g++ & mingw-binutils. To compile your code: g++ hello.cpp -o hello
If using the gcc utility instead compile with the command: gcc hello.cpp -o hello -lstdc++ ... to get your executable.
As long as you have either gcc or mingw installed and the path to the c++ include files is in your path environment, the commands will work.
There is another hard to spot mistake could also cause this error,
If your Makefile uses PATH as variable, the gcc not found error could happen.
This is because it changes the system path temporarily.
I took a lot of time checking the cygwin environment setting to discover this, so I'll leave it here in case this helps anyone finding their way here.