Using code compiled in OpenSUSE on a microcontroller running Gentoo Linux

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.