I have a binary that requires glibc-2.18 installed, but the newest I can get using yum is 2.17. What I would want to accomplish is to test my binary with only a built glibc-2.18 (not installed, from what I've read it's a bad idea to do it manually). I read multiple articles regarding the LD_LIBRARY_PATH and how to set it, but most of them were either incomplete for me to follow through or I get an error, such as sed: relocation error.
As for glibc and how I built it: downloaded the version, extracted, made /build folder inside the extracted folder, and from it, ran ../configure --prefix=/usr. Finally, in the same folder, make.
Could someone provide step-by-step instructions on how to run my binary with the built library ?
What I would want to accomplish is to test my binary with only a built glibc-2.18 (not installed, from what I've read it's a bad idea to do it manually).
This is what GLIBC itself does when you run make check:
/build/elf/ld.so --library-path /build:/build/elf:/build/math:/build/nptl:... /path/to/binary
Explanation: run ld.so from /build and ask it to load other parts of GLIBC from the /build and its subdirectories.
This works for most programs, but there is a certain class of programs that wouldn't work when invoked this way. One example in the latter category is a program that execve()s itself.
You need to link the binary with -Wl,-rpath, as explained in the glibc testing instructions. So if glibc 2.18 is installed under /opt/gnu/glibc-2.18, the linker invocation could look like this:
gcc -Wl,--dynamic-linker=/opt/gnu/glibc-2.18/lib64/ld-2.18.so \
-Wl,-rpath=/opt/gnu/glibc-2.18/lib64 -L/opt/gnu/glibc-2.18/lib64
Related
Let's say I did this while installing GCC (on RHEL6):
./configure --prefix=/path/to/gcc_install
make
make install
Then I move it:
mv /path/to/gcc_install /other/path/to/gcc
Then I set my PATH and LD_LIBRARY_PATH correctly... How do I tell it where to find the STL headers & STD C++ library that it installed so it doesn't look in /usr/...?
The word to describe this property is "relocatable". That means the program and its support files can be moved after it is built and it will still be able to find everything it needs.
From this thread, it sounds like GCC is already relocatable by default since it uses relative paths to find all of its files. If you continue to have trouble, I suggest posting a shell session showing how you compiled, installed, and ran GCC, and then showing how it doesn't work when you move it to a different folder. You should run GCC with the -v option so we can see detailed information about what it is doing.
I am building a RPM package for a c++ application. The compilation and installation succeed. Then the the following command fails /usr/lib/rpm/check-buildroot with the following error:
Found '/user/dfsdf/rpmbuild/BUILDROOT/vendor-xerces-c-3.1.3-3.1.3-1.x86_64' in installed files; aborting
I haven't found any documentation about this command. What does check-buildroot does?
Here is a pointer to a copy of the script. Because it is considered an "internal" part of rpmbuild (in /usr/lib/rpm, rather than /usr/bin), there is no manual page for it.
However, it is known to people who troubleshoot problems building rpms.
The script checks for a common problem: when building an rpm, your package compiles and installs into a BUILDROOT directory. If it is done properly, no trace of that directory name will remain in the final package. Occurrences of the actual installation directory, e.g., /usr/bin, /usr/lib, etc., are okay.
Further reading:
rpmdevtools-5.3-1.el4 RPM for noarch describes the rpmdevtools and gives its changelog.
pk's Tech Page discusses a change that a developer made based on the check-buildroot message.
check-buildroot failure is another example where it was used
How do I safely remove a path string from a compiled library without corrupting the library? illustrates the real problem: getting good advice.
I am new to C++ and I have to handle large integers, so I have to install GMP through Cygwin.
Any documentation I can find on installing this already assumes that you know what you are talking about, and I really don't.
Anyway, I got the right .tar or whatever, extracted it properly, and now any website I see says to run ./configure --prefix=${gmp_install}...
What in the world is gmp_install? And what directory do I run configure from? Huh? I can run it from my little Cygwin terminal, but it just says no such file.
Next, I am supposed to type make. From where?
Help...
Welcome to StackOverflow (SO).
The source directory of GMP should probably contain the file called configure. This is the script which you have to execute to "configure" the build system in your environment. It means that during configuration Autotools (the build system which is used to build GMP) will gather information about your environment and generate the appropriate makefile. Gathering information includes things like: understanding that you are on Windows, understanding that you are using Cygwin, understanding that your compiler is GCC and its version is x.y.z, and etc. All these steps are important for successful build.
You can specify a lot of different options to this configure script to tweak the configuration process. In your case, you specify the prefix option which determines the installation directory, i.e. the directory where you want the built and ready-to-use GMP distribution to reside. For example:
./configure --prefix=/D/Libraries/GMP
will configure the build system to install the GMP binaries to D:\Libraries\GMP directory.
Assuming that the GMP source directory (the one you extracted from *.tar) is located at say D:\Users\Me\Downloads\GMP, in order to build and install GMP you should do the following:
cd /D/Users/Me/Downloads/GMP
./configure --prefix=/D/Libraries/GMP
make
make install
NOTE: The make command will actually execute the makefile (which was generated by configure script) I've mentioned earlier. This file describes the process of building and installing GMP on your system.
NOTE: ${gmp_install} is nothing, but an environment variable. For instance, you could do:
export gmp_install=/D/Libraries/GMP
./configure --prefix=${gmp_install}
this can be useful, for example, when you have to use the same path in multiple places, and don't want to type it everytime. There are other cases, when this is useful, but for that you'll have to learn more about environment variables, what they are for, and Bash scripting in general. However, all this goes far beyond the answer on your question.
You'll have to spend quite some time to understand all these things and how they fit together, and you'd probably have to ask more questions here on SO as understanding all that stuff for a beginner alone might be very challenging.
I'm trying to use the Quadprog++ library (http://quadprog.sourceforge.net/). I don't understand the instructions though.
To build the library simply go through the ./configure; make; make
install cycle.
In order to use it, you will be required to include in your code file
the "Array.hh" header, which contains a handy C++ implementation of
Vector and Matrices.
There are some "configure", and "MakeFile" files, but they have no extension and I have no idea what to do with them. There are also some ".am", ".in" and ".ac" extensions in the folder.
Does this look familiar to anyone? What do I do with this?
(Edit: On Windows.)
This package is built using the autotools. These files you talk to (*.am, *.in...) are because of the tools automake, and autoconf.
Autotools is a de-facto standard in the GNU/Linux world. Not everybody uses it, but if they do you ease the work of package and distribution managers. Actually they should be portable to any POSIX system.
That said, I'm guessing that you are using a non-unix machine, such as Windows, so the configure script is not directly runable in your system. If you insist in keep using Windows, wich you probably will, your options are:
Use MinGW and MSYS to get a minimal build enviroment compatible with autotools.
Use Cygwin and create a POSIX like environment in your Windows.
Create a VS project, add all the source of the library in there, compile and debug the errors they may arise, as if the code had been written by you.
Search for someone that already did the work and distributes a binary DLL, or similar.
(My favourite!) Get a Linux machine, install a cross-compiler environment to build Windows binaries, and do configure --host i686-mingw32 ; make.
This instruction say how can be build an program delivered like a tarball in Linux. To understand take a look on Why always ./configure; make; make install; as 3 separate steps?.
This can be confusing at first, but here you go. Type these in as shown below:
cd <the_directory_with_the_configure_file>
./configure
At this point, a bunch of stuff will roll past on the screen. This is Autoconf running (for more details, see http://www.edwardrosten.com/code/autoconf/index.html)
When it's done, type:
make
This initiates the build process. (To learn more about GNU make, check out Comprehensive gnu make / gcc tutorial). This will cause several build messages to be printed out.
When this is done, type:
sudo make install
You will be asked for the root password. If this is not your own machine (or you do not have superuser access), then contact the person who administers this computer.
If this is your computer, type in the root password and the library should install in /usr/local/lib/ or something similar (watch the screen closely to see where it puts the .so file).
The rest of it (include the .hh file) seems self-explanatory.
Hope that helps!
I have access to computer in a public library and I want to try out some C++ and maybe other code. Problem is that there is no g++ installed and I can't install it using packages because I have no root access. Is there a "smart" way to make a full environment for programming in a home folder?
I have gcc installed (I can compile C code). Also, I have a home folder that is consistent. I don't know where to find precompiled g++, I found only source but I don't know what to do with it. I tried to ask them to install this but it didn't work :)
If you want to install it as a local user
GNU GSRC provides an easy way to do so
Link: http://www.gnu.org/software/gsrc/
After configuration, simply specify the following commands:
cd gsrc
make -C pkg/gnu/gcc
make -C pkg/gnu/gcc install
The second step could also be changed to speed up for an N-core system:
make -C pkg/gnu/gcc MAKE_ARGS_PARALLEL="-jN"
You can run the configure script with the --prefix parameter: ../gcc-4.5.0/configure --prefix=/home/foo/bar. Since it is very likely that the c++ standard library is different then the one on your system, you have to set export LD_LIBRARY_PATH=/home/foo/bar/lib before you can start a program compiled by this compiler.
Once, a long time ago (1992 or so), I went through something similar to this when I bought a SCO system with no development environment. Bootstrapping it up to having a full development environment was a gigantic pain, and not at all easy. Having library header files or gcc on a system would make your job a whole lot easier.
It depends a lot on just how obnoxious the library has been about what kinds of things are installed. If there is no gcc there, your job becomes a bit harder. If there are no header files for glibc there, your job is a LOT harder.
Also, do you get an account on the system so you have a home folder that's consistent from login to login?
If you have no gcc there, you need to find a pre-compiled binary of gcc/g++ and install it somewhere. If you have no header files there, you need to find copies of those and put them on the system.
There is no 'standard' way of installing gcc in your home folder though. All of the solutions are going to have some manner of hand-rolling involved.
Have you asked the librarians if they can change what's installed because you want to learn a bit of programming and only have access to their computers to do it with? That might well be the easiest solution.
From your comment it seems that you do have gcc and if you can compile C code, you have the library header files. So now it's a matter of actually compiling your own version of g++. You could probably find a way to entice the package manager on the system into installing a binary package somewhere other than in a system folder. I think this solution is less fun than compiling your own, and I think there may also be possible subtle problems as that installed package may be expecting to find things in particular places and not finding them there.
First thing to do is to make sure you've downloaded the right source for the gcc package. The place to find that is the GNU United States mirror page. You want to find the gcc-4.5.0.tar.bz2 or gcc-4.5.0.tar.gz file on the mirror site you choose. It will likely be in a gcc directory, and a gcc-4.5.0 sub-folder.
After you have that downloaded, you should untar it. In general you shouldn't build gcc in the folder you untar it into. So create another sibling folder that you actually want to build it in labeled gcc-build. Then the command you want is ../gcc-4.5.0/configure --prefix=$HOME/.local --enable-languages='c c++'.
gcc does require some other packages be installed in order to be able to compile itself. You can use the same --prefix line for these packages to install them in the same place. The gcc website has a list of pre-requisite packages.
$HOME/.local is sort of the standard accepted place for per-user installs of things.
If you have fakeroot, you can use that to set ~/some-path as root to install the packages from. Alternatively, you can setup a chroot environment to do the same.
Given this, you can then use dpkg -i package.deb to install the gcc package(s) on your system. You will need to download and install each package individually (e.g. from the debian website) -- at least binutils, glibc, linux-headers and gcc.
If you are on another system, you will need to get the right packages for that system and install them using the corresponding package manager.