much further along, but.....

[Joshua Blanton]

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
> libraries...)

It doesn't - gobject isn't gnome, it's glib.

> Making all in .
> make[4]: 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,
--jtb
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://pidgin.im/pipermail/devel/attachments/20070611/545ba930/attachment.sig>