I set up an ancient machine with SUSE Linux 10.1, and am trying to build a current distro of gcc, but that wants gmp, mprf and mpc.
Now, I installed gmp successfully, and I find it in /usr/local/include and /usr/local/lib. I also find the shared library libgmp.so.10 in /usr/local/lib. Alas, when I run make check for mpfr, it complains that it can not open the shared object file libgmp.so.10
The question, then, is what do I need to do to tell it where the shared object file is?
Thanks
Ted
Make sure /usr/local/lib is on the LD_LIBRARY_PATH environment variable.
Alternatively, configure mpfr with the --with-gmp=/usr/local/ option. You'll have to do the same with mpc when you build that, but you'll have to also add the --with-mpfr=/usr/local option when configuring it.
Related
I have a question and I hope some guru here could help me out :) My goal is simple : (GOAL1) build a older glibc on a newer system and (GOAL2) build old software that can run on older glibc. I am on gcc4.9, glibc2.19, amd64 system. I did compile glibc2.14 and gcc4.7.3 on my system.
(convention : /path/to/libc2.14_dir = $LIBC214, /path/to/gcc4.7.3 = $GCC473)
I am trying to compile bash4.2.53 ( and other softwares coreutil, binutil, qt3.3...) using newly built glibc2.14. My configure and make looks like this : ( I am being in object/build directory )
$ cd /path/to/build/bash-4.2.53
$ CC=$GCC473/bin/gcc CXX=$GCC473/bin/g++ CPP=$GCC473/bin/cpp \
/path/to/source/bash-4.2.53/configure \
--prefix=/path/to/installation/bash-4.2.53
$ make all V=1 \
CFLAGS="-Wl,--rpath=$LIBC214/lib -Wl,--dynamic-linker=$LIBC214/lib/ld-linux-x86-64.so.2" \
CPPFLAGS="-Wl,--rpath=$LIBC214/lib -Wl,--dynamic-linker=$LIBC214/lib/ld-linux-x86-64.so.2" \
CXXFLAGS="-Wl,--rpath=$LIBC214/lib -Wl,--dynamic-linker=$LIBC214/lib/ld-linux-x86-64.so.2"
When make is done in bash4.2.53 build (object) directory, I tried 2 scenarios :
SCENARIO1. Use system's libc2.19
$ ldd ./bash
linux-vdso.so.1 (0x00007ffe677c3000)
libtinfo.so.5 => $MY_PREBUILT_NCURSE/lib/libtinfo.so.5 (0x00007f5d108e3000)
libdl.so.2 => $LIBC214/lib/libdl.so.2 (0x00007f5d106df000)
libc.so.6 => $LIBC214/lib/libc.so.6 (0x00007f5d10354000)
$LIBC214/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f5d10b0a000)
This line is weird :$LIBC214/lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f5d10b0a000)
$ $LIBC214/bin/ldd ./bash
not a dynamic executable
SCENARIO2. Add $LIBC214/bin to my PATH, $LIBC214/lib to my LD_LIBRARY_PATH
$ ldd ./bash
/bin/bash: $LIBC214/lib/libc.so.6: version `GLIBC_2.15' not found (required by /bin/bash)
$ export SHELL=$PWD/bash
$ ldd --version
/bin/bash: $LIBC214/lib/libc.so.6: version `GLIBC_2.15' not found (required by /bin/bash)
$ ldd ./bash
/bin/bash: $LIBC214/lib/libc.so.6: version `GLIBC_2.15' not found (required by /bin/bash)
As far as I can tell, SCENARIO2 is the right way to run commands. My assumption is that I built glibc2.14 wrongly, that it uses /bin/bash which in turn uses glibc2.19. I am not really sure.
My question:
Could you please explain for me the weird line above and the following line that out put not a dynamic executable?
Could you share me your steps to properly build glibc (GOAL1) and build software using that glibc (GOAL2) ?
What could I do next to solve 2 above scenario?
Thank you.
when you link ELFs, the absolute path to the ldso is hardcoded in it. if you want to use a different one, you can use the -Wl,--dynamic-linker=/path/to/ldso flag to override it. this path is absolute though, so if you try to move your local glibc somewhere else, the ELFs you linked will fail to execute (with errors like no such file). there's no way around this as the system, by design, must have an absolute path in it to the interpreter.
the reason you get weird not a dynamic executable output is that ldd works by actually executing the target ELF and extracting (via debug hooks) the libraries that get loaded. so when you attempt to use a diff ldd like that, glibc gets confused. if you want a stable dependency lister, you might consider something like lddtree from the pax-utils project (most distros have this bundled nowadays). or run readelf -d on the file directly and look at all the DT_NEEDED entries.
trying to build & maintain your own toolchain (glibc, gcc, etc...) is a huge hassle. unless you want to dedicate a lot of time to this, you really should use a project like crosstool-ng to manage it for you. that will allow you to build a full toolchain using an older glibc, and then you can use that to build whatever random packages you like.
if you really really want to spend time doing this all by hand, you should refer to the glibc wiki for building your own glibc and then linking apps against that glibc.
I'm trying to install gcc4.9 on a SUSE system without an internet connection. I compiled gcc on an Ubuntu machine and installed it into a prefix, then copied the prefix folder to the SUSE machine. When I tried to run it gcc complained about not finding GLIBC_2_14, so I downloaded an rpm for libc6 online and included it into the prefix folders. my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64. When I try to run any program now (ls, cp, cat, etc) I get the error error while loading shared libraries: /home/***/prefix/lib64/libc.so.6: unexpected reloc type 0x25.
Is there any way I can fix this so that I can get gcc4.9 up and running on this system?
As an alternative, is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?
my LD_LIBRARY_PATH includes prefix/lib and prefix/lib64
See this answer for explanation of why this can't work.
Is there any way I can fix this so that I can get gcc4.9 up and running on this system?
Your best bet is to install whatever GCC package comes with the SuSE system, then use that GCC to configure and install gcc-4.9 on it.
If for some reason you can't do that, this answer has some of the ways in which you can build gcc-4.9 on a newer system and have it still work on an older one.
is it possible to build gcc staticaly so that I don't have to worry about linking at all when I transfer it between computers?
Contrary to popular belief, fully-static binaries are generally less portable then dynamic ones on Linux.
I am trying to build Guile 1.8.8 from source. I am stuck at the point where the build system is looking for libtool. I have installed it in a non-standard location.
I have already built Guile 2.0.11. In 2.0.11 build system, there is an explicit flag to configure --with-libltdl-prefix, which I think tells the build system where libtool is installed.
For Guile 1.8.8, I have Libtool installed in a non-standard location. How do I tell the build system where it is installed?
I am specifically getting error messages like:
libguile/Makefile.am:40: Libtool library used but `LIBTOOL' is undefined
libguile/Makefile.am:40: The usual way to define `LIBTOOL' is to add `LT_INIT'
I think in general this is a question regarding one or more of the autotools and how the build system finds programs / headers / libraries in non-standard locations.
This link is informative: How to point autoconf/automake to non-standard packages
Find the directory where *.m4 exists, which corresponds to libtool, or package which is in non-standard location.
export ACLOCAL_PATH=/path/to/m4/file
cd /path/to/configure.[in,ac]
autoreconf -if
./configure
I am creating chroot jail in linux , but i do not have access to any system file like ls/cd/gcc/g++. What are the necessary libs/bin/systme files i need to copy to my chroot jail ?
To create a basic debian-based root file systems (not necessarily on debian-based host systems), you can use debootstrap or multistrap tool. I think there is also a febootstrap equivalent for fedora-based root file systems.
In debootstrap, you will have full control on which packages should be installed, over the base necessary packages, which are packages with "Priority: required" and "Priority: important" tag. In case of initial extra packages, you are responsible for package dependencies.
multistrap is a newer tool, which uses apt and can leverage multiple repositories, and so takes care of the dependency issue.
You can also do cross-bootstrapping which is creating a root fs for another architecture. This is useful when creating embedded or virtualized systems.
sample debootstrap command:
debootstrap wheezy rootfs/ http://ftp.us.debian.org/debian
then you can chroot into it and do whatever else is needed.
This is by far the easiest method to create chroots.
Executables like ls/cd/gcc/g++, they depend on shared library (unless you didn't build them to be statically). So, what you need to do is copy all those shared library dependencies to appropriate location into your chroot jail, also you need to find what are those shared dependencies are. To find out you need help from "ldd".
To see what shared dependencies gcc has, do the following:
ldd /usr/bin/gcc
On my system it shows the following output:
linux-vdso.so.1 => (0x00007fffd9bff000)
libc.so.6 => /lib64/libc.so.6 (0x00000030c9c00000)
/lib64/ld-linux-x86-64.so.2 (0x00000030c9800000)
So, gcc has the dependency of standard c library libc.so and it also needs ld (executable loader), place these shared libraries into appropriate place (i.e libc under /lib64) into your chroot jail, along with gcc. So gcc can load necessary stuffs while you call gcc.
Is there any way to link against RedHat static libraries while building on Ubuntu and using GCC?
Copy over the RedHat library and header files to a directory preserving directory structure and give GCC the --sysroot directive to tell it to look in that directory as prefix for searching libs and headers
I see two obvious solutions:
Copy /usr/lib, /lib and /usr/include from a Red Hat system into a subtree and point -I and -L to this subtree.
Install a minimal RedHat into a chroot and compile there.
The first solution is the easiest, but you might run into libc version issues. The second solution is guaranteed to work, but not far from running a complete RedHat for compilation.