On Wed, 2009-05-13 at 20:56 -0700, Rick Altherr wrote: > On May 13, 2009, at 8:42 PM, Zach Welch wrote: > > > On Wed, 2009-05-13 at 16:42 -0700, Rick Altherr wrote: > >> 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 > >>>> remember having similar problems, and I think I recall finding a > >>>> bunch > >>>> of files that should not have been there. Try 'svn st --no- > >>>> ignore'. > >>>> > >>> > >>> > >>> 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 > >>> [email protected] > >>> https://lists.berlios.de/mailman/listinfo/openocd-development > >> > >> > >> 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: > >> > >> int (*Jim_SetResult_sprintf)( Jim_Interp *p, const char *fmt, ... ); > >> > >> 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. > > > > Thanks for doing this research. Based on this, it looks like the > > definition should be removed; it does not seem to be necessary or > > appropriate for our situation. My build works fine without it, so I > > have attached a patch for others to test. > > > > If this change resolves the problem, I will apply it. > > > > Cheers, > > > > Zach > > > > <openocd-remove-define-jim-embedded.patch> > > > Appears to work on 10.5.7 w/ Xcode 3.1.2 as well.
Well... I committed it for you as r1790, and it was just reverted in r1793. I must therefore assume that the proper solution will be... an #if/#ifdef conditional on DARWIN or IS_CYGWIN to wrap that definition? I am not sure at this point, but somebody needs to dig into this. Øyvind? You're one of our Jim experts.... :) Cheers, Zach _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
