I'm trying to get a "Hello World" application compiled for an ARM target. I'm cross compiling using gcc on Ubuntu/VMWare. If I compile for the host machine, it works fine. When I compile for the target, I get this error:
/root/picokernel/toolchain/arm-eabi/lib/libcs3hosted.a(hosted-sbrk.o): In function `_sbrk':
sbrk.c:(.text+0x74): undefined reference to `__cs3_heap_limit'
/root/picokernel/toolchain/arm-eabi/lib/libcs3hosted.a(hosted-sbrk.o):(.data+0x0): undefined reference to `__cs3_heap_start'
make: *** [HelloWorld] Error 1
So I think I need to link something in - perhaps my toolchain does not have the right libs? I was able to build the kernel, so I thought it was complete. Thanks! This is the target board. - runs Angstrom or Android.
makefile:
CC=$(CROSS_COMPILE)gcc
LD=$(CROSS_COMPILE)ld
CROSS_LIB1=/root/picokernel/toolchain/arm-eabi/lib
CROSS_LIB2=/root/picokernel/toolchain/lib/gcc/arm-eabi/4.2.1
CFLAGS=-Wall
LDFLAGS= -L$(CROSS_LIB1) -L$(CROSS_LIB2) -lc -lcs3hosted -lg -lgcc --entry main
HelloWorld: HelloWorld.o
$(LD) HelloWorld.o $(LDFLAGS)
clean:
rm -f HelloWorld HelloWorld.o
program:
#include <stdio.h>
int main(int argc, char **argv)
{
printf("Hello World\n");
return 0;
}
I gotta say, this is suspicious: -nostdlib
How about not using this flag?
The kernel does not use the C runtime library since the library does many—if not most—things not permitted by kernel code like file i/o and allocating memory.
Normally, you don't have to specify a library at all. gcc assumes the right thing. Try removing setting LDFLAGS altogether: I bet it works better.
Ok - finally worked this out, picked up a toolchain from the source here:
http://www.codesourcery.com/sgpp/lite/arm/portal/release1803
Hello World works great! Thanks for the suggestions
Does the toolchain you are using have a library called "lcs3arm" ? If so, try adding that to the list. You can also try "-lcs3" itself
Out of interest, which version of GCC are you using here? (i.e. which CodeSourcery release)
Related
I have 3 classes - I denote those by firstClass,secondClass,thirdClass.
My headers - firstClass.h, secondClass.h, thirdClass.h and sources firstClass.cpp, secondClass.cpp, thirdClass.cpp.
In class thirdClass I create instance of firstClass and two instance of secondClass.
In main.cpp I deamonize and create instance thirdClass.
I want to create static library of thirdclass and linking to main.cpp.
firstClass and thirdClass used the same library libm.a
I created library step by step as following:
g++ -c -I-/usr/include/ -I-/usr/lib/ -I-/home/projects/Learninig firstClass.cpp -lstdc++ -lm-o WsChannel.o -w -m32
g++ -c -I-/usr/include/ -I-/usr/lib/ --I-/home/projects/Learninig secondClass -lstdc++ -o secondClass.o -w -m32
g++ -c -I-/usr/include/ -I-/usr/lib/ --I-/home/projects/Learninig thirdClass.cpp -lstdc++ -lm -o thirdClass.o -w -m32
ar rcs libLearning.a firstClass.o secondClass.o thirdClass.o
g++ main.cpp -L. -lLearning -lm -o MnLearning.o -m32
Compiling was maked correctly without any errors, but when I execute program I have same error. I spent some hours on checking code, but I don't find bugs. So then maybe compiling was incorrect. I did this using some tutorial in web.
If whatever was unclearly I am ready to more explain my question.
Edit: My error:
segfault at 557400000045 ip 00005574bd509dcd sp 00007ffd9e887900 error 4 in MnLearning[5574bd4f2000+26000]
The error is surely inside your own source code. Avoid undefined behavior in it, and be scared of UB.
Your use of -I- is strange, and probably wrong. I recommend removing it (and also, at first, remove the -m32 flag if your computer and distribution is 64 bits; work first to have your program run correctly on your laptop, then port it later to 32 bits Linux by adding the -m32 flag). You might use preprocessor options like -H to be shown what files are included.
I recommend building your library and your program with some build automation tool, such as GNU make or ninja.
Configure your build to compile with all warnings and debug info, i.e. using g++ -Wall -Wextra -g with GCC. Improve your source code to get no warnings. Then use the gdb debugger to understand the behavior of your program (and library).
So then maybe compiling was incorrect.
No, the compiler is probably good, and you should trust it.
The bug is very likely to be in your own code.
My error: segfault at 557400000045 ip 00005574bd509dcd sp 00007ffd9e887900 error 4 in MnLearning[5574bd4f2000+26000]
Segmentation fault is a symptom of some error in your own code (e.g. some buffer overflow, some bad pointer dereference, etc; or other kind of UB).
You might also use valgrind.
I spent some hours on checking code, but I don't find bugs.
You did not spend enough time (some bugs may take you weeks of work to be found), and you forgot to use the debugger, a very handy tool to help you understand the behavior of your program and find bugs in it. Be aware that programming is difficult, and don't be discouraged.
my program compiled and worked fine with:
g++ main.cpp exm1.cpp exm2.cpp -o main.o
i want to compile this app and run anywhere
how can i?
i try this code
g++ -g -Wall -I/MyApp/lib -static-libgcc -static-libstdc++ -static main.cpp exm1.cpp exm2.cpp -o main.o
but not work
in lib folder has 2 files:
exm1.h
exm2.h
main.cpp included:
#include <fstream>
#include <iostream>
#include <string>
#include <streambuf>
#include <stdlib.h>
#include "lib/exm1.h"
#include "lib/exm2.h"
my linux is kali, and i want run this app on CentOS 6
please help me,thanks
As C. bear said, use the -m32 flag so the program is able to run on 64- and 32- bit systems. In doing this, You'll also have to install the 32bit stdlibs. I'm not sure how to do this on kali, give it a google. Another thing you can do to avoid having users install external libraries (if you use them at any point) is to statically link you executable. Use the -static flag to do this. However, because all your app's dependencies (including the stdlibs) will be in a single file, it will get pretty big. On the other hand, loading times will be better, because your app doesn't have to run the dynamic linker and wait for it to link your external libraries as you call them.
So from comments one reason could be you executable is 64-bit and centOS a 32-bit sytem. Try compilation with -m32 flag.
how to compile g++ app and run anywhere?
It is not easily possible. For example, an ELF executable produced by GCC on a recent Debian/x86-64 computer won't run on a RaspberryPi (with a linux for ARM 32 bits, e.g. some Raspbian)
Read more about execve(2), elf(5) and about fat binaries
Be aware that the GCC compiler suite can be built (from its source code) as a cross-compiler (but you'll need to rebuild GCC for every different target system).
I recommend to invoke GCC as g++ -Wall -Wextra -g during the debugging phase (and use GDB). Once your software is debugged, compile it with g++ -Wall -Wextra -O2 to get an optimized binary (or even compile and link it with g++ -Wall -Wextra -O3 -flto)
I have a Xilinx FPGA running a soft processor (PowerPC). I recently cross compiled Boost libraries for PowerPC and wanted to test it. So I used one of the sample programs and tried to cross compile it for my target. Below is the code
#include <boost/thread/thread.hpp>
void helloworld()
{
printf( "Hello World!");
}
int main()
{
boost::thread thrd(&helloworld);
thrd.join();
}
Below is my make file
CPP=ppc_4xx-g++
CFLAGS=-c -g -Wall
LDFLAGS_PowerPC=-L/shared/deps/powerpc/lib -L/opt/ELDK/4.2/ppc_4xx/lib/
LIBS_PowerPC=-lboost_thread -lboost_system -lpthread -lrt
INCLUDES=-I. -I./4.2.2/ -I./include -I/opt/ELDK/4.2/ppc_4xx/usr/include/
CPPFLAGS_PowerPC=-I/shared/deps/common/include
CPPFLAGS_COMMON=-I/shared/deps/powerpc/include
CPPFLAGS=$(CPPFLAGS_COMMON) $(CPPFLAGS_PowerPC)
all: helloworld
helloworld: helloworld.o
$(CPP) $(LDFLAGS_PowerPC) $(LIBS_PowerPC) helloworld.o -o helloworld
helloworld.o: helloworld.cpp
$(CPP) $(CFLAGS) $(CPPFLAGS) $(INCLUDES) helloworld.cpp
clean:
rm -rf *.o helloWorld
I was able to generate the binaries but when I run the program on my target I get the below error
-/bin/sh: ./helloworld: not found
I checked online and found that the above problem comes when we have dynamic linking. My Boost libraries are present in the location /shared/deps/powerpc/lib and I have set the variable LD_LIBRARY_PATH accordingly using the below command.
export LD_LIBRARY_PATH=/shared/deps/powerpc/lib/:/opt/ELDK/4.2/ppc_4xx/lib/
But even then I get the same problem.
Below is the output of uname -ars
Linux (none) 3.0.0-14.1-build3+ #23 PREEMPT Thu Jan 3 18:44:27 CST 2013 ppc GNU/Linux
I don't have ldd installed on my target so I can't check the dynamic dependencies. But I am sure that, libraries are included. How can I proceed ?
Even though my embedded Linux system had a dynamic linker, it was not working. The problem was resolved when I used a dynamic linker provided with my tool chain and replaced it the correct directory. Now dynamic linking is fine.
I successfully ran sudo apt-get install libncurses5-dev
Within my Eclipse window I then try to build the following HelloWord.cpp program:
#include <ncurses.h>
int main()
{
initscr(); /* Start curses mode */
printw("Hello World !!!"); /* Print Hello World */
refresh(); /* Print it on to the real screen */
getch(); /* Wait for user input */
endwin(); /* End curses mode */
return 0;
}
I get the following error:
Invoking: GCC C++ Linker
g++ -m32 -lncurses -L/opt/lib -o "Test_V" ./src/curseTest.o ./src/trajectory.o ./src/xJus-epos.o -lEposCmd
/usr/bin/ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
make: *** [Test_V] Error 1
It looks like the compiler is searching for the ncurses library and can't find it? I checked /usr/lib and the library does not exist there so do I need to manually link the ncurses library there - I thought the get-apt installer would automatically do this?
g++ HelloWorld.cpp -lncurses -o HelloWolrd
If you have a 32-bit machine, gcc compile m32 auto. If you have a 64-bit machine and you want to compile 32bits you
Your arguments are not in the correct order. You must specify all source files first and then linker search directories before specifying the libraries to link with. Your command should be like this:
g++ HelloWorld.o -L/opt/lib -lncurses -o HelloWorld
Taken from comment by #ChrisDodd:
Your options are in the wrong order -- -L must be BEFORE -l and both must be after all .o
I have an autotools project that compiles just fine on the Mac, but under Linux (Ubuntu 12.04.1 LTS) the command lines passed to gcc have the libraries out of order relative to the object files. For example, autotools generates the following command to compile my code, a single file named test.c into a binary named test:
gcc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -lglib-2.0 -o test test-test.o
This command line fails with:
/home/user/glib-test/test.c:4: undefined reference to `g_malloc`
/home/user/glib-test/test.c:5: undefined reference to `g_free`
However, if I compile from the command line and switch it up so the library reference is after the object files it works just fine:
gcc -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -g -O2 -o test test-test.o -lglib-2.0
The challenge is that I can't figure out how to force Autotools to generate the command line in the right order. For the sake of clarity, I've reproduced the simple test case here. First up is configure.ac:
dnl Process this file with autoconf to produce a configure script.
AC_PREREQ(2.59)
AC_INIT(glib-test, 1.0)
AC_CANONICAL_SYSTEM
AM_INIT_AUTOMAKE()
AC_PROG_CC
AM_PROG_CC_C_O
PKG_CHECK_MODULES(GLIB, glib-2.0 > 2.0)
AC_CONFIG_FILES(Makefile)
AC_OUTPUT
Next is the simple Makefile.am:
CFLAGS=-Wall
bin_PROGRAMS=test
test_CFLAGS=$(GLIB_CFLAGS)
test_LDFLAGS=$(GLIB_LIBS)
test_SOURCES=test.c
Finally, the source code to this minimal test case, test.c:
#include <glib.h>
int main(int argc, char **argv) {
gchar *foo = g_malloc(100);
g_free(foo);
return 0;
}
Compilation is then achieved using the following series of commands:
touch NEWS README AUTHORS ChangeLog
aclocal
autoconf
automake --add-missing
./configure
make
I should be clear, I understand why my code won't compile, I'm just wondering how to get automake to put the libraries at the end of the command line so gcc will execute and link properly. It should be noted that gcc on Mac OS X Lion doesn't seem to have this problem.
The solution turned out to be the difference between LDFLAGS and LDADD. In short LDFLAGS is added before the object files on the command line and LDADD is added afterwards. Thus, changing Makefile.am to the following solved the problem:
CFLAGS=-Wall
bin_PROGRAMS=test
test_CFLAGS=$(GLIB_CFLAGS)
test_LDADD=$(GLIB_LIBS)
test_SOURCES=test.c
It only took tracking down a GCC developer at work to solve. Also, this example I provided is rather poor because test has a defined meaning in some contexts of autotools.
I solved a similar problem. The ./configure script in question was unable to complete a check for presence of a function due to a missing symbol. If I added the correct library to $LDFLAGS or such like, it was added before the .c file and the library was ignored.
The names of functions to check are first added to ac_func_list and then there is a loop in the body of the ./configure that for each of them calls ac_fn_c_check_func () and that in turns calls ac_fn_c_try_link ()
the checking function ac_fn_c_try_link () uses a command of this pattern:
ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS \
$LDFLAGS conftest.$ac_ext $LIBS >&5'
$LDADD is completely ignored here. Therefore the only solution here is to add the -l flags to variable $LIBS.