I am attempting to compile a simulator for Y86-64 code on Linux.I have already rewritten the makefile but it turned out like below.It said "undefined reference for 'matherr'".(Looks like it connects with gcc when linking)
(cd pipe; make all GUIMODE=-DHAS_GUI TKLIBS="-L/usr/lib/ -ltk8.5 -ltcl8.5" TKINC="-I/usr/include/tcl8.5 ")
make[1]: 进入目录“/home/gongchen/桌面/ICS/archlab-handout/sim/pipe”
# Building the pipe-std.hcl version of PIPE
../misc/hcl2c -n pipe-std.hcl < pipe-std.hcl > pipe-std.c
gcc -Wall -O2 -I/usr/include/tcl8.5 -I../misc -DHAS_GUI -o psim psim.c pipe-std.c \
../misc/isa.c -L/usr/lib/ -ltk8.5 -ltcl8.5 -lm
/tmp/cchKTZy7.o:(.data.rel+0x0)：对‘matherr’未定义的引用
collect2: error: ld returned 1 exit status
Makefile:42: recipe for target 'psim' failed
make[1]: *** [psim] Error 1
make[1]: 离开目录“/home/gongchen/桌面/ICS/archlab-handout/sim/pipe”
Makefile:28: recipe for target 'all' failed
make: *** [all] Error 2
gcc -Wall -O2 -I/usr/include/tcl8.5 -I../misc -DHAS_GUI -o psim psim.c pipe-std.c \
../misc/isa.c -L/usr/lib/ -ltk8.5 -ltcl8.5 -lm
/tmp/cchKTZy7.o:(.data.rel+0x0)：对‘matherr’未定义的引用
You are linking and getting an undefined reference error to matherr.
It looks like matherr is part of SVID math library. According to the matherr(3) man page the symbol is no longer present in Glibc 2.27 or above.
DESCRIPTION
Note: the mechanism described in this page is no longer supported by
glibc. Before glibc 2.27, it had been marked as obsolete. Since
glibc 2.27, the mechanism has been removed altogether. New
applications should use the techniques described in math_error(7) and
fenv(3). This page documents the matherr() mechanism as an aid for
maintaining and porting older applications.
The math_error(7) man page says that you should do the following to check for errors:
set errno to zero
call feclearexcept(FE_ALL_EXCEPT);
After the math calculation completes you should check the following for non-zero value to indicate error:
errno
fetestexcept(FE_INVALID | FE_DIVBYZERO | FE_OVERFLOW | FE_UNDERFLOW);
Since you are a guy or gal trying to use the program (and not a maintainer) I suggest two courses of actions. The strategy is to use a distro where things just work, and punt to the Y86 maintainer to fix it.
First, use a different, older distro that provides Glibc 2.26 or early. Something like Debian 8 (Glibc 2.19) or Fedora 25 (Glibc 2.24) should do just fine.
Second, file a bug report against Y86 project. The Y86 maintainers need to fix the problem, not students trying to learn the class material.
My classmates have a way to solve this problem: comment the code related to matherr, like the code in the picture. And the GUI mode works. 好厉害!
Related
I am compiling qtwebengine 5.15.2 using Yocto on Ubuntu 18.04.
I am getting the below error:
[18991/20786] STAMP v8_snapshot/obj/v8/run_gen-regexp-special-case.stamp
[18992/20786] LINK v8_snapshot/torque
FAILED: v8_snapshot/torque
/home/aws-mjamal/test/build-am437x-evm-test/tmp/hosttools/g++ -pie -Wl,--fatal-warnings -Wl,--build-id=sha1 -fPIC -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,-z,defs -Wl,--as-needed -m32 -pie -Wl,--disable-new-dtags -Wl,-O2 -Wl,--gc-sections -o "v8_snapshot/torque" -Wl,--start-group #"v8_snapshot/torque.rsp" -Wl,--end-group -ldl -lpthread -lrt
v8_snapshot/obj/v8/torque_base/torque_base_jumbo_3.o:(.data.rel.ro._ZTVN2v88internal6torque13NullStreambufE[_ZTVN2v88internal6torque13NullStreambufE]+0x18): undefined reference to `std::basic_streambuf<char, std::char_traits<char> >::seekoff(long, std::_Ios_Seekdir, std::_Ios_Openmode)'
collect2: error: ld returned 1 exit status
[18993/20786] CXX v8_snapshot/obj/v8/third_party/inspector_protocol/crdtp/crdtp_jumbo_1.o
[18994/20786] CXX v8_snapshot/obj/v8/src/inspector/inspector/inspector_jumbo_1.o
[18995/20786] CXX v8_snapshot/obj/v8/src/inspector/inspector/inspector_jumbo_3.o
[18996/20786] CXX v8_snapshot/obj/v8/src/inspector/inspector/inspector_jumbo_2.o
[18997/20786] CXX v8_snapshot/obj/v8/src/inspector/inspector/inspector_jumbo_4.o
ninja: build stopped: subcommand failed.
Well, to start with, seekoff is a virtual protected method.
https://en.cppreference.com/w/cpp/io/basic_streambuf
https://en.cppreference.com/w/cpp/io/basic_streambuf/pubseekoff
Calls seekoff(off, dir, which) of the most derived class
The base class version of this function has no effect. The derived
classes may override this function to allow relative positioning of
the position indicator.
So, your chosen configure answers opted to not build the source file where seekoff is actually implemented for that object.
Qt supports X11 with Ubuntu 18.04.
https://doc.qt.io/qt-5/linux.html
Others have had issues trying to build qtwebengine on Ubuntu 18.04 due to a very old libopus being native on that platform.
https://askubuntu.com/questions/1355519/opus-1-3-1-on-ubuntu-18-04-w-preinstalled-opus-0-5-2
You didn't list your brand of board, but here are the instructions from one vendor.
https://developer.toradex.com/knowledge-base/how-to-set-up-qt-creator-to-cross-compile-for-embedded-linux#boot-to-qt-for-embedded-linux
Is this the only error you got?
Web engine is a beast. Everybody deletes it from embedded systems projects because of this. The error you are focusing on might have nothing to do with the real problem. Embedded systems builds of Qt notoriously run out of memory building WebEngine, especially if a person doesn't use -j1 to limit to a single processor. It can consume 8GB per process. If you didn't limit the number of jobs to 1 and have a 4-core machine then it tried to use 32GB and you probably didn't have that. Somewhere further back in the log you got an out of memory error and it didn't fatal out right there.
Do you actually need qtwebengine or are you just building it to build everything?
Almost every embedded system does what this one did.
https://community.toradex.com/t/apalis-imx8qm-b2qt-qtwebengine-build-error/11441/3
It's a resource pig. Lots of embedded systems don't have enough under the hood to even think about running it.
So, one of the following should work for you:
If you don't need webengine start a fresh build in a clean directory tree and remove it from the configuration.
If you do really need it start a fresh build in a clean directory tree and use -j1 on the make/ninja command to limit to one CPU/thread so you don't exhaust memory.
Odds are you won't be lucky enough to have torque_base_jumbo_3 directly use seekoff(). Qt likes to bury stuff like that in hidden private classes. You will have to identify what objects (if you can) that are derived from or contain something derived from std::basic_streambuf. With templates using templates sometimes that can be impossible. Use grep (or a grep-like tool) to go down the entire source tree identifying which source files made use of seekoff(). That should be a small number. Next, search your build log to see what happened to each of those files. Did they all build clean or are some of them not getting built at all?
https://blog.kitware.com/cmake-building-with-all-your-cores/
ninja does not require a –j flag like GNU make to perform a parallel
build. It defaults to building cores +2 jobs at once
The only "quick fixes" for your problem is to take webengine out if you don't need it and limiting ninja to 1.
Oh! Also check the X11 link I posted for the minimum compiler version for Ubuntu 18.04. You could be getting bit by that.
I've mainly worked on Windows, so I'm quite unfamiliar with less common issues under Linux.
Here's the error I'm getting when dub tries to link my application:
/usr/bin/ld: .dub/obj/pixelperfectengine_pixelperfecteditor.o: undefined reference to symbol 'inflateEnd'
//lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
Error: /usr/bin/gcc failed with status: 1
/usr/bin/ldc2 failed with exit code 1.
I've an image handling library as a dependency, which is required for the application, and it (obviously) uses zlib for *.png compression/decompression. I've installed zlib1g-dev for Ubuntu, but did not fix my issues, and the same exact code compiles without any issues under Windows.
You need to link in zlib, as mentioned before.
I would recommend to do so via the "libs" array (see this page: https://dub.pm/package-format-json.html). The advantage of using libs over lflags is that libs will try to use pkg-config, which is a generic way to get linker / compile flags for C[++] libraries on POSIX. It works on Linux and Mac OSX. If pkg-config is not found, dub will just default to do what lflags would do in the first place.
Here's an example from my own project: https://github.com/Geod24/libsodiumd/blob/9b397645e2fc3ca502acb58e1b4631d3faf094e2/dub.json
/lib/x86_64-linux-gnu/libz.so.1: error adding symbols: DSO missing from command line
This error is telling you that you must add -lz to command line. I don't know what dub is, but somehow you must convince it to add -lz to the link command it constructs.
It's probably enough to add -lz to the lflags in your dub file.
I ran across this error while trying to compile the NMR software modelfree4.20 for Linux. The distribution comes with a MakeFile, and so I type "make" in the modelfree folder to try and compile it, and after it writes a few files I get the following error:
/usr/bin/ld: -f may not be used without -shared
collect2: error: ld returned 1 exit status
Makefile:74: recipe for target 'modelfree4' failed
make: *** [modelfree4] Error 1
I have no idea what "-f may not be used without -shared" means or what it is trying to tell me to fix? I don't see anything with a -f or -shared in the MakeFile when I open it up, and I didn't specify any options when I ran "make."
Any help on this is greatly appreciated!
I think I could see 2 possibilities.
If the Makefile is generated by a configure script, you may need to run it again. You may have picked up a bad Makefile due to misconfiguration. Possibly you need to run the autotools to generate the configure script again.
It's possible that there is some system- or session-specific LDFLAGS environment variable interfering with linking. Try unset LDFLAGS?
I'm using ubuntu 14.04 and i'm trying to install the UHD device from the github but i'm getting an error that won't allow it to build.
checking whether the Boost::System library is available... yes
checking for exit in -lboost_system... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Regex library is available... yes
checking for exit in -lboost_regex... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: executing depfiles commands
willie.thompson#seb215-wks07:~/redhawk/USRP_UHD/cpp$ make
CXX USRP_UHD-USRP_UHD.o
CXX USRP_UHD-USRP_UHD_base.o
CXX USRP_UHD-main.o
CXX USRP_UHD-template_impl.o
CXXLD USRP_UHD
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
seb215-wks07:~/redhawk/USRP_UHD/cpp$
Am I doing something wrong here or is the issue with Ubuntu?
For now, you can edit the Makefile.am file to fix this. At the end of the USRP_UHD_LDADD line, add -luuid, then you should be able to rebuild it successfully.
The version of g++ used in Ubuntu14 is stricter than the version used in CentOS6. Luckily, g++ is providing a good hint about what the issue is.
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
It is basically saying "What you want is here in libuuid.so.1 but you didn't put it on the command line so I'm refusing to use it". While in CentOS6 g++ is less strict and links regardless, assuming that is what you wanted.
You have two options, one is the easy way out that works quick, one is a better long term solution:
1) Run make again in verbose mode, this will show you exactly what calls are being made and you can fix the offending call. Lets do that below:
make V=1
< ... a bunch of calls to g++ that work fine or nothing if these have already run prior .... >
g++ -Wall -D__x86_64__ -D__linux__ -D__OSVERSION__=2 -DENABLE_EVENTS=1 -I/var/lib/redhawk/core/include -I/var/lib/redhawk/core/include/ossie -I/var/lib/redhawk/core/share/idl -pthread -I/usr/include -I/var/lib/redhawk/core/include/frontend -I/var/lib/redhawk/core/include/redhawk -I/var/lib/redhawk/core/include/bulkio -I/var/lib/redhawk/core/include/ossie -g -O2 -Wall -o USRP_UHD USRP_UHD-USRP_UHD.o USRP_UHD-USRP_UHD_base.o USRP_UHD-main.o USRP_UHD-template_impl.o -L/var/lib/redhawk/core/lib64 -lossiecf -lossieidl -lCOS4 -lomniDynamic4 -lomniORB4 -lomnithread -L/usr/lib/x86_64-linux-gnu -lboost_thread -lboost_regex -lboost_system -L/var/lib/redhawk/core/lib64 -lfrontend-2.2.0 -lfrontendInterfaces -lbulkio-1.10 -lbulkioInterfaces -luhd -llog4cxx
/usr/bin/ld: USRP_UHD-USRP_UHD.o: undefined reference to symbol 'uuid_generate_random##UUID_1.0'
//lib/x86_64-linux-gnu/libuuid.so.1: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make: *** [USRP_UHD] Error 1
Okay, so now we have the long ugly g++ call, we simply need to add "-luuid" to the list of linked libraries so we can tack that on at the end and voila! It will return without error. Note that we simply hand ran 1 of the g++ calls so for good measure run Make again in case there are any additional build steps; in this case there are not, it will simply say "nothing to be done"
2) A better fix! So the build files clearly need some fixing.
If we take a look at the configure.ac we see that there are calls like this one:
PKG_CHECK_MODULES([LIBUHD], [uhd >= 3.5.3])
What this is doing is saying "Check pkg-config for the module uhd, ensure it is of version >= 3.5.3 and store any build related info in a variables prefixed with LIBUHD so that I can use it later". Sounds like what we want. We can check to see if pkg-config is aware of libuuid by viewing all of the packages it knows about:
pkg-config --list-all
That will show us everything pkg-config knows about and we see that it is aware of uuid. So, lets add a line to configure.ac right below the check for the UHD driver and see what affect that has. My line looks like this:
PKG_CHECK_MODULES([LIBUUID], [uuid])
I put no version constraint. Okay, so now in order for that change to be incorporated we need to rerun the reconf script and then we can see the configure output.
./reconf
./configure
<....a bunch of stuff....>
checking for LIBUUID... yes
<....a bunch more stuff....>
That's new! We are now checking for the uuid library in our configure call and if you take a look at the config.log file, new variables have been added:
LIBUUID_CFLAGS='-I/usr/include/uuid '
LIBUUID_LIBS='-luuid '
Alright, almost there! Take a look at the Makefile.am file. These variables are used there and dictate the calls to g++. Append our newly made LIBUUID_CFLAGS and LIBUUID_LIBS variables to the end of the USRP_UHD_LDADD and USRP_UHD_CXXFLAGS variables like I've done below.
USRP_UHD_LDADD = $(PROJECTDEPS_LIBS) $(BOOST_LDFLAGS) $(BOOST_THREAD_LIB) $(BOOST_REGEX_LIB) $(BOOST_SYSTEM_LIB) $(INTERFACEDEPS_LIBS) $(redhawk_LDADD_auto) $(LIBUHD_LIBS) $(LIBUUID_LIBS)
USRP_UHD_CXXFLAGS = -Wall $(PROJECTDEPS_CFLAGS) $(BOOST_CPPFLAGS) $(INTERFACEDEPS_CFLAGS) $(redhawk_INCLUDES_auto) $(LIBUHD_FLAGS) $(LIBUUID_CFLAGS)
Since we've changed the Makefile.am files, we need to rerun ./configure. Rule of thumb is that ./reconf creates your configure script from the configure.* files and ./configure creates the Makefile's from your Makefile.* files so if you edit a downstream file you need to rerun the upstream script.
Alright, now that we've done that things should work! We've added a system check for libuuid via pkg-config using the configure.ac file, stored the outcome in a variable and used that in our makefile template.
None of this is really unique to redhawk so if you'd like more information there is loads of documentation on the autotools build system and pkg-config.
I'm actually reading the LFS book (version 7.1) and I'm blocked at page 53. Trying to compile gcc, I tried the following command:
./configure --target=$LFS_TGT --prefix=$LFS/build/gcc-build --disable-nls\
--disable-shared --disable-multilib --disable-decimal-float --disable-threads\
--disable-libmudflap --disable-libssp --disable-libgomp --disable-libquadmath\
--disable-target-libiberty --disable-target-zlib\
--enable-languages=c\
--without-ppl --without-cloog\
--with-mpfr-include=$LFS/source/mpfr/src
--with-mpfr-lib=$LFS/source/mpfr/src/.libs\
--with-gmp-include=/mnt/LFS/source/gmp\
--with-gmp-lib=/mnt/LFS/source/gmp/.libs\
--with-mpc-include=/mnt/LFS/source/mpc/src\
--with-mpc-lib=/mnt/LFS/source/mpc/src/.libs
to run the configure script of gcc (of course I already compiled mpfr, mpc and gmp as well).
But once I launch:
make -j4
I get the following error:
checking for suffix of object files... configure: error: in `/mnt/LFS/source/gcc-4.6.2/x86_64-lfs-linux-gnu/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
make[1]: *** [configure-target-libgcc] Error 1
I tried to google for it and tried the solutions I found but nothing worked. Does anyone know why I get this error?
This issue is caused by dyanmic link library path issue when the test programs try to link against libmpc/libmpfr/libgmp.
Append below environment variable to allow ld link against the correct so file:
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/path/to/mpc/lib/
Then try build gcc again.
"Building GCC is not trivial, but is not difficult if you follow the instructions carefully.
Many people rush into trying to build it without reading the installation docs properly and make one or more of these common mistakes:
do not run ./configure from gcc src dir (this is not supported) => you need to run configure from outside the gcc source directory
Note: if GCC links dynamically to the prerequisite libs (GMP/MPFR/MPC) then the shared libraries must be in the dynamic linker's path (LD_LIBRARY_PATH), both when building gcc and when using the installed compiler."
Simple example (without dynamic link to GMP/MPFR/MPC):
tar xzf gcc-4.8.0.tar.gz
cd gcc-4.8.0
./contrib/download_prerequisites
cd ..
mkdir objdir
cd objdir
$PWD/../gcc-4.8.0/configure --prefix=/opt/gcc-4.8.0
make
make install
Sources:
Advogato Doc -
GNU Doc
This error message can arise from a number of different reasons. The best way to figure out which one is to check the logfile '/home/manu/gcc/gcc/i686-pc-linux-gnu/libgcc/config.log' in the example below. Or in the original posters case '/mnt/LFS/source/gcc-4.6.2/x86_64-lfs-linux-gnu/libgcc' and look for the last error line.
Quoting GCC FAQ: http://gcc.gnu.org/wiki/FAQ#configure_suffix
Like any of the GNU projects, GCC is using the GNU autotools to
commonly configure the compilation for the specifics of the build
system. The configure script thereby uses small test programs -
usually called conftest.c - to test if certain functions and/or
features are available. If the compilation of such a test program
fails, you'll see an error message like:
checking for suffix of object files... configure: error: in
`/home/manu/gcc/gcc/i686-pc-linux-gnu/libgcc': configure: error:
cannot compute suffix of object files: cannot compile See `config.log'
for more details. make[2]: *** [configure-stage1-target-libgcc] Error
1 make[2]: Leaving directory `/home/manu/gcc/gcc'
This error message is quite misleading and frequently the problem has
nothing to do with the message. You have to check the file
'config.log' in the directory where the error occurred. In the example
above, you would have to check the 'config.log' file in the directory
'/home/manu/gcc/gcc/i686-pc-linux-gnu/libgcc'. There might be several
test programs that failed during the configuration, but some of these
failures are non-critical. Check for the last error entry in the file.
Common causes for this error message are:
Required libraries for the GCC build are missing, specifically MPFR,
GMP and MPC. If installed as shared libraries they must be in the
runtime linker's search path so they can be found. Please, follow the
instructions in the answer to Why does my ./configure and make fail?
The compiler crashed. For example, if there is an error such as
'conftest.c: internal compiler error:', this indicates a bug in the
compiler. If you are using an unmodified version of GCC, please follow
the procedure to report the bug.
This happens while creating a cross-compiler.
It's not referring to the top-level config.log, but $LFS_TGT/libgcc/config.log.
For me, in there, it says:
configure:3566: /foo/gcc/build/./gcc/xgcc -B/foo/gcc/build/./gcc/ -B/opt/gcc-cross-11.1.0/aarch64-none-elf/bin/ -B/opt/gcc-cross-11.1.0/aarch64-none-elf/lib/ -isystem /opt/gcc-cross-11.1.0/aarch64-none-elf/include -isystem /opt/gcc-cross-11.1.0/aarch64-none-elf/sys-include -o conftest -g -O2 conftest.c >&5
conftest.c:9:10: fatal error: stdio.h: No such file or directory
9 | #include <stdio.h>
| ^~~~~~~~~
compilation terminated.
configure:3569: $? = 1
configure:3782: checking for suffix of object files
configure:3804: /foo/gcc/build/./gcc/xgcc -B/foo/gcc/build/./gcc/ -B/opt/gcc-cross-11.1.0/aarch64-none-elf/bin/ -B/opt/gcc-cross-11.1.0/aarch64-none-elf/lib/ -isystem /opt/gcc-cross-11.1.0/aarch64-none-elf/include -isystem /opt/gcc-cross-11.1.0/aarch64-none-elf/sys-include -c -g -O2 conftest.c >&5
/foo/gcc/build/./gcc/as: line 106: exec: -E: invalid option
exec: usage: exec [-cl] [-a name] [command [arguments ...]] [redirection ...]
configure:3808: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "GNU C Runtime Library"
| #define PACKAGE_TARNAME "libgcc"
| #define PACKAGE_VERSION "1.0"
| #define PACKAGE_STRING "GNU C Runtime Library 1.0"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL "http://www.gnu.org/software/libgcc/"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3822: error: in `/foo/gcc/build/aarch64-none-elf/libgcc':
configure:3824: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
Was your logfile similar?
It's my belief that the gcc compilation/installation process will take the various includes, run them through fixincludes to fix problems and tailor them to the target arch. The expected file is not present.
Referring to the Prerequisites page, I believe this section is relevant (emphasis mine):
C standard library and headers
In order to build GCC, the C standard library and headers must be present for all
target variants for which target libraries will be built (and not only the variant
of the host C++ compiler).
This affects the popular ‘x86_64-pc-linux-gnu’ platform (among other multilib
targets), for which 64-bit (‘x86_64’) and 32-bit (‘i386’) libc headers are usually
packaged separately. If you do a build of a native compiler on ‘x86_64-pc-linux-gnu’,
make sure you either have the 32-bit libc developer package properly installed (the
exact name of the package depends on your distro) or you must build GCC as a 64-bit
only compiler by configuring with the option --disable-multilib. Otherwise, you may
encounter an error such as ‘fatal error: gnu/stubs-32.h: No such file’
I believe that the solution is to obtain headers for the TARGET platform.
The problem is the assembler, "as" is missing. Build and install binutils for the target first.
In my case it was:
export LD_LIBRARY_PATH=/usr/mpc-082/lib:/usr/gmp501/lib:/usr/libelf0812/lib
Whereas each of the above library is the destination of what additional libraries you installed appended with /lib at the end.
Example: Lib-MPC:
1) Downloaded onto /usr/src/libmpc-src
2) cd into /usr/src/mpc-082
3) ../configure --prefix=/usr/mpc-082
4) make
5) make install
6) once installed, verify that you have the new libs installed under /usr/mpc-082-lib
7) add it to your LD_LIBRARY_PATH by doing:
export LD_LIBRARY_PATH=/usr/mpc-082/lib:$LD_LIBDADY_PATH
8) Repeat the same with your LibELF, and LibGMP
9) Go back and compile your GCC, should work after this.
Cheers
H