Building binutils with debugging mode - c

I'm trying to build binutils 2.21 source code with debugging on. My main aim is to debug objdump actually. But in order to build it I think I have to build whole package.
Unfortunately there is no debugging option on the configure file. I tried adding -g and -ggdb to CFLAGS before I configure it. However the error was:
Configuring in ./intl
configure: loading cache ./config.cache
configure: error: `CFLAGS' has changed since the previous run:
configure: former value: `-g -O2 -D__USE_MINGW_ACCESS'
configure: current value: `-g -D__USE_MINGW_ACCESS'
configure: error: in `/c/binutils-2.21/intl':
configure: error: changes in the environment can compromise the build
configure: error: run `make distclean' and/or `rm ./config.cache' and start over
make[1]: *** [configure-intl] Error 1
make[1]: Leaving directory `/c/binutils-2.21'
make: *** [all] Error 2
I tried "make clean" and "make distclean" but I'm receiving the same error. Actually according to former CFLAGS it had -g option on before but when I try to open objdump.exe in gdb it says
Reading symbols from c:\binutils-2.21\binutils/objdump.exe...
(no debugging symbols found)...done.
Thank you in advance.

Yes I've tried a lot. As I said -g tag was on to gcc. However makefile saves all debugging enabled binaries to binutils.libs\ directory. So when I run binutils.libs\objdump.exe under gdb it was fine. Thanks for your answer though.

Related

Gtk3 - unresolved inclusion

I am using Ubuntu 18.04.4, and Eclipse 2019-12 (4.14.0) and I try to create a little C application with the help of Glade for the user interface.
Adding the following header files in C results in "unresolved inclusion" error:
#include <gtk/gtk.h>
#include <gtk/gtkx.h>
I have searched and tried in many ways to fix this, but unfortunately I didn't manage (I am new to linux/eclipse). The most easy solution seems to be a package called "Pkg-config" that knows itself how to add the gtk package, but unfortunately, this version of Eclipse does not support it.
The compiler sends the following error:
10:22:19 **** Incremental Build of configuration Debug for project MyTestProject ****
make all
Building file: ../src/MyTestProject.c
Invoking: GCC C Compiler
gcc -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"src/MyTestProject.d" -MT"src/MyTestProject.o" -o "src/MyTestProject.o" "../src/MyTestProject.c"
../src/MyTestProject.c:17:10: fatal error: gtk/gtk.h: No such file or directory
#include <gtk/gtk.h>
^~~~~~~~~~~
compilation terminated.
src/subdir.mk:18: recipe for target 'src/MyTestProject.o' failed
make: *** [src/MyTestProject.o] Error 1
"make all" terminated with exit code 2. Build might be incomplete.
10:22:19 Build Failed. 3 errors, 0 warnings. (took 466ms)
Any ideas how I can solve this? I mention that libgtk-3-dev is installed on my system and it appears inside the "includes" folder.

"fatal error: bits/libc-header-start.h: No such file or directory" while compiling HTK

I'm getting the following issue when trying to run make on the HTK library:
(cd HTKLib && make HTKLib.a) \
|| case "" in *k*) fail=yes;; *) exit 1;; esac;
make[1]: Entering directory '/home/william/speech/htk/HTK-3.4.1/htk/HTKLib'
gcc -m32 -ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH="x86_64"' -Wall -Wno-switch -g -O2 -I. -DPHNALG -c -o HGraf.o HGraf.c
In file included from HShell.h:40:0,
from HGraf.c:54:
/usr/include/stdio.h:27:10: fatal error: bits/libc-header-start.h: No such file or directory
#include <bits/libc-header-start.h>
^~~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
<builtin>: recipe for target 'HGraf.o' failed
make[1]: *** [HGraf.o] Error 1
make[1]: Leaving directory '/home/william/speech/htk/HTK-3.4.1/htk/HTKLib'
Makefile:96: recipe for target 'HTKLib/HTKLib.a' failed
make: *** [HTKLib/HTKLib.a] Error 1
I'm unsure what to do about this error. The libc-header-start.h file is present on my system:
$ find /usr -name libc-header-start.h
/usr/include/x86_64-linux-gnu/bits/libc-header-start.h
Running gcc -H -fsyntax-only /usr/include/stdio.h appropriately returns
. /usr/include/x86_64-linux-gnu/bits/libc-header-start.h
.. /usr/include/features.h
... /usr/include/x86_64-linux-gnu/sys/cdefs.h
etc.
Also, compiling and running a sanity-check C file works fine (simply executing printf("hello!"); in its main method).
Apologies if this is a well-known error - my experience with C libraries stops at compiling and installing them using make.
UPDATE
Per the accepted answer below I executed sudo apt-get install gcc-multilib to install the missing 32 bit libraries.
Afterwards I got an error with a similar cause: "/usr/bin/ld: cannot find -lX11" error when installing htk. I resolved this by executing sudo apt-get install libx11-dev:i386 libx11-dev to retrieve the missing 32 bit library.
The -m32 is telling gcc to compile for a 32-bit platform. On a 64-bit machine, gcc normally only comes with 64-bit libraries. You have two options:
Install 32-bit headers and libraries. Here's how you'd do this on Ubuntu.
Run this command:
sudo apt-get install gcc-multilib
Compile for 64-bit instead. Modify this line in the file named configure:
CFLAGS="-m32 -ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH=\"$host_cpu\"' $CFLAGS"
Delete -m32, giving you:
CFLAGS="-ansi -D_SVID_SOURCE -DOSS_AUDIO -D'ARCH=\"$host_cpu\"' $CFLAGS"
Run ./configure, then make clean, then make
However, I would recommend against this approach. The library authors went out of their way to make this build for 32 bits on a 64 bit system, and I can't guarantee that it will work correctly if you do this. (It does compile, though.)
Below is one way to debug and fix this issue. Since most linux installations differ in one way or another, YMMV.
Find which package installed libc-header-start.h.
$ dpkg -S libc-header-start.h
libc6-dev:amd64: /usr/include/x86_64-linux-gnu/bits/libc-header-start.h
On a working system, /usr/include/bits is a symlink to /usr/include/x86_64-linux-gnu/bits. Running dpkg search gives us:
$ dpkg -S /usr/include/bits
libc6-dev-i386: /usr/include/bits
Installing libc6-dev-i386 creates the symlink and the error is addressed.
However, subsequently I ran into a linker error with the linker not being able to find libgcc (-lgcc). Apparently Linux default linker needs libgcc in most cases. Further debugging the issue with linker verbosity enabled lead me to missing lib32gcc-10-dev package.
In short, unless a very controlled build environment is desired, just install gcc-multilib package when using -m32 (needed for gcc or clang). For C++, g++-multilib is also required.

collect2.exe: error: ld returned 1 exit status in eclipse cdt

I'm a beginner of programming. I am using Eclipse CDT for C programming. When I build any program, the console window shows the below message. Please tell me a specific way so that I could solve this problem.
Console window:
Info: Configuration "Debug" uses tool-chain "MinGW GCC" that is unsupported on this system, attempting to build anyway.
Info: Internal Builder is used for build
gcc -O0 -g3 -Wall -c -fmessage-length=0 -o test.o "..\\test.c"
gcc -o test.exe test.o
c:/mingw/bin/../lib/gcc/i686-pc-mingw32/4.9.2/../../../../i686-pc-mingw32/bin/ld.exe: cannot open output file test.exe: Permission denied
collect2.exe: error: ld returned 1 exit status
00:33:35 Build Finished (took 2s.385ms)
USUALLY(in my experience), LD errors result from you not including the libraries or linkers necessary. Go to your project, right click, select properties, under C build go to settings, GCC C compiler and includes and add the libraries.
Your operating system simply does not allow to modify a file while it is in use, so the compilation fails, because compiler can't remove the old executable and place a new one. To solve this, simply restart eclipse program.

GCC as m68k cross-compiler

I am trying to recompile binutils and GCC as a cross-compiler for m68k architecture. I am following these instructions:
http://darkdust.net/writings/megadrive/crosscompiler
However, the process keeps failing on one part or another. I have tried with binutils 2.16.1 and gcc 3.4.6, binutils 2.15 and gcc 3.4.2 and binutils 2.15 and gcc 3.4.6.
This last attempt fails when running "make" on gcc, after making and installing binutils. It gives the following error:
gcc -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-
prototypes -Wmissing-prototypes -pedantic -Wno-long-long -DHAVE_CONFIG_H
-I. -I. -I../../gcc-3.4.2/gcc -I../../gcc-3.4.2/gcc/. -I../../gcc-
3.4.2/gcc/../include \
-DTARGET_MACHINE=\"m68k-coff\" \
-c ../../gcc-3.4.2/gcc/collect2.c -o collect2.o
In file included from /usr/include/fcntl.h:289:0,
from ../../gcc-3.4.2/gcc/system.h:214,
from ../../gcc-3.4.2/gcc/collect2.c:30:
In function ‘open’,
inlined from ‘collect_execute’ at ../../gcc-3.4.2/gcc/collect2.c:1535:20:
/usr/include/x86_64-linux-gnu/bits/fcntl2.h:50:4: error: call to
‘__open_missing_mode’ declared with attribute error: open with O_CREAT or
O_TMPFILE in second argument needs 3 arguments
__open_missing_mode ();
^
Makefile:1364: recipe for target 'collect2.o' failed
make[1]: *** [collect2.o] Error 1
make[1]: Leaving directory '/home/gabriel/src/gcc-build/gcc'
Makefile:23339: recipe for target 'all-gcc' failed
make: *** [all-gcc] Error 2
I don't expect to fix this error, but does anyone know of a combination of binutils and gcc release that work? Should I be using a certain version of gcc to recompile gcc successfuly?
Thanks for any insight you may have on this!
EDIT:
My linux has GCC 5.4.0 so I just downloaded the 5.4.0 source to try and rebuild that for m68k cross-compiling. I now get the following error when running "make" on the gcc source:
*** Configuration m68k-unkown-coff not supported
What could be the cause of this? Is it because I need an older version of GCC? (the binutils version i'm using definately supports the m68k target). The tutorial I'm using always defines "--target=m68k-coff", should that instead be "--target=m68k-unkown-coff"?
EDIT 2:
So I tried compiling for m68k-elf but now I get this error:
checking for m68k-elf-gcc... /home/gabriel/src/gcc-build/./gcc/xgcc -B/home/gabriel/src/gcc-build/./gcc/ -B/opt/m68k/m68k-elf/bin/ -B/opt/m68k/m68k-elf/lib/ -isystem /opt/m68k/m68k-elf/include -isystem /opt/m68k/m68k-elf/sys-include
checking for suffix of object files... configure: error: in `/home/gabriel/src/gcc-build/m68k-elf/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
I ran download_prerequisites before building so it should not be a problem with the MPC library. Any idea how to move on? I need assembler only so I don't mind what the format of the object files is. Thanks!
I used to do pretty much what you are doing right now.
My advice is to use crosstool-ng (http://crosstool-ng.github.io), as it does pretty much everything in an automated manner.
If you are studying m68k assembly, I used to host a modified version of gcc-explorer by Matt Godbolt (https://godbolt.org/). You can find a runnable docker image here (https://hub.docker.com/r/esantoro/acso-explorer/) and some more details here (https://znpy.wordpress.com/2017/05/08/decommisioning-acso-explorer-santoro-tk/)
Hope it helps,
znpy
you can build most versions with a current Linux. To install the prerequisites have a look at https://github.com/bebbo/amiga-gcc
unpack the gcc archive, e.g. to /opt/cross/gcc-6.5.0
create a separate build folder, e.g. /opt/cross/xcc-6.5.0 - never build inside gcc's source folder!
create the prefix folder, that's where binaries are installed to, e.g. /opt/cross/gcc65
ensure that these folders exist and are writable, then
configure from within that build folder using an absolute path for configure
cd /opt/cross/xcc-6.5.0/
/opt/cross/gcc-6.5.0/configure --target=m68k-elf --program-prefix=m68k-elf- --enable-languages=c,c++ --prefix=/opt/cross/gcc65 --disable-libssp --disable-nls --disable-multilib
make all-gcc
make install-gcc
I'm also running the compiler explorer for 68k gccs at https://franke.ms/cex/

HAWQ installation on Redhat

I am installing HAWQ on RedHat servers provisioned on Amazon EC2. I already have HDP 2.3 setup on the cluster.
I have cloned HAWQ from Github.
First I run ./configure --prefix=/opt/hawq.
In the second step, I run make.
The dependencies are compiling correctly when I run make from the root folder of incubator-hawq. The following error occours when make moves to compiling from src folder in the root directory (incubator-hawq):
make[2]: Entering directory `/root/incubator-hawq/src/port'
gcc -O3 -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith -Wendif-labels -Wformat-security -fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -I/usr/include/libxml2 -I../../src/port -DFRONTEND -I../../src/include -D_GNU_SOURCE -I/root/incubator-hawq/depends/libhdfs3/build/install/usr/local/hawq/include -I/root/incubator-hawq/depends/libyarn/build/install/usr/local/hawq/include -c -o copydir.o copydir.c
In file included from copydir.c:25:0:
../../src/include/storage/fd.h:61:23: fatal error: hdfs/hdfs.h: No such file or directory
#include "hdfs/hdfs.h"
^
compilation terminated.
make[2]: *** [copydir.o] Error 1
make[2]: Leaving directory `/root/incubator-hawq/src/port'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/root/incubator-hawq/src'
make: *** [all] Error 2
I know the compiler cannot find hdfs/hdfs.h, but as the dependencies (libhdfs3) compiled successfully, I don't understand why the particular file isn't found. Please help if somebody has come across the same problem as I am pretty much stuck here.
Could you check file /root/incubator-hawq/depends/libhdfs3/build/install/usr/local/hawq/include/hdfs/hdfs.h exists?
If not, then it should be build defect, please open defect to hawq team or email to: dev#hawq.incubator.apache.org. Thanks.
Do you have a folder in incubator-hawq/depends/libhdfs3/build/installafter make?
The problem seems that libhdfs3 dependency is not successfully built. There are some possible reasons for that: using a old version gcc(<4.7), configuration error of libhdfs3.
To test my words, you could try this:
cd incubator-hawq/depends/libhdfs3
mkdir build_debug && cd build_debug
cmake ..
make
If you could successfully do that, I think there is another reason for your problem. In this case, could you paste the information with more building lines?
Another possible reason is that you use different configuration prefix. In this case, you should run make distclean before another configuration.

Resources