Coding using C on the Onion Omega

Lazar Demin

@huxflux Does your linker command include the linking instructions from the wiki article?

Also, do you have the onion spi library installed?
Run:

opkg update
opkg install libonionspi

To install the library

huxflux

@Lazar-Demin Yes, this is what I execute gcc main.c -loniondebug -lonionspi
Here's the testfile for compiling http://pastebin.com/gj8QT1k1. I also have libonionspi.so and liboniondebug.so in /usr/lib/.

Lazar Demin

@huxflux What output do you get when you run that command?
Maybe try adding -L /usr/lib so it knows where to look for the dynamic libraries?

huxflux

@Lazar-Demin Check out post #4 in this thread. I'll try with -L /usr/lib

Btw, minor detail. When I include onion-spi.h, that file also includes onion-debug.h. Which is not found at https://github.com/OnionIoT/spi-gpio-driver/ but found at https://github.com/OnionIoT/i2c-exp-driver

huxflux

I now have onion-spi.h from https://github.com/OnionIoT/spi-gpio-driver/ and onion-debug.h from https://github.com/OnionIoT/i2c-exp-driver and moved them to /usr/include. I execute gcc main.c -L /usr/lib -loniondebug -lonionspi and get this errormessage: http://pastebin.com/2K3eX8x4

Basically the same as post #4

Theodore Borromeo

@huxflux said:

spiParamInit

That is defined in: https://github.com/OnionIoT/spi-gpio-driver/blob/853a4ab5010cd23847e3b0ff87ff6b1bd1447187/src/onion-spi.c

soooooo, try to maybe include that in your build as well? perhaps something like:

gcc main.c onion-spi.c -loniondebug -lonionspi

or whatever. . .

however, the more i think about it, those libs should be providing the definition for what the headers declare. so the linking to the libs as well as pointing to usr/lib for the headers should just work. It seems that perhaps the libs work for omega folks as they have the headers working. Maybe their packages didn't properly export the headers upon library installation with opkg, and it works for them coincidentally?

Theodore Borromeo

so in light of all this, you're probably better off compiling it all by hand into your app yourself, if linking to the built libs aren't working. Of course, I'm hopeful that it is as simple as that and you don't need yet other libs. . .

huxflux

@Theodore-Borromeo That is exactly what I'm thinking. They're not including the header-files in their libonionspi and liboniondebug packages. But even when I've downloaded the headers from their github, they still don't work as I think they should. I'm no expert on these matters. Far from it.

I did manage to do something though. This is all on the Onion Omega. I downloaded onion-debug.c, onion-spi.c, onion-debug.h and onion-spi.h from github. I moved onion-debug.h and onion-spi.h to /usr/include. I then executed these commands:
gcc -Wall -fPIC -c onion-spi.c onion-debug.c
gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0 onion-spi.o onion-debug.o
ln -sf libctest.so.1.0 libctest.so.1
ln -sf libctest.so.1.0 libctest.so

We just made a dynamic library out of onion-spi.c.

Next step is to make a simple code for trying out the functions in the library. Lets call it main.c

#include <stdio.h>
#include <onion-spi.h>

int main(int argc, char *argv[])
{
struct spiParams params;
spiParamInit(&params);
return 0;
}

gcc main.c -L/root/coding/spi -Wl,-rpath,/root/coding/spi -lctest and voila! It works. Of course you'll have to change the paths to the correct places.

It is possible to build dynamic libraries from their code. It's also possible to compile and link using those dynamic libraries. And all this can be done on the Onion Omega itself.

I'll try to see if I can put all these files into the correct directories and see if the compiling and linking gets easier. Eg. gcc main.c -lonionspi.

EDIT: And that works out too. I can now compile with gcc main.c -lonionspi. Just change the name of libctest to libonionspi and mv libonionspi.so.1.0 /usr/lib/. Then just cd /usr/lib and make the symbolic links.

Well, I did learn a thing or two from this experience. Worth!

Theodore Borromeo

So if that worked, there is no reason you couldn't use -rpath options to just point out the header files you needed to properly utilize the provided spi libs, right?

You went through a lot of trouble to prove that their libs are in fact built from the sources you already have access to (well, similar enough that it at least doesn't error out), but all I was trying to point out were ways to satisfy the linkage dependencies in such a way to make gcc 'see' that the provided libs do in fact contain the definitions of those functions declared in the associated headers you fetched from github. . .i.e., try doing the first solution in:
http://stackoverflow.com/questions/22426574/gcc-undefined-reference-to

In any case, I do think @Lazar-Demin and @Boken-Lin should ensure that the libraries do provide the exported headers so that the APIs work 'out of the box' I would be heartbroken if I have to figure out the 'hard' linkage flags necessary to do this.

Thankfully, we aren't needing to use prelinked tables for library loading such that you could even use the -fPIC option. However, once I see these types of options, my eyes tend to glaze over. I still don't get why developers need to know this much to make code 'go'. We should just insist on python already

huxflux

@Theodore-Borromeo That's what I thought, but it's not the case. Using -rpath options together with their libonionspi.so did nothing. I'm not sure what's going on.

Anyway, I was doing this for fun, and to prove a point. It is possible to compile and link on the Onion Omega using gcc. If you have the diskspace, since gcc is about 22MB.

Cloud compiling is coming soon. No need for this stuff.