GCC in DevStudio missing functionality

Hi All,

Been trying to cross compile an application for the Legato and it appears that the version of GCC delivered with Dev Studio (DS) is missing some functionality.

I’ve found the following:
[ul][li]select() is not defined anywhere - appears to be missing from a header file?[/li]
[li]the header files sys/shm.h and sys/ipc.h are missing from the include directory - so Shared Memory and some IPC functionality is not available[/li]
[li]the version of pthread.h is somewhat broken and missing some declarations.[/li][/ul]

The code I’m cross compiling for the Legato is already cross compiled on MOXA ARMv4 and Raspberry Pi ARM targets (as well as X32 and x64 intel) and I don’t have these issues. My code (compiled with a Makefile using the Yocto GCC) compiles and links but segfaults when executed - which is why I was trying with DS so I could use gdb to debug what is happening.

I need some assistance:
[ul][li]Why are these headers missing from DS?[/li]
[li]Copying the missing headers from the Yocto gcc install doesn’t seem to help. Is there an update of DS with these missing headers available.[/li][/ul]

Or does the Legato not support multithreading and shared memory?

Yes, I’m pushing the Legato hard … but it’s nothing that I can’t already do on a $40 Raspberry Pi.

Looking forward to sorting this out.

ciao, Dave

Hi David,

The Yocoto build we have supports IPC and shared memory. We’re using sockets internally, and are planning to use shard memory as well. So, as a small test, I’ve tried compiling the sample code found in: [url]http://en.wikipedia.org/wiki/Select_(Unix)[/url]

Using my copy of the Yocto GCC from the command line, currently installed in:

/opt/swi/y14-ext/tmp/sysroots/x86_64-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi/

And it seems to compile cleanly. So, I fired up DevStudio and created a new Legato project. I took the same code, added the Legato header and changed main into a compoent init. This still builds cleanly.

One thing you can check is to make sure that you have GCC configured. In DevStudio go to Window/Preferences. Under Developer Studio click GCC/GDB paths preferences. Make sure that the Legato Linux GCC toolchain location is set to something sensable.

Another thing you can try is create a new project by going to the menu and selecting File/New/Project… Then make sure you select Legato Project and not a generic C or C++ project option.

Note that there seems to be a bug in the new project wizard. If you create a project that defaults to the helloWorld template it creates an improper .adef file. To fix it right click on the adef file and select “Open With/Text Editor” and change the code from:

executables:

    helloWorld ( helloWorld.c )

To, adding quotes to the helloWorld.c:

executables:

    helloWorld ( "helloWorld.c" )

Give this a try and let me know how it works out.

Thanks,
-Kelly

Here’s the “component” version of the code I tried compiling:


#include "legato.h"

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <netdb.h>

#include <sys/select.h>
#include <fcntl.h>
#include <unistd.h>
#include <errno.h>

#include <sys/ipc.h>
#include <sys/shm.h>


#define PORT "9421"



/* function prototypes */
void die(const char *msg)
{
	perror(msg);
	exit(EXIT_FAILURE);
}



COMPONENT_INIT
{
	int sockfd, new, maxfd, on = 1, nready, i;

	struct addrinfo *res0, *res, hints;

	char buffer[BUFSIZ];

	fd_set master, readfds;

	ssize_t nbytes;

	(void)memset(&hints, '\0', sizeof(struct addrinfo));

	hints.ai_family = AF_INET;
	hints.ai_socktype = SOCK_STREAM;
	hints.ai_protocol = IPPROTO_TCP;
	hints.ai_flags = AI_PASSIVE;

	if(-1 == (getaddrinfo(NULL, PORT, &hints, &res0)))
		die("getaddrinfo()");

	for(res = res0; res; res = res->ai_next)
	{
		if(-1 == (sockfd = socket(res->ai_family, res->ai_socktype, res->ai_protocol)))
		{
			perror("socket()");
			continue;
		}

		if(-1 == (setsockopt(sockfd, SOL_SOCKET, SO_REUSEADDR, (char*)&on, sizeof(int))))
		{
			perror("setsockopt()");
			continue;
		}

		if(-1 == (bind(sockfd, res->ai_addr, res->ai_addrlen)))
		{
			perror("bind");
			continue;
		}

		break;

	}

	if(-1 == sockfd)
		exit(EXIT_FAILURE);

	freeaddrinfo(res0);

	if(-1 == (listen(sockfd, 32)))
		die("listen()");

	if(-1 == (fcntl(sockfd, F_SETFD, O_NONBLOCK)))
		die("fcntl()");

	FD_ZERO(&master);
	FD_ZERO(&readfds);

	FD_SET(sockfd, &master);

	maxfd = sockfd;

	for(;;)
	{
		memcpy(&readfds, &master, sizeof(master));

		(void)printf("running select()\n");

		if(-1 == (nready = select(maxfd+1, &readfds, NULL, NULL, NULL)))
			die("select()");

		(void)printf("Number of ready descriptor: %d\n", nready);

		for(i=0; i<=maxfd && nready>0; i++)
		{
			if(FD_ISSET(i, &readfds))
			{
				nready--;

				if(i == sockfd)
				{
					(void)printf("Trying to accept() new connection(s)\n");

					if(-1 == (new = accept(sockfd, NULL, NULL)))
					{
						if(EWOULDBLOCK != errno)
							die("accept()");

						break;
					}

					else
					{

						if(-1 == (fcntl(new, F_SETFD, O_NONBLOCK)))
							die("fcntl()");

						FD_SET(new, &master);

						if(maxfd < new)
							maxfd = new;
					}
				}
				else
				{
					(void)printf("recv() data from one of descriptors(s)\n");

					nbytes = recv(i, buffer, sizeof(buffer), 0);

					buffer[nbytes] = '\0';
					printf("%s", buffer);

					(void)printf("%zi bytes received.\n", nbytes);

					if(nbytes <= 0)
					{
						if(EWOULDBLOCK != errno)
							die("recv()");

						break;

					}

					close(i);
					FD_CLR(i, &master);

				}
			}

		}

	}
}

I also added the other includes you mentioned just to be safe:

#include <sys/ipc.h>
#include <sys/shm.h>

Thanks,
-Kelly

I wonder if there could be an issue with the order of the #include directives in your source. Some distros have different conditional compilation directives in their system includes than other distros, and I have seen that cause portability problems before.

Hiya,

Thanks for getting back to me - it’s much appreciated.

I’ve got some more questions though.

First, can I confirm that I’m running the same version of DS as you are? Below is an image of the Help->About window for the version I am running.
[attachment=2]aboutDS.png[/attachment]
I’ve checked the online updates and there doesn’t appear to be any new updates that I am missing.

My version of DS does not have this option. See the image:
[attachment=1]prefsDS.png[/attachment]
I have followed some notes from Matt Lewis about setting up DS - some string substitutions to enable the Legato Applications … but it may be that I’m using the compiler installed with DS, rather than the external Yocto compiler.

I’ve tried the Legato ‘Hello World’ Application - it doesn’t build in DS. Even editing the ADEF file as you suggest doesn’t build the hello world sample application. Using

[code]executables:
LegatoHello ( “LegatoHello.c” )

start:
LegatoHello
[/code] as the adef file, I get the following error:
[attachment=0]errorDS.png[/attachment]
I also get the same error if I compile from a makefile at the command line.

As I’ve been unable to get any ‘Legato Application’ Projects to compile, I’ve been using ‘Legato Linux GCC’ projects - which appears to use a different compiler (built in to DS - under the tools directory) which is missing the header files that I need.

If I can get the Legato Application projects (using the Yocto compiler in /opt/swi/…) to compile, I think I’ll have no further problems cross-compiling my application in DS. My code already compiles using the Yocto compiler when compiled from a makefile at the command line. It just segfaults (sigh :frowning: )

To summarize:
[ul][li]DS uses different compiler installations (even though they are the same version of GCC!) depending on if you are making a Legato Application or Legato Linux GCC project.[/li]
[li]The built in compiler (Legato Linux GCC) has a different set of header files to the Yocto GCC compiler used for applications[/li]
[li]There are some issues with the way DS builds the sample Legato Application project that need to be documented.[/li]
[li]A link to the Legato Application documentation would be useful.[/li][/ul]

Thanks again for helping.

ciao, Dave

Hi,

actually we’re about to push the latest DS version online, so that you have the version mentioned by Kelly.
The one that you have was compatible with alpha A release, which may explain the incompatibilities.

Another thing: DS doesn’t embed the ARM Linux GCC (yet), and relies on the Yocto GCC, whatever it is for “Legato Linux” projects or for “Legato Application” projects. The sole GCC compiler we have in the “tools” directory is the Open AT one, which is not compatible with Legato (as it is a “bare metal” ARM GCC toolchain). You shouldn’t even need to install it if you only aim to work with Legato in this DS installation.

Will keep you updated when the release is ready.

The latest build of DS 3.0 has been pushed online.
You should be able to update your install.

Hiya,

[quote=“daav”]The latest build of DS 3.0 has been pushed online.
You should be able to update your install.[/quote]

Thanks. Will do that tonight and let you know how I get on.

Are there any release notes available as PDF?

ciao, Dave

The release note will be pushed on the developer zone ASAP (probably early next week)

Hiya,

Any chance of being special and getting a draft copy early :smiley:

Ta, Dave

ok, but just because it is you :wink:

Hiya daav,

Ta. It’s nice to feel special :laughing:

ciao, Dave

Hi All,

I finally figured out why I was having the compilation problems with GCC in DS3.

In the previous version of DS3 (late 2013), I could not get the Legato Application projects to compile, so had switched to a C++ project, based on the LEGATO LINUX GCC (this is important!) toolchain. However, it appears that DS was NOT configured to use the Yocto GCC compiler for these projects - rather it was using the arm-none-eabi series of compilers found in the tools directory of DS3.

I’ve just checked with the latest update version of DS3, and creating a C++ project with the Legato Linux GCC toolchain now uses the Yocto GCC compiler, rather than the arm-none-eabi toolchain supplied as part of DS3.

Thanks to all those who helped to sort this out - and to the DS3 developer team for fixing the bugs!

ciao, Dave