Re: [Openocd-development] Build problem with 1770 and Mac OS X

[Rick Altherr]

On May 13, 2009, at 3:41 PM, Edgar Grimberg wrote:

But at the end, I got a ld error like:

ld: duplicated symbol _Jim_SetResult_sprintf

Mac OS X 10.5.7 and GCC 4.0.1

I had no problems with the old build where libtoolize
is not needed.

Did the transition leave around any old objects in your tree?  I

of files that should not have been there.  Try 'svn st --no-ignore'.

remember having similar problems, and I think I recall finding a bunch

I also get

ld: duplicate symbol _Jim_SetResult_sprintf in
.libs/libopenocd.lax/libxsvf.a/xsvf.o and
.libs/libopenocd_la-openocd.o

on a clean tree.

Regards,
Edgar
<bootstrap.patch>_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development

 int (*Jim_SetResult_sprintf)( Jim_Interp *p, const char *fmt, ... );





--
Rick Altherr
kc8...@kc8apf.net


 -- Unsigned

It looks like the Jim functions are being defined oddly. Most of them are declared JIM_STATIC which varies in meaning depending upon the #defines set. Preprocessing xsvf.c with the same options used during a build shows that jim.h is declaring the following: Thus, every file that includes jim.h is defining a global symbol named Jim_SetResult_sprintf that is a function pointer. This only showed up when using libtool since libtool builds with -fno-common. Without that, the global symbols are coalesced at link time. This all seems to stem from the definition of JIM_STATIC. It looks like we are accidentally setting JIM_EXTENSION in command.h. I tried moving that definition into command.c but that causes duplicate definitions between command.o and jim-eventloop.o. Someone with more knowledge of Jim and how extensions should work needs to look at this. "He said he hadn't had a byte in three days. I had a short, so I split it with him."

smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development