On Wednesday, June 29, 2011 06:04:10 Michael Vacek wrote: > > building on 64bit systems still produces ugly warnings. looking at the > > code, it seems to assume that the size of pointers are 32bit, and that's > > just broken. not sure how you'll want to fix. > > > > in jamsym.h, the value member could probably be patched to "mostly" work > > by changing the type from uint32_t to unsigned long. > > The problem is that the original Altera/Actel stapl code is not designed > for 64-bit systems and it does not work on them. To make the software run > on 64-bit architecture, int32_t must be set to longs and all code > blocks containing explicit (long) and (long*) casting must be fixed. The > suspicious castings are on several places in jamarray.c, jamexec.c, and > jamheap.c. (as mentioned in TODO file) However, the task is not easy at all > and we are now busy to implement necessary changes. We plan that we or > others using and contributing from urjtag stapl extension make it work on > 64-bit system in the future. So, we recommend that stapl support would be > now implicitly disabled in configure for 64-bit builds.
sorry, but i'm not really comfortable adding code that only works on 32bit systems. especially for desktop systems where 32bit is dying. -mike
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________ UrJTAG-development mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/urjtag-development
