Using code compiled in OpenSUSE on a microcontroller running Gentoo Linux

I want to use code the I compiled on a desktop running OpenSUSE linux, and port it over to a microcontroller running Gentoo Linux. The primary means of sending data between the desktop and the microcontroller is to remove the microcontroller's memory card and insert it into a usb card reader connected to my desktop.

Through the USB card reader, I have access to all the files, including all root folder files, that are part of the microcontroller's linux operating system. I can essentially install any program, package, library or module to this operating system as if it were my desktop computer.

The problem is the system discrepancy, if I do install any packages to the microcontroller memory, those packages will be compiled in a openSUSE operating system, but ultimately used by a Gentoo Linux operating system. I have no idea what kinds of problems this might cause.

Any advice on how to approach this issue would be greatly appreciated.

Thanks for the help.

Can you take the source code and compile it on the Gentoo system? That would be the most straightforward way to do things.

What are the kernel versions on the two systems? (Type uname -r.) Are they both running on 32-bit Intel CPUs, for example? If so, you could try it. There might be other issues, though, like incompatible versions of libc or something.

You can tell GCC to target different platforms, assuming you have access to the source code. I don't know how, since I've never needed to.

Is the microcontroller an x86-based processor? Or something like ARM or MIPS?

--
Mats

I am using a PC104 stack for the microcontroller. Apparently they come in all kinds of configurations so I am not sure what processor architecture it is using. I will have to look it up or perhaps even disassemble the stack to get. Although the uppoermost chip on the stack is the firewire controller and that uses a 32-bit PCI bus, which leads me to assume the CPU module would also use a 32-bit chip.

The Desktop uses an Intel Pentium 4, and is a 32-bit architecture. The Kernel is 2.6.18.8-0.5-default.

The PC104 stack Kernel is 2.6.14-gentoo-r5.

As far as compiling on a Gentoo system, I don't have access to any systems with it installed. I could install Gentoo on my desktop, but the operating system is a major project to set up, and it is nearly impossible for me to get any assistance in using it. Most people who I managed to contact for assistance with Gentoo Linux simple told me to install another version of Linux. Its emerge function is completely arcane and I have absolutely no understanding of it, yet that is what I need to get programs like gcc to work on it. So I would prefer not to have to deal with any more Gentoo Linux than I need to.

Emerge is anything but arcane. But this is not a place to advertise Gentoo.

In fact, I rather think that Gentoo is a poor choice for such an inaccessible system as you're building. Why do you need Gentoo just to get GCC to work?

I don't need Gentoo to get gcc to work. I have gcc installed on OpenSUSE linux on the desktop, with a working copy of gcc and the program I compiled in gcc. I want to move said program to the microcontroller, which runs Gentoo Linux for no other reason than is what it came with.

Now, the program is already a fully compiled stand alone application when I send it to the microcontroller. So I just send it over using the USB card reader and try to run it. However, the microcontroller claims it is missing libraries that it needs to run the program.

You could try adding -static on the gcc line that produces the final binary (e.g. gcc -o myprog myprog.o blah.o -lsomething -static).

--
Mats

Interesting, it is giving me a cannot find -lcxcore error when compiling. That is the same error I was getting when I attempted to run the program on the PC104. This might work(as soon as a find this lcxcore).

Thanks for the help.

Well, -static means "link everything into the binary" or, put a different way, "don't use shared libraries". Of course, if "libcxcore.a" doesn't exist, then you can't link against it....

--
Mats

Apparantly, cxcore is part of openCV. There are several files named cxcore on my machine, but none name libcxcore. Either my install of openCV is incomplete or the make file is not properly obtaining the files.

Quote:

---

Originally Posted by Phanixis

Apparantly, cxcore is part of openCV. There are several files named cxcore on my machine, but none name libcxcore. Either my install of openCV is incomplete or the make file is not properly obtaining the files.

---

You probably need to install somethng like OpenCV-devel or such.

--
Mats

That might be the case. My makefile is currently searching for the necessary files in a strange filepath that currently doesn't exist on my machine:

/usr/lib/gcc/i586-suse-linux/4.1.2/../../../../i586-suse-linux/bin/ld: cannot find -lcxcore

Mind you, I have no idea why it is searching that particular path, the line in make that produces this error is:

-g++ -o (all my .o files) -lcxcore

And nowhere in the make file do I tell it to look up the above filepath. The one I provided make with is "/usr/local/include/opencv". I have no idea were the program got the idea to search that rather long filepath for cxcore.

Quote:

---

Originally Posted by Phanixis

/usr/lib/gcc/i586-suse-linux/4.1.2/../../../../i586-suse-linux/bin/ld: cannot find -lcxcore

Mind you, I have no idea why it is searching that particular path

---

You have a version-specific installation of binutils. Not typical, but nothing wrong with it, either. It's not looking for a library there. That's where the "ld" binary is -- read the message more closely.

Ok, I found out that when I statically compile the code, I apparently need to statically compile all the libraries it is using. I statically compiled the openCV libraries on my computer and reinstalled them, and I was able to get rid of the errors. Problem is that now it is telling me it can't find various gtk functions on compiling, which means I might have to statically recompile that as well.

Thanks for the help. Hopefully I will get this to work eventually.

Quote:

---

Originally Posted by Phanixis

Ok, I found out that when I statically compile the code, I apparently need to statically compile all the libraries it is using.

---

That shouldn't be the case... Can you give any more details on what you've tried? Recompiling GTK is going to really suck.

EDIT: Do you mean "link it statically?" In that case, yes, all the libraries need to be static, but I would strongly recommend against linking it statically in the first place. If you can't dynamically link with cxcore, that's a separate issue we should investigate.

By statically compile the code, I mean link it statically. If you look up several topics, this was a suggestion given by matsp to avoid any conflicts between the operating system that I am using on my desktop, which is openSUSE, and the operating system running on the PC104, which is a copy of Gentoo Linux.

From what I have been doing, it seems like the libcxcore libraries on the two systems are incompatible. So a dynamically linked program compiled on one machine using opencv will not work on the other.

I have tried statically linking the code using -static, only to get an error saying that libcxcore could not be located. So, I went back to the copy of opencv 1.0.0 that I obtained from sourceforge.net, gave a /configure --enable-static instruction that told make the statically link the opencv libraries after compiling, then ran make clean, make, and make install.

The result installed things like libcxcore.a onto Linux, allowing my program to recognize opencv when I statically linked it. Unfortunately, it now would not recognize several other things, including libdc1394. libraw1394, and gtk. I have libdc1394 and libraw1394 source code from sourceforge.net, so I can just do the same thing I did with them that I did with opencv. Unfortunately, gtk either came with the Linux install or was installed through YaST as a dependacy, and I lack the source code to do the same with it.

Quote:

---

Originally Posted by Phanixis

The result installed things like libcxcore.a onto Linux, allowing my program to recognize opencv when I statically linked it. Unfortunately, it now would not recognize several other things, including libdc1394. libraw1394, and gtk. I have libdc1394 and libraw1394 source code from sourceforge.net, so I can just do the same thing I did with them that I did with opencv. Unfortunately, gtk either came with the Linux install or was installed through YaST as a dependacy, and I lack the source code to do the same with it.

---

If you give the -static option to the linker, it has to link EVERYTHING statically. If you want to try linking only CERTAIN libraries statically, just list their archives on the link line as if they were object files instead of linking with the "-l" flag:

Code:

---

gcc -o program -lsomething -lsomething_else /path/to/libcxcore.a

---

That links cxcore statically, the other stuff dynamically (if possible). If you really want a fully static link, there are ways to "massage" a shared library to turn it into a static library, without recompiling everything.

EDIT: Off the top of my head, I'm not remembering how to do what I just said. I might be hallucinating, although it seems it should be possible. I'll keep looking at it..

That is an incredibly helpful suggestion. This will definitely make my life easier.

Thanks.

Quote:

---

Originally Posted by Phanixis

That is an incredibly helpful suggestion. This will definitely make my life easier.

Thanks.

---

I wasn't hallucinating! There is a project called "ELF Statifier" which takes a dynamically linked binary and turns it into a static image. So if all you have are dynamic libs, and you want to produce a static executable, this might allow you to do it.

I will have to try that program.

In the mean time, I tried your suggestion of statically linking only the library components that were giving me problems. In this case, the PC-104 is saying that it cannot find the library libcxcore.so.1. So I gave make the instructions /usr/local/lib/libcxcore.a and /usr/local/libcxcore.so.1 for the linking stage, but it has not corrected the situation.

I tried out Elf Statifier, it looks a good program but the instructions don't seem to be very thorough. I tried creating an executable using this program, only to get a "Failed to read a valid object file image from memory." message, and executable it creates immediately produces a segmentation fault when I run it. I could really use some troubleshooting documentation for this thing.

It's strange. I never saw statifier faled like this.

Could you please post your problem to statifier's forum
https://sourceforge.net/forum/forum.php?forum_id=358807
with following details:
statifier's version
gdb version
your distro
kernel version
platform (x86/x86_64)
output of
statifier -v orig_program statified_program

Valery.
P.S. you can also try ermine (http://magicErmine.com)

Ok, I will do that. Only problem is that I will not be able to fit the verbose output on a forum post, because it is that long.

Never mind, "Failed to read a valid object file image from memory"
provide enough information.

I found this bug report
https://bugzilla.novell.com/show_bug.cgi?id=258433

and I'll try to work around it.

Valery.

Ok, I have yet to get Statifier working, but I tried Ermine and it was able to compile the file I need without giving any explicit error messages.

However, I get the error: Bad File Descriptor(9) when I run the executable on the PC-104.

Any idea why?

Thanks.

Quote:

---

Originally Posted by Phanixis

Ok, I have yet to get Statifier working, but I tried Ermine and it was able to compile the file I need without giving any explicit error messages.

However, I get the error: Bad File Descriptor(9) when I run the executable on the PC-104.

Any idea why?

Thanks.

---

Try using "strace" to see where it's going wrong. [You may want to use "strace app 2> blah.txt" - as seeing the last 20 or so lines usually just show you that it printed an error message and some cleanup, rather than what actually went wrong]

--
Mats

Quote:

---

Originally Posted by Phanixis

Ok, I have yet to get Statifier working, but I tried Ermine and it was able to compile the file I need without giving any explicit error messages.

However, I get the error: Bad File Descriptor(9) when I run the executable on the PC-104.

Any idea why?

Thanks.

---

Did you get same error when you run packed executable on the openSUSE system ?
Could you send output of
1) ldd your_program
2) ERMINE_SELF_LOG_MASK=1 your_program.ermine

Valery

But, first, you should take a step back and ensure that you _can_ write a binary that will execute on the other machine. Are you SURE that you are working with an x86? Have you attempted to compile a "Hello World" on the build machine for the host? If you cannot do this, then you start over from scratch with BuildRoot or crosstools.