Re: [Openocd-development] Build problem with 1770 and Mac OS X
Committed. - Cygwin w/CFLAGS=-fno-common. Builds + no crash. - Cygwin plain build. Builds + no crash. - Cygwin w/CFLAGS=-mno-cygwin. Fails for other reasons(include files). - Mac. Builds + no crash. - Linux. Builds + no crash. Thanks to Edgar Grimberg for debugging & diagnosing the problem! A remark on Jim Tcl: I'm not happy about that it is has all this "clever" stuff w.r.t. DLLs vs. being embedded. Really where Jim Tcl shines is when it is embedded into an application and it should be more straightforward to do so... -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com Index: C:/workspace/openocd/src/helper/jim.h === --- C:/workspace/openocd/src/helper/jim.h (revision 1793) +++ C:/workspace/openocd/src/helper/jim.h (working copy) @@ -632,7 +632,7 @@ #define JIM_API( X ) X #else #ifndef __JIM_CORE__ -# if defined JIM_EXTENSION || defined JIM_EMBEDDED +# if defined JIM_EMBEDDED # define JIM_API(x) (*x) # define JIM_STATIC # else ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
I've committed this. It's less wrong than what's currently in svn. Tested on Linux & Cygwin. Still fails on Mac. Looking into part #2 to fix Mac(or -fno-common rather). -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
> > OS X's linker is complaining because the build is using -fno-common which > specifically turns multiple global symbols of the same name into an error. > In this case, it's not a gcc issue at all (I'm using 4.0.1 rather than 4.4 > anyway). If you preprocess the source for those two files, you'll see that > both declare all of the JIM functions as global function pointers. I'm not > sure why the JIM code does this when JIM_EMBEDDED is turned on or why that > is necessary at all. > Further more, if you set CFLAGS to include -fno-common in Linux, gcc 4.1.2, this error appears on link: ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x1bc): multiple definition of `Jim_GetApi' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x1b4): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0xc): multiple definition of `Jim_Alloc' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x4): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x10): multiple definition of `Jim_Free' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x8): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x18): multiple definition of `Jim_Eval' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x10): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x1c): multiple definition of `Jim_Eval_Named' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x14): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x20): multiple definition of `Jim_EvalGlobal' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x18): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x24): multiple definition of `Jim_EvalFile' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x1c): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x28): multiple definition of `Jim_EvalObj' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x20): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x2c): multiple definition of `Jim_EvalObjBackground' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x24): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x30): multiple definition of `Jim_EvalObjVector' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x28): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x54): multiple definition of `Jim_InitHashTable' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x4c): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x58): multiple definition of `Jim_ExpandHashTable' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x50): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x5c): multiple definition of `Jim_AddHashEntry' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x54): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x60): multiple definition of `Jim_ReplaceHashEntry' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x58): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x64): multiple definition of `Jim_DeleteHashEntry' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x5c): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x68): multiple definition of `Jim_FreeHashTable' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x60): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x6c): multiple definition of `Jim_FindHashEntry' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x64): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x70): multiple definition of `Jim_ResizeHashTable' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x68): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x74): multiple definition of `Jim_GetHashTableIterator' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x6c): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x78): multiple definition of `Jim_NextHashEntry' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x70): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x7c): multiple definition of `Jim_NewObj' ../src/helper/.libs/libhelper.a(libhelper_la-jim-eventloop.o):(.bss+0x74): first defined here ../src/helper/.libs/libhelper.a(libhelper_la-command.o):(.bss+0x80): multiple definition of `Jim_FreeObj' ../src/he
Re: [Openocd-development] Build problem with 1770 and Mac OS X
On May 15, 2009, at 11:31 AM, Øyvind Harboe wrote: Still an issue on OS X. Same problem, duplicate JIM symbols but now the locations have changed: Is this an OS X or gcc 4.4 problem? I'd like to have a confirmation that the patch works on Linux so I can commit it and we can concentrate on the OS X(or GCC 4.4?) problem. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com OS X's linker is complaining because the build is using -fno-common which specifically turns multiple global symbols of the same name into an error. In this case, it's not a gcc issue at all (I'm using 4.0.1 rather than 4.4 anyway). If you preprocess the source for those two files, you'll see that both declare all of the JIM functions as global function pointers. I'm not sure why the JIM code does this when JIM_EMBEDDED is turned on or why that is necessary at all. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
> Still an issue on OS X. Same problem, duplicate JIM symbols but now the > locations have changed: Is this an OS X or gcc 4.4 problem? I'd like to have a confirmation that the patch works on Linux so I can commit it and we can concentrate on the OS X(or GCC 4.4?) problem. -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
On May 15, 2009, at 6:16 AM, Øyvind Harboe wrote: It's a faux pas to revert commits like that without discussing it with said committer, but since it caused a SEGFAULT on Cygwin and I figured you were asleep I didn't want you to wake up to a flurry of emails about Cygwin SEGFAULTs... Your fix was correct, but not complete, hence the SEGFAULT... 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 :) How's the attached patch? Tested on: - cygwin - embedded host, where Jim Tcl is provided by athttpd and not embedded into OpenOCD Missing tests: - mac - linux -- Øyvind Harboe Embedded software and hardware consulting services http://consulting.zylin.com Still an issue on OS X. Same problem, duplicate JIM symbols but now the locations have changed: ld: duplicate symbol _Jim_SetResult_sprintf in .libs/libopenocd.lax/ libhelper.a/libhelper_la-jim-eventloop.o and .libs/libopenocd.lax/ libhelper.a/libhelper_la-command.o So, it's a conflict between jim-eventloop.c and command.c. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
It's a faux pas to revert commits like that without discussing it with said
committer, but since it caused a SEGFAULT on Cygwin and I figured
you were asleep I didn't want you to wake up to a flurry of emails
about Cygwin SEGFAULTs...
Your fix was correct, but not complete, hence the SEGFAULT...
> 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 :)
How's the attached patch?
Tested on:
- cygwin
- embedded host, where Jim Tcl is provided by athttpd and not embedded into
OpenOCD
Missing tests:
- mac
- linux
--
Øyvind Harboe
Embedded software and hardware consulting services
http://consulting.zylin.com
### Eclipse Workspace Patch 1.0
#P openocd
Index: src/helper/command.h
===
--- src/helper/command.h(revision 1793)
+++ src/helper/command.h(working copy)
@@ -32,7 +32,6 @@
/* Jim is provied by eCos */
#include
#else
-#define JIM_EMBEDDED
#include "jim.h"
#endif
Index: src/helper/command.c
===
--- src/helper/command.c(revision 1793)
+++ src/helper/command.c(working copy)
@@ -30,6 +30,11 @@
#include "config.h"
#endif
+#if !BUILD_ECOSBOARD
+/* see Embedder-HOWTO.txt in Jim Tcl project hosted on BerliOS*/
+#define JIM_EMBEDDED
+#endif
+
// @todo the inclusion of target.h here is a layering violation
#include "target.h"
#include "command.h"
@@ -675,7 +680,7 @@
context->output_handler = NULL;
context->output_handler_priv = NULL;
-#ifdef JIM_EMBEDDED
+#if !BUILD_ECOSBOARD
Jim_InitEmbedded();
/* Create an interpreter */
interp = Jim_CreateInterp();
@@ -721,7 +726,7 @@
add_default_dirs();
-#ifdef JIM_EMBEDDED
+#if !BUILD_ECOSBOARD
Jim_EventLoopOnLoad(interp);
#endif
if (Jim_Eval_Named(interp, startup_tcl,
"embedded:startup.tcl",1)==JIM_ERR)
@@ -800,7 +805,7 @@
void process_jim_events(void)
{
-#ifdef JIM_EMBEDDED
+#if !BUILD_ECOSBOARD
static int recursion = 0;
if (!recursion)
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
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 > >>> ___ > >>> Openocd-development mailing list > >>> Openocd-development@lists.berlios.de > >>> 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 > > > > > > > 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 Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de 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 Appears to work on 10.5.7 w/ Xcode 3.1.2 as well. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
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 > > ___ > > Openocd-development mailing list > > Openocd-development@lists.berlios.de > > 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 Index: src/helper/command.h === --- src/helper/command.h (revision 1781) +++ src/helper/command.h (working copy) @@ -32,7 +32,6 @@ /* Jim is provied by eCos */ #include #else -#define JIM_EMBEDDED #include "jim.h" #endif ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
On Thu, May 14, 2009 at 2:12 AM, Edgar Grimberg wrote: >> >> Fixed on my rocket. >> > > Now I get something else: > > /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall > -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter > -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror -o > libopenocd.la -rpath /usr/local/lib libopenocd_la-openocd.lo > ../src/xsvf/libxsvf.la ../src/svf/libsvf.la ../src/pld/libpld.la > ../src/jtag/libjtag.la ../src/flash/libflash.la > ../src/target/libtarget.la ../src/server/libserver.la > ../src/helper/libhelper.la > libtool: link: `libopenocd_la-openocd.lo' is not a valid libtool object > make[3]: *** [libopenocd.la] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 > False alarm, this looks like leftovers from some funny previous build. I checked out a fresh tree and I get just the ld: duplicate symbol _Jim_SetResult_sprintf in .libs/libopenocd.lax/libxsvf.a/xsvf.o and .libs/libopenocd_la-openocd.o error. Edgar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
> > Fixed on my rocket. > Now I get something else: mac-mini:build edgar$ rm -rf * mac-mini:build edgar$ ../configure --enable-maintainer-mode --enable-dummy . onfigure: creating ./config.status config.status: creating Makefile config.status: creating src/Makefile config.status: creating src/helper/Makefile config.status: creating src/jtag/Makefile config.status: creating src/xsvf/Makefile config.status: creating src/svf/Makefile config.status: creating src/target/Makefile config.status: creating src/server/Makefile config.status: creating src/flash/Makefile config.status: creating src/pld/Makefile config.status: creating doc/Makefile config.status: creating config.h config.status: config.h is unchanged config.status: executing depfiles commands config.status: executing libtool commands mac-mini:build edgar$ make make all-recursive Making all in src Making all in helper make[3]: Nothing to be done for `all'. Making all in jtag make[3]: Nothing to be done for `all'. Making all in xsvf make[3]: Nothing to be done for `all'. Making all in svf make[3]: Nothing to be done for `all'. Making all in target make[3]: Nothing to be done for `all'. Making all in server make[3]: Nothing to be done for `all'. Making all in flash make[3]: Nothing to be done for `all'. Making all in pld make[3]: Nothing to be done for `all'. /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -g -O2 -Wall -Wstrict-prototypes -Wformat-security -Wextra -Wno-unused-parameter -Wbad-function-cast -Wcast-align -Wredundant-decls -Werror-o libopenocd.la -rpath /usr/local/lib libopenocd_la-openocd.lo ../src/xsvf/libxsvf.la ../src/svf/libsvf.la ../src/pld/libpld.la ../src/jtag/libjtag.la ../src/flash/libflash.la ../src/target/libtarget.la ../src/server/libserver.la ../src/helper/libhelper.la libtool: link: `libopenocd_la-openocd.lo' is not a valid libtool object make[3]: *** [libopenocd.la] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all] Error 2 Edgar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
On Thu, May 14, 2009 at 1:41 AM, Zach Welch wrote: > On Thu, 2009-05-14 at 01:00 +0200, Edgar Grimberg wrote: >> >> Right. I forgot about this madness. *sigh* An updated bootstrap >> >> script has been committed as r1779. >> > >> > The attached patch does the trick for bootstrap. :) >> > >> >> Now that we are at MacOS issues, when I do: >> >> mac-mini:build edgar$ ../configure --enable-maintainer-mode --enable-dummy >> >> I get: >> >> checking net/if.h presence... yes >> configure: WARNING: net/if.h: present but cannot be compiled >> configure: WARNING: net/if.h: check for missing prerequisite headers? >> configure: WARNING: net/if.h: see the Autoconf documentation >> configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" >> configure: WARNING: net/if.h: proceeding with the preprocessor's result >> configure: WARNING: net/if.h: in the future, the compiler will take >> precedence >> configure: WARNING: ## >> -- >> ## >> configure: WARNING: ## Report this to OpenOCD Mailing List >> ## >> configure: WARNING: ## >> -- > > Thanks for reporting this. Is it fixed in r1781? I simply followed > autoconf's instructions to solve it, so I expect it should do the job. > Fixed on my rocket. Thanks, Edgar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
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 ___ Openocd-development mailing list Openocd-development@lists.berlios.de 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. -- Rick Altherr kc8...@kc8apf.net "He said he hadn't had a byte in three days. I had a short, so I split it with him." -- Unsigned smime.p7s Description: S/MIME cryptographic signature ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
On Thu, 2009-05-14 at 01:00 +0200, Edgar Grimberg wrote: > >> Right. I forgot about this madness. *sigh* An updated bootstrap > >> script has been committed as r1779. > > > > The attached patch does the trick for bootstrap. :) > > > > Now that we are at MacOS issues, when I do: > > mac-mini:build edgar$ ../configure --enable-maintainer-mode --enable-dummy > > I get: > > checking net/if.h presence... yes > configure: WARNING: net/if.h: present but cannot be compiled > configure: WARNING: net/if.h: check for missing prerequisite headers? > configure: WARNING: net/if.h: see the Autoconf documentation > configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" > configure: WARNING: net/if.h: proceeding with the preprocessor's result > configure: WARNING: net/if.h: in the future, the compiler will take precedence > configure: WARNING: ## > -- > ## > configure: WARNING: ## Report this to OpenOCD Mailing List > ## > configure: WARNING: ## > -- Thanks for reporting this. Is it fixed in r1781? I simply followed autoconf's instructions to solve it, so I expect it should do the job. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
On Thu, 2009-05-14 at 00:41 +0200, Edgar Grimberg wrote: > Hi, > > > > Right. I forgot about this madness. *sigh* An updated bootstrap > > script has been committed as r1779. > > The attached patch does the trick for bootstrap. :) D'oh. Fixed in r1780. Thanks. :) > >> 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. I am still a little uncertain about this one. I will keep digging. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
>> Right. I forgot about this madness. *sigh* An updated bootstrap >> script has been committed as r1779. > > The attached patch does the trick for bootstrap. :) > Now that we are at MacOS issues, when I do: mac-mini:build edgar$ ../configure --enable-maintainer-mode --enable-dummy I get: checking net/if.h presence... yes configure: WARNING: net/if.h: present but cannot be compiled configure: WARNING: net/if.h: check for missing prerequisite headers? configure: WARNING: net/if.h: see the Autoconf documentation configure: WARNING: net/if.h: section "Present But Cannot Be Compiled" configure: WARNING: net/if.h: proceeding with the preprocessor's result configure: WARNING: net/if.h: in the future, the compiler will take precedence configure: WARNING: ## -- ## configure: WARNING: ## Report this to OpenOCD Mailing List ## configure: WARNING: ## -- ## Regards, Edgar ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
Hi, > Right. I forgot about this madness. *sigh* An updated bootstrap > script has been committed as r1779. The attached patch does the trick for bootstrap. :) >> 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 Description: Binary data ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
On May 14, 2009, at 0:06, Michael Fischer wrote: > Hello list, > > please can some one test if it is possible > to build the 1770 on Mac OS X? > Here I need libtoolize, but this was not found, > even if I install libtool over mac port. > I only found glibtoolize, therefore I set a symbolic > link to libtoolize. > But at the end, I got a ld error like: > ld: duplicated symbol _Jim_SetResult_sprintf Same here: "ld: duplicate symbol _Jim_SetResult_sprintf in .libs/ libopenocd.lax/libxsvf.a/xsvf.o and .libs/libopenocd_la-openocd.o". This was a fresh source tree, built in a separate directory out of the source tree, so no chance of stale object files. It seems Fink sets up the libtoolize->glibtoolize symlink automatically, but it would be nice if the configuration mechanism would pick up this by itself. Regards, -Anders ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Build problem with 1770 and Mac OS X
On Wed, 2009-05-13 at 23:06 +0200, Michael Fischer wrote: > Hello list, > > please can some one test if it is possible > to build the 1770 on Mac OS X? > > Here I need libtoolize, but this was not found, > even if I install libtool over mac port. > > I only found glibtoolize, therefore I set a symbolic > link to libtoolize. Right. I forgot about this madness. *sigh* An updated bootstrap script has been committed as r1779. "Think Different" and this is what it gets you. ;) :) > 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'. Cheers, Zach ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] Build problem with 1770 and Mac OS X
Hello list, please can some one test if it is possible to build the 1770 on Mac OS X? Here I need libtoolize, but this was not found, even if I install libtool over mac port. I only found glibtoolize, therefore I set a symbolic link to libtoolize. 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. Best regards, Michael ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
