much further along, but.....
jblanton at masaka.cs.ohiou.edu
Mon Jun 11 09:47:18 EDT 2007
Bill Fassler wrote:
> Although I don't understand the error I was getting I got past it
> with the simple (most likely inappropriate) hack of just creating
> a soft link for iconv.h in the top level in pidgin and pointing to
> /usr/include/iconv.h. I seem to have gotten close to an
> executable, but no cigar.
I have some concern with this - /usr/include/iconv.h will be your
*local* iconv.h definition - not the definition for your
cross-compiler target. You need to use *only* include paths for
your target, not for your local host machine. It looked like
./configure was detecting locally-installed stuff, too - I suspect
because your pkg-config path wasn't set to only look at the
cross-compiler jazz. I forgot to mention that in my previous email
(or maybe didn't notice it until afterwards).
> I thought I passed in configure arguments such that I would be building a static binary, but apparently things are working that way. Finch still appears to building dynamically linked libraries which is certainly not the way I want to go for my first pass at this...Did I misunderstand? Doesn't --enable-static=yes do the trick or do I really have to pass each and every protocol seperately and if I do that will the entire binary be static?
> Here is where I'm failing now: (I thought finch didn't use gnome
It doesn't - gobject isn't gnome, it's glib.
> Making all in .
> make: Entering directory `/home/project/elf_flat/uClinux-dist/pidgin-2.0.0/libpurple'
> /bin/sh ../libtool --silent --tag=CC --mode=link bfin-uclinux-gcc -Wl,-elf2flt -g -g -O2 -o purple-client-example purple-client-example.o libpurple-client.la -Wl,--export-dynamic -pthread -L/opt/gnome/lib -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 -L/opt/gnome/lib -ldbus-glib-1 -ldbus-1 -lglib-2.0 -lnsl -lresolv
> /opt/gnome/lib/libgobject-2.0.so: could not read symbols: File in wrong format
Again, this is because you're linking against host-side libraries
instead of target libraries. The "wrong format" error when you're
cross-compiling almost always means that some part of the build
process is linking against your local libraries, instead of the
remote target libraries. I think this is a pkg-config error; I
think you might have to force PKG_CONFIG_PATH to point at wherever
the cross-compiled .pc files are located.
Hope this helps,
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: Digital signature
More information about the Devel