I'm attempting to build GCC from source on a RHEL6 virtual machine, and have run into a Catch 22. That is, I need a C compiler for successful configuration. The solution seems simple enough - execute yum to solve dependencies. However, this virtual machine cannot have an Internet connection.
Does anybody have any sources for a binary or .rpm containing a pre-compiled compiler, simplifying installation? I've searched, but cannot find one. Alternatively, does a RHEL6 command exist to install a pre-compiled version of GCC? If neither are possible, what C compilers might I pursue to resolve this?
For context, here's the message I receive:
../gcc-4.7.2/configure
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking target system type... x86_64-unknown-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether ln works... yes
checking whether ln -s works... yes
checking for a sed that does not truncate output... /bin/sed
checking for gawk... gawk
checking for libitm support... yes
checking for gcc... no
checking for cc... no
checking for cl.exe... no
configure: error: in `/gcc/gcc-build':
configure: error: no acceptable C compiler found in $PATH
See `config.log' for more details.
It is not possible to compile gcc source code without any C compiler installed on your VM.
If you can transform files from your host to VM, then you have two ways:
Compile the source code on your host and copy them to your VM. Use ./configure --prefix=/<path>/<to>/<output> to specify the output directory. If your VM CPU arch is different from your host, you may want to look at cross compile.
Download gcc rpm package from a Redhat's rpm repository mirror. Search it in google and you will get an answer.
But it is always a good idea to use yum or rpm to install software in RHEL. I have some questions about your problem:
Why you don't have gcc installed on your RHEL6? It is installed by default.
What VM are you using? The best solution of your problem may be figuring out a way to get network available in your VM.
Since you don't have Internet access on your VM, you probably won't be able to use the dependency resolving yum or rpm. I'll assume you don't want to connect or can't connect the VM to the internet.
From an Internet connected system, you can download a self-contained pre-built version of GCC and the rest of the toolchain here:
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/
The IA32 GNU/Linux native compiler is here:
http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/ia32-gnu-linux
https://sourcery.mentor.com/GNUToolchain/package10871/public/i686-pc-linux-gnu/ia32-2012.09-62-i686-pc-linux-gnu.bin
You will still need to find a way to get the installer onto your VM.
Related
First of all, I'm aware of this answer, yet as it's quite vague, it didn't help me solve my problem.
I'm working on CentOS machine and as current subversion package is quite old, I needed to compile svn by myself. I've managed to do that, but trying to use one of commands I need, which is:
$ svnsync initialize [...] [...]
Resulted with the following error:
svnsync: E170000: Unrecognized URL scheme for '[url here]'
After some research, I found that I need serf to make it work, so I've installed it by using yum install libserf (I'm not sure if it's it, but name and description sound similar to what I need). Unfortunately, nothing has changed and I later came to a conclusion that maybe I need to recompile svn with serf in place.
I've downloaded subversion source and ran ./configure. Here is the output of it associated with serf:
configure: serf library configuration via pkg-config
checking for serf-2 library... no
checking for serf-1 library... no
checking was serf enabled... no
An appropriate version of serf could not be found, so libsvn_ra_serf
will not be built. If you want to build libsvn_ra_serf, please
install serf 1.3.4 or newer.
There is an argument called --with-serf, but I'm not sure how should I use it. Linking to location of serf binaries, like that:
$ ./configure --with-serf=/usr/lib64/
results with the following output:
configure: serf library configuration via pkg-config
checking for serf-2 library... no
checking for serf-1 library... no
checking was serf enabled... no
An appropriate version of serf could not be found, so libsvn_ra_serf
will not be built. If you want to build libsvn_ra_serf, please
install serf 1.3.4 or newer.
configure: error: Serf was explicitly enabled but an appropriate version was not found.
Can you give me some hints on how can I proceed with this?
I want to build openldap on linux, aix, and sun solaris. I require openldap only for use in regression tests on these machines. For this purpose I only need ldif. I want to avoid any potential licensing problems and expenses related to Oracle Berkeley DB.
I have downloaded by FTP the tar file openldap-2.4.40.tgz to a linux machine. I then ran,
tar -zxvf openldap-2.4.40.tgz
cd openldap-2.4.40
To configure the source ready for the build,
./configure --enable-ldif=yes
The log ended in;
...
checking for gethostbyaddr_r... yes
checking number of arguments of ctime_r... 2
checking number of arguments of gethostbyname_r... 6
checking number of arguments of gethostbyaddr_r... 8
checking db.h usability... no
checking db.h presence... no
checking for db.h... no
configure: error: BDB/HDB: BerkeleyDB not available
Can I get OpenLDAP built for only LDIF, or at least not depended on Oracle Berkeley DB? How?
There is no enable-ldif option anymore. You get LDIF format by default.
To disable BerkeleyDB
./configure --enable-bdb=no --enable-hdb=no
make depend
make install
For my purposes I found the --prefix option useful.
So far I have been able to build it on Linux, Solaris, and AIX.
But on AIX could only build static libraries. But that is another question.
I am trying to compile a library using android-ndk-r5 standalone toolchain and autotools. When doing a ./configure, it fails with:
$ ./configure --host=arm-linux-androideabi
...snip...
checking host system type... Invalid configuration `arm-linux-androideabi': system `androideabi' not recognized
configure: error: /bin/sh ./config.sub arm-linux-androideabi failed
Explicitly setting CC and CXX does not work either (configure says to use --host).
The NDK docs and various materials online seems to indicate that using the standalone toolchain in this manner should be possible. What is wrong here? and how can I resolve it? (besides simply ditching autoconf and going back to Android.mk)
You might need a newer config.sub and config.guess, 2010-05-20 or later.
You can get the newer config.sub and config.guess from here
I took the newest from both, but that lead to errors, so I took the mentioned ones of Peter Eisentraut's date.
You can also grab config.sub and config.guess from the Ubuntu autotools-dev package:
sudo apt-get install autotools-dev
cp /usr/share/misc/config.{sub,guess} .
How can I install gcc on a system that have not any c compiler?
this system is a linux base firewall and have not any c compiler.
I guess you a have an appliance running Linux and shell-access, but neither a package manager nor a compiler is installed.
So, you need to cross-compile gcc and the whole toolchain (at least binutils) - this is quite simple, because the ./configure scripts of gcc, binutils, gdb etc. support cross-compiling with the --target= option. So all you have to do is to find out the target architecure (uname helps) and then download, unpack the gcc sources on a linux-host and run ./configure --target=$YOUR_TARGET.
With this, you now can build a cross-compiler gcc - this still runs on your host, but produces binaries for your target (firewall appliances).
This may already be sufficient for you, a typical desktop PC is much faster than a typical appliance, so it may make sense to compile everything you need on the Desktop PC with the cross-compiler and cross-binutils.
But if you really wish to do so, you can now also use your cross-compiler to compile a gcc running on your target (set this as --host= option) and compiling for your target (set this as --target option).
You can find details about allowed host/targets and examples in the gcc documentation: http://gcc.gnu.org/install/specific.html.
It depends on the distribution, if it's based on debian or some other of the big ones you can install gcc through apt-get or similar tool.
If it's a more basic system you need to compile gcc yourself on another computer and copy it over. It will be easiest if you have another computer with the same architecture (i386, arm or x86_64 for example).
I think that you might want to compile it statically also, so that you don't have dependencies on external libraries.
How do you plan to get all the source code needed for GCC loaded onto your machine? Could you mount the ISO image onto this machine and install from there?
Since you are using Endian Firewall, see "Building a development box" at the following link:
http://alumnus.caltech.edu/~igormt/endian/tips.html
If it's a debian based distribution, you can use
sudo apt-get install gcc
Note: maybe you must change "gcc" by a specific version of the debian package.
I download the rss-glx 0.9 project's source codes to build. But the configure script complained GL library was not found!
...
checking GL/gl.h usability... yes
checking GL/gl.h presence... yes
checking for GL/gl.h... yes
checking GL/glx.h usability... yes
checking GL/glx.h presence... yes
checking for GL/glx.h... yes
checking for glNewList in -lGL... no
checking for glNewList in -lMesaGL... no
configure: error: GL library was not found.
But there are GL libraries in /usr/lib.
$ ls /usr/lib/GL*
/usr/lib/libGLcore.so.1 /usr/lib/libGL.so.180.29
/usr/lib/libGLcore.so.180.29 /usr/lib/libGLU.a
/usr/lib/libGLEW.so.1.5 /usr/lib/libGLU.so
/usr/lib/libGLEW.so.1.5.0 /usr/lib/libGLU.so.1
/usr/lib/libGL.la /usr/lib/libGLU.so.1.3.070004
/usr/lib/libGL.so.1
Anybody can tell me why?
Thanks.
Thank you, drhirsch. I have found out the reason. In my /usr/lib, libGL.so is a symbolic link to /usr/lib/nvidia/libGL.so.1.2.xlibmesa. And in /usr/lib/nvidia, there is not a libGL.so.1.2.xlibmesa but a libGL.so.xlibmesa, which is also a symbolic link to a no-existed libGL.so.1. Now I have fixed the problem and it's OK.
I don't know why there are some null symbolic links. I guess it occured when I reinstall the nvidia graphic card driver for my Debian's kernel updated from 2.6.26-1 to 2.6.26-2.
Looks like the linker wasn't able to link a test program against your GL library. (This is was configure does). Possibly a version mismatch.
What exactly has happened is written in the file 'config.log', close to the end, but before the whole envirnoment variables content. You can repeat the last unsuccessful command at the comand line and look a the error the linker throws out.
I had a similar problem once. A quick fix might be to create a symlink called libGL.so and have it point to one of the "other" libGLs
My problem was that the test program couldn't link to libXmu.so, as I found by reading config.log. Turns out on my installation, there was a libXmu.so.6, but no soft link. I did this:
ln -s /usr/lib64/libXmu.so.6 /usr/lib64/libXmu.so
and then the ./configure worked.