This is my make file
EXE = signsrch
CFLAGS += -s -O2
PREFIX = /usr/local
BINDIR = $(PREFIX)/bin
SRC = $(EXE).c
all:
$(CC) $(CFLAGS) -c disasm.c
$(CC) $(CFLAGS) -c asmserv.c
$(CC) $(SRC) $(CFLAGS) -o $(EXE) *.o
install:
install -m 755 -d $(BINDIR)
install -m 755 $(EXE) $(BINDIR)/$(EXE)
.PHONY:
install
I want to cross compile it for my ubuntu and I tried:
make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
but I get unknown type name errors with a bunch of âDWORDâ
Help?
We also need to see some code, but....
Windows has its own types for basic things above the vanilla C ones, as does Linux. It sounds like DWORD as a type is not known in Linux (likely). You'll probably have to create a mytypes.h file that redefines Windows standards like DWORD into Linux speak when building for a Linux platform. Linux has types.h that defines things like int32_t which is the equivalent. See this thread for more about this.
I've assumed you have a working cross compiler set up and you're fighting just with the port. If you haven't, that's your first job. You could have a windows based compiler that targets Linux (the cygwin option, mentioned in another post) or go for a Linux based compiler and targetting windows (crosstool will help here). Though since you seem to be targetting arm, I'm expecting that that Ubuntu install isn't the place you wish to build! :-)
to cross compile you need a toolchain for the target platform, not just a Makefile. Check this tutorial and also Cygwin
Related
I followed this article on how to make a very simple kernel which prints "Hello, World". The files to my project are available on Github.
I built my cross compiler from this project. I use these command to cross compile, assemble, and build my ISO (CD-ROM image):
i686-elf-as boot.s -o boot.o
i686-elf-gcc -c kernel.c -o kernel.o -std=gnu99 -ffreestanding -O2 -Wall -Wextra
i686-elf-gcc -T linker.ld -o myos.bin -ffreestanding -O2 -nostdlib boot.o kernel.o -lgcc
mkdir -p isodir/boot/grub
cp myos.bin isodir/boot/myos.bin
cp grub.cfg isodir/boot/grub/grub.cfg
grub-mkrescue -o myos.iso isodir
When I tried to execute it on VirtualBox, it gives the following message:
FATAL: No bootable medium found! System halted.
Why am I getting this error, and how can I fix it?
P.S. I use Ubuntu subsystem for Windows 10
Likely there is a GRUB component missing or an incorrect version of Xorriso. In the Bare Bones article you linked to it says this:
You can easily create a bootable CD-ROM image containing the GRUB bootloader and your kernel using the program grub-mkrescue. You may need to install the GRUB utility programs and the program xorriso (version 0.5.6 or higher).
When using grub-mkrescue to make ISO images, more often than not unbootable ISOs is a result of Xorisso installation missing. If grub-mkrescue runs but doesn't produce ISOs at all then likely a GRUB component is missing. To ensure that you have all the GRUB and Xorriso components installed install the components on modern Ubuntu releases with:
sudo apt-get install grub2-common grub-pc xorriso
Then attempt to rebuild and rerun your ISO image in VirtualBox.
I've been having trouble compiling an executable with SDL 1.2 and C that will work on another machine. I'vee been compiling it from Ubuntu using a makefile. I'd like to be able to send a "bin.zip" to a classmate, with "SDL.dll" and "SDL_ttf.dll" inside as well as "prog" the executable that I compiled for them.
I would expect them to be able to run that "prog" from their own Ubuntu desktop (Virtual Machine, if that's relevant) and not need to install libsdl1.2debian and libsdl-ttf2.0-0 themselves first, since I included the DLLs.
Note that they can run it fine once they've installed those libraries.
My project structure, at compilation, is such:
2048-c
/bin (dlls and executable)
/include (".h" header files)
/lib ("SDL.lib", "SDL_ttf.lib", "SDLmain.lib")
/src (".c" source files)
"makefile"
My makefile looks like this:
CC=gcc
CFLAGS=-c -Wall `sdl-config --cflags`
LDFLAGS=`sdl-config --libs` -lSDL_ttf
SOURCES=src/main.c src/toolbox.c src/game.c
OBJECTS=$(SOURCES:.c=.o)
EXECUTABLE=bin/prog
.PHONY: clean
all: $(SOURCES) $(EXECUTABLE)
$(EXECUTABLE): $(OBJECTS)
$(CC) $(OBJECTS) $(LDFLAGS) -o $#
.c.o:
$(CC) $(CFLAGS) $< -o $#
clean:
rm -f $(OBJECTS) $(EXECUTABLE)
Am I missing something obvious? Edit: (Yes, I was)
Yes, I was missing something obvious : DLLs are specifically for Windows
Now, as for getting an executable to work without installing the required libraries, I still haven't managed that (linking statically didn't pan out, in my case), but at least I learnt something.
If I give cross-compilation to Windows a try, I'll try to update this.
I need to obtain the information on the C-compiler used to build an installed program. I am guessing a rt or a lib can report that, but nothing concrete. Not that the program would be installed in /usr/... or a similar place, and hence would not have access to the build directory to get the relevant info.
Well behaved programs should understand the --version argument.
Packaged programs (i.e. those installed with dpkg -i or apt-get install of a .deb package on Debian, etc...) also know their package version and source.
You might try to use strings on the binary executable. However, such meta-data (about the version of the C compiler used to build the program) might have been stripped (e.g. by the strip command).
If you are developing the program (i.e. its C source code) and can change it, you might consider adding something like
timestamp.c: Makefile
echo 'const char timestamp[]=' > $#
date +'"built with $(shell $(CC) --version) on %c";' >> $#
yourprogram: $(OBJECTS) timestamp.o
$(LINK.c) $(LDFLAGS) $< -o $# $(LDLIBES)
$(RM) timestamp.c
in your Makefile (details could be wrong, but you get the idea)
I've made a C program that uses libsndfile to extract some data from audio files.
What possibilities are there to make the program as portable as possible, preferably without requiring root access when installing?
Libsndfile is not available at the target machines, so i need to somehow package it with my program. Is there a way to statically link the library? I've also looked at some Autotools tutorials, but I'm not sure how to proceed.
I can compile without a hitch on my dev machine, where I installed the libraries using the package manager: apt-get install libsnfile1-dev
The makefile is very simple:
CFLAGS=-std=c99 -Wall -pedantic -g
CLIBS= -lsndfile -lm
BIN=audiodecode
CC=gcc
MAIN=main.o
FILES=
OBJS=$(FILES) $(MAIN)
.PHONY: all
all: clean $(OBJS)
$(CC) $(CFLAGS) -o $(BIN) $(OBJS) $(CLIBS)
.PHONY: clean
clean:
rm -f *.o $(BIN)
A lot of packages bundle their dependencies. Examples: rsync (contains a bundled libpopt), gnupg (contains a bundled libz). Other dependencies commonly bundled are gettext or glib.
For inspiration look at how these popular open source projects do it.
Put the content of http://www.mega-nerd.com/libsndfile/files/libsndfile-1.0.25.tar.gz into a subdir and add apropriate rules to build the the subdir first.
Untested sample code:
OBJS += libsndfile/libsndfile.a
libsndfile/libsndfile.a:
cd libsdndfile && ./configure --enable-static && $(MAKE)
For Bonus points add a configure script, that check if the system has already installed libsndfile and link to it dynamically.
When I compile a simple Hello World! program that uses the sscanf function on my local Debian lenny x64, it works. But when I upload the same program to the server running CentOS x86, it will not work. If I do not use sscanf, then the program works on both computers.
gcc -std=c99 -O2 -pipe -m32
If I compile it with sscanf but without -std=c99, then it works on both computers.
gcc -O2 -pipe -m32
What is the problem with sscanf and c99 on CentOS x86 ? I thought that compiling with the -m32 flag would work on all Linuxes ? (I have limited access to the CentOS server, so I do not have access to error messages.)
Probably the CentOS box is using an old version of glibc. Since the nonstandard GNU extensions to their scanf implementation ended up making glibc conflict with c99, they added a nasty hack of redirecting *scanf to __isoc99_*scanf when -std=c99 is in use; if your copy of glibc is missing the __isoc99_sscanf symbol, the program will then fail to run.
Static linking, or linking to a different libc without ugly backwardsness-compatibility hacks, would solve the problem.
Are you uploading the binary or the source and then recompiling? If you are uploading the binary, you are probably running into a library compatibility issue between Debian and CentOS.
If that is the case, upload the source only and recompile on CentOS.
If you do not have permission to compile # CentOS, then try compiling a static binary. You can use dietlibc which makes smaller binaries than glibc or try EGLIBC which is the default C library that Debian will use starting Debian "squeeze".
I came up with the similar problem, it works # Ubuntu 64-bit, but the compile fails # CenseOS 64-bit (REHL5 desktop):
the error message is:
undefined reference to `__isoc99_sscanf#GLIBC_2.7'
when i copied the executable file compiled #Ubuntu to REHL5, and run it another error appeared:
elf file os abi invalid
it is compiled without flag -std=c99, i'm a newbie at C, and looking forword some workarounds, ex. add some flag.
Makefile:
CC=gcc
CCFLAGS= -Wall -O2 -DLINUX -I../include
demos:linuxdemo.c
$(CC) $(CCFLAGS) -o demoA linuxdemo.c -L../lib -lsense4 -lusb
$(CC) $(CCFLAGS) -o demoSO linuxdemo.c -lusb -lsense4
clean:
rm -f demoA
rm -f demoSO
You need to update your glibc to 2.7
download the rpm package from here:
http://archive.fedoraproject.org/pub/archive/fedora/linux/releases/8/Everything/x86_64/os/Packages/
needs:
libc-common-2.7-2.x86_64.rpm
glibc-headers-2.7-2.x86_64.rpm
glibc-devel-2.7-2.x86_64.rpm
glibc-2.7-2.x86_64.rpm
command:
rpm -Uvh --aid --nodeps glibc-common-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-headers-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-devel-2.7-2.x86_64.rpm
rpm -Uvh --aid --nodeps glibc-2.7-2.x86_64.rpm