royfarji india wrote:

Sorry to bother you all. I am a student and desire to become researchers like you all out there.

I understand. There are several things that I think you need to spend time studying, to make the most out of the community. Some are trivial (write useful email subjects, never send Microsoft Office files) and others require understanding of a fairly big topic, such as the problem you met, because the cross-compilation is not being done correctly. The GNU toolchain is not too simple, so it's a big topic even for native compilation. It becomes even more important to know many details in order to firmly grasp cross-compilation.

Toolchain education is not the topic of the project. I would recommend experimenting with some other ARM microcontrollers first.

It says that the header file 'signal.h' is missing in osmocore. I am just uanble to figure it how it is unable to include the header file. please help.

The fact that noone else had the problem could (and should) suggest that there is a greater error than something related to the header file.

Also I am attaching the file of compilation.

Microsoft Office is a proprietary program. The open source community by definition dislikes proprietary programs. Please keep this in mind. Please keep the logic in mind.

Even if Word is a big part of your other activities it is important to speak with fools the way fools understand. (Swedish proverb.) When working in an open source project, Word is not an appropriate tool, because you can not know if everyone else has Word, and furthermore, because you are sending text via email then the simplest method is to put the text directly in the email. That way everyone receiving your email can also read the text directly in their email programs. Try it also with your colleagues. Maybe they will be shocked by having text available immediately in the email program.

By the way I am using the gnuarm-3.4.3 as shown on the osmocom-bb website.

I believe this toolchain has a bug, and the osmocom build system currently relies on this bug. With experience from the GNU toolchain and embedded software development using open source tools the bug is obvious and trivial to work around. Without that experience it's not easy to spot. I've sent a patch which makes osmocom assume a bug-free toolchain, but still be compatible with the old behavior, but it has not been included yet.

roy@roy:~/osmocom-bb$ cd src roy@roy:~/osmocom-bb/src$ make cd shared/libosmocore/build-target && ../configure \ --host=arm-elf-linux --disable-vty --enable-panic-infloop \ --disable-shared --disable-talloc --disable-tests \ CC="arm-elf-gcc" CFLAGS="-Os -ffunction-sections -I/home/roy/osmocom-bb/src/target/firmware/include -nostartfiles -nodefaultlibs"

The error is with --host and the gnuarm toolchain. The specified target system (arm-elf-linux) would Linux on the phone, which is incorrect. A more correct prefix tuple for an ARM CPU without operating system would be arm-elf, arm-none-elf or arm-none-eabi.

checking for arm-elf-linux-gcc... arm-elf-gcc

osmocom configure expects an arm-elf-linux C compiler, but CC= on the command line overrides it. This might seem like an acceptable solution, but in fact the configure script and other toolchain commands may still rely on the fact that the target system will be running Linux as specified with --host.

Could try patch v4 in old thread:

http://baseband-devel.722152.n3.nabble.com/PATCH-Adjust-top-level-Makefile-f...

//Peter