Ok so I think this is probably out of the ballpark for most people here (including me :P ) but here's my problem...
I am trying to get together a basic compiling toolchain for an AppleTV 3rd gen. After a very long time of digging through archives and source code I got a decent set of tools together. (csu, gdb, gcc, headfile, ldid, real-libgcc!, make, odcctools, uuid, file, rsync, autoconf, gawk, python, coreutils, inetutils, git, less, nano, gettext) and while most of them are outdated they still operate decently. All except for gcc. Great, eh? So my problem is whenever I compile ANY C code, even something as simple as
#include <stdio.h>
int main() {
printf("Hello World!\n");
return 0;
}
it will always return Killed: 9, I don't understand why it would do this but I do know that it means the program was killed with the signal 9 which terminates a process instantly no matter what. However I am very new to C in general and any help would be appreciated.
Thanks in advance,
A\\/.
P.S here is the output from uname -a
Darwin Apple-TV 14.0.0 Darwin Kernel Version 14.0.0: Fri Jan 29 18:51:13 PST 2021; root:xnu-2784.40.6~93/MarijuanARM_S5L8947X AppleTV3,2 arm J33iAP Darwin
Related
Meet my
$ uname -a
Linux hostmachine 4.1.2-2-ARCH #1 SMP PREEMPT Wed Jul 15 08:30:32 UTC 2015 x86_64 GNU/Linux
I'm trying to learn how to use GDB for debugging C programs. I think it would be particularly excellent if I could use GDB to ferret out bugs that lead to segfaults. I have a small program that I've written as a solution to K&R's exercise 1-13, and given an input string of a certain size it will generate a segfault:
$ ~/learning_c/KR_exercises/chapter_1/1.13.x`
--I provide a string from stdin, and...--
Segmentation fault (core dumped)
According to the Arch wiki, "Systemd's default behavior is to generate core dumps for all processes in /var/lib/systemd/coredump/."
Okie doke:
$ls /var/lib/systemd/coredump/core.1\x2e13\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4
But when I run:
$ gdb -q ~/learning_c/KR_exercises/chapter_1/1.13.x /var/lib/systemd/coredump/core.1\\x2e13\\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4
I get:
Reading symbols from /home/dean/learning_c/KR_exercises/chapter_1/1.13.x...done.
"/var/lib/systemd/coredump/core.1\x2e13\x2ex.1000.0da6be3a2b4647c8befe14e0e73af848.1719.1438627150000000.lz4" is not a core dump: File format not recognized
Trying to generate a core dump by attaching GDB to the process as detailed here only makes my terminal emulator start capturing control characters (^D, ^C, and ^Z won't work in emulator after attaching GDB), and if a segfault is occuring after attaching GDB it isn't being reported in the shell.
Help me to understand, oh merciful and beneficent lords of Stack Overflow!
ADDENDUM:
I've solved this particular issue, thanks largely to WhozCraig, whom suggested that GDB was behaving as it should have when being force-fed an lz4 compressed corefile. If Craig would be so kind as to post a solution saying something similar, I'd be happy to give him that big 'ol check mark.
The easist solution is to start gdb via a subroutine named coredumpctl along with the crashed program's PID, a la
$coredumpctl gdb *PID HERE*
This vexes me, Arch, and I may migrate over to Gentoo because of it.
I've solved this particular issue, thanks largely to WhozCraig, whom suggested that GDB was behaving as it should have when being force-fed an LZ4 compressed corefile. If Craig would be so kind as to post a solution saying something similar, I'd be happy to give him that big 'ol check mark I'm taking all the credit, though. Bwahahaha!
The easiest solution is to start gdb via a subroutine named coredumpctl along with the crashed program's PID, a la
$coredumpctl gdb PID HERE
This vexes me, Arch, and I may migrate over to Gentoo because of it.
I have same purpose with you. Just uncompress lz4 file by lz4 command, then you can debug by gdb crashed_C_executable_file uncompressed_coredump_file
I have a Dreambox 500 which on Wikipedia says has a PCP processor which is PowerPC:
$ cat /proc/cpuinfo
processor: 0
cpu: STBx25xx
clock: 252MHz
Review: 9.80 (pvr 5151 0950)
bogomips: 250.36
Machine: Dream Multimedia Dreambox TV
plb bus clock: 63MHz
I would normally install GCC but it has low storage on it and I need to compile a program for it.
I've heard GCC can compile powerpc but I had no luck doing so.
Example this code
#include <stdio.h>
int main()
{
printf("Hello World!\n");
return 0;
}
And I use this to compile
gcc example.c -mtune=powerpc
But it give this error
example.c:1:0 error: bad value (powerpc) for -mtune- switch
#include <stdio.h>
^
Thank you!
You should use cross-compiler, because your target architecture differs from host one. Host is the architecture of your system (usually amd64 (x86_64) or i386 (x86_32)). And target arch is the arch on which your compiled program will run (powerpc in your case).
Many GNU/Linux distors provide crosscompilers as a separate packages. For example, for Ubuntu these packages are available:
sudo apt-get install gcc-4.8-powerpc-linux-gnu g++-4.8-powerpc-linux-gnu binutils-4.8-powerpc-linux-gnu
Packages above are for trusty. In later releases different GCC versions are available.
Then you can compile your program using powerpc-linux-gnu-gcc-4.8. Or you can set your environment variables CC and CXX to powerpc-linux-gnu-gcc-4.8 and powerpc-linux-gnu-g++-4.8 accordingly.
upd:
I found crosscompiler toolchain for Dreambox 500 here, but it contains relatively old GCC (3.4).
In order to use it extract downloaded file to /opt/cross/dm500, add /opt/cross/dm500/cdk/bin to path via export PATH=$PATH:/opt/cross/dm500/cdk/bin and use gcc from here with appropriate prefix.
After being on a programming forum for a while, found a guy with the same problem, and after a while he found a way to fix it and I tried it and it works.
The thing I have to do is
powerpc-gcc someprog.c -static
I have no idea what the -static does but it increases the executable file size and at the end it works!
I am using Code::Blocks 13.12 for programming in C. After building and running my simple HelloWorld.c program, it gives an error.
Error: An alert box pop up saying -"cc1.exe has stopped working.A problem caused the program to stop working correctly.Windows will close the program and notify you if a solution is available."
I tried using Notepad++ , the same pop up appears saying a.exe has stopped working.
I am a naive,so have no idea on how to deal with this.
My queries:
1) Am I using an outdated version? If not, how can I get rid of this problem?
2) Which is the most efficient IDE available for C/C++ if Code::Blocks is not that efficient?
My requirement"
-I had been using Turbo C and it doesn't give errors like segmentation fault and other memory related errors that we get in online Compilers or compilers of competitive programming.So, I need an efficient compiler which behaves same as online compilers, so I don't get stuck while solving problems during competitive programming.
This is the simple code giving error:
#include <stdio.h>
void main()
{
printf("Hello world!");
//return 0;
}
Edit:
Even after changing the code to return int, it's giving an error.I tried editing the code as below, but the same window is being popped up again.
int main(void)
{
printf("Hello world!");
return 0;
}
There's no problem with your code, though indeed, as pointed out in the comments, neither void main() nor int main(void) is considered correct, but that's not what's causing the problem. cc1.exe is a MinGW-related file (MinGW is the GCC port for Windows that Code::Blocks uses by default for compilation); if it's crashing, it's possible the installation is corrupt.
I suggest you try reinstalling MinGW - remove Code::Blocks, install the standalone MinGW version, then download Code::Blocks without the compiler suite, install it and configure to use your version of MinGW.
For me, the solution was to choose,
Select target -> Release
from the Build menu. It took lots of time for me to find this!
Looking into learning C. As I understand it when I say #include <stdio.h> it grabs stdio.h from the default location...usually a directory inside your working directory called include. How do I actually get the file stdio.h? Do I need to download a bunch of .h files and move them from project to project inside the include directory? I did the following in a test.c file. I then ran make test and it outputted a binary. When I ran ./test I did not see hello print onto my screen. I thought I wasn't seeing output maybe because it doesn't find the stdio.h library. But then again if I remove the greater than or less than signs in stdio the compiler gives me an error. Any ideas?
I'm on a Mac running this from the command line. I am using: GNU Make 3.81. This program built for i386-apple-darwin10.0
#include <stdio.h>
main()
{
printf("hello");
}
Edit: I have updated my code to include a datatype for the main function and to return 0. I still get the same result...compiles without error and when I run the file ./test it doesn't print anything on screen.
#include <stdio.h>
int main()
{
printf("hello");
return 0;
}
Update:
If I add a \n inside of the printf it works! so this will work:
#include <stdio.h>
int main()
{
printf("hello\n");
return 0;
}
Your code should have preferably
printf("hello\n");
or
puts("hello");
If you want to know where does the standard header file <stdio.h> comes from, you could run your compiler with appropriate flags. If it is gcc, try compiling with
gcc -H -v -Wall hello.c -o hello
Pedantically, a standard header file is even not required to exist as a file; the standard permits an implementation which would process the #include <stdio.h> without accessing the file system (but e.g. by retrieving internal resources inside the compiler, or from a database...). Few compilers behave that way, most really access something in the file system.
If you didn't have the file, you'd get a compilation error.
My guess is the text was printed, but the console closed before you got the chance to see it.
Also, main returns an int, and you should return 0; to signal successful completion.
#include <header.h>, with angle brackets, searches in standard system locations, known to the compiler-- not in your project's subdirectories. In Unix systems (including your Mac, I believe), stdio.h is typically in /usr/include. If you use #include "header.h", you're searching subdirectories first and then the same places as with <header.h>.
But you don't need to find or copy the header to run your program. It is read at compilation time, so your ./test doesn't need it at all. Your program looks like it should have worked. Is it possible that you just typed "test", not "./test", and got the system command "test"? (Suggestion: Don't name your programs "test".)
Just going to leave this here : STILL! in 2018, December... Linux Mint 18.3
has no support for C development.
innocent / # cc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # gcc ThoseSorts.c
ThoseSorts.c:1:19: fatal error: stdio.h: No such file or directory
compilation terminated.
innocent / # apt show libc6
(Abbreviated)::
Package: libc6
Version: 2.23-0ubuntu10
Priority: required
Section: libs
Source: glibc
Origin: Ubuntu
Installed-Size: 11.2 MB
Depends: libgcc1
Homepage: http://www.gnu.org/software/libc/libc.html
Description: GNU C Library: Shared libraries
Contains the standard libraries that are used by nearly all programs on
the system. This package includes shared versions of the standard C library
and the standard math library, as well as many others.
innocent / # apt-get install libc6-dev libc-dev
So, magic... and a minute later they are all installed on the
computer and then things work as they should.
Not all distros bundle up all the C support libs in each ISO.
Hunh.
hardlyinnocent / # gcc ThoseSorts.c
hardlyinnocent / # ./a.out
20
18
17
16
... ... ...
Not so long ago I've installed Debian and configured it with my friend's help.
Yesterday I have downloaded GCC 4.4 and I created a simple program to test it out.
This is the code:
#include <stdio.h>
int main () {
int result;
printf ("Hello Wor... Linux! This is my %dst program compiled in Debian.\nHow many is 2+2?\n", 1);
scanf ("%d", &result);
while (result!=4) {
printf ("Oh no! You're not going anywhere until you type the correct result! 2+2 is?\n");
scanf ("%d", &result);
}
printf ("Congrats!\n");
return 0;
}
I've compiled it by typing gcc-4.4 myfile.c in bash. Then I've tried to run the resulting binary file and it worked just as I wanted it to. Then I've sent the binary file to my friend to test it on his PC also. When he tried to run it, he received a segmentation fault message and the program didn't work.
He also uses Debian and his kernel's version is very similar to mine (2.6.32-5-686). The only difference is that his kernel is an amd-64 one (he owns a 64-bit processor, while mine is 32-bit).
Why is this happening? Does it mean that 64-bit Linux users will be unable to run my 32-bit programs? If so, can I compile it in a way which will let them to run it?
Please note that I'm not really experienced with Linux.
he may need a chroot for it.
apt-get install ia32-libs
should work for most cases.
see "Using an IA32 chroot to run 32bit applications" http://alioth.debian.org/docman/view.php/30192/21/debian-amd64-howto.html#id292205
Alternatively, set up your compiler to target 64-bit binaries by following the instructions at the OSDev wiki: In brief:
Set up the new repos in /etc/apt/sources.list
deb http://www.tucs.org.au/~jscott4/debian/ stable main #Primary Mirror. Hosted by University of Tasmania.
Add the signing key:
gpg --recv-keys 0x2F90DE4A
gpg -a --export 0x2F90DE4A | sudo apt-key add -
Update your repo indices and get the appropriate cross-compilation package:
apt-get update
apt-get install osdev-crosscompiler-x86-64-elf
Then use the x86_64-elf variant of gcc to target x64. For instance
x86_64-elf-gcc --pedantic -Wall -o foo foo.c
(In fact all the GCC tools and Binutils will have an x86_64-elf- variant now.)
EDIT -- Vastly improved instructions by pulling from a reference instead of from memory.
EDIT -- removed stale mirror
chroot is one option. But remember it requires a lot of disk space as it installs 32-bit libraries.
Alternatively you can compile your file for a 64-bit environment by using the -m64 compiler flag of gcc which sets int to 32 bits and long and pointer to 64 bits and generates code for AMD's x86-64 architecture.