>
> 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.
I will send you the "rebased" patch in few days.
Michael
------------------------------------------------------------------------------
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
