Clint,
 
I will try the approach with "icall.h" as you said. It's very interesting because I can learn deeper of Unicon architecture in this case.
But with "icall.h" one thing is unclear. I have tried this for cygwin and Icon. All is OK. But during building the shared library I need to specify iconx.a (Icon runtime library?). For example, below is an extraction from mkbuild.sh used for library building (http://www.cs.arizona.edu/icon/library/src/cfuncs/mklib.sh) :
   CYGWIN*)
      # move the win32 import library for iconx.exe callbacks
      # created when iconx.exe was built
      if [ -e $BIN/../src/runtime/iconx.a ]; then
         mv $BIN/../src/runtime/iconx.a $BIN
      fi
      $CC -shared -Wl,--enable-auto-import -o $LIBNAME "$@" $BIN/iconx.a;;
In the case of pure Windows and Unicon what I need to specify instead?
 
Best regards,
Sergey
 
20.02.2014, 14:10, "Jeffery, Clint (jeffe...@uidaho.edu)" <jeffe...@uidaho.edu>:

Sergey,

 

I have used loadfunc() to call C from Windows Unicon before, but it was a long time ago. The C calling interface main header file icall.h has some #ifdef WIN32 code that I put in at the time, but seems to be missing some updates needed to account for recent changes in the virtual machine runtime system. In any case, it appears that you are including Unicon header files from bitcount.c that are causing trouble. I don't really know what you've done to your bitcount.c (included a fib.c along with our headers?) since you did not share it.  Loaded C files are generally better off to just use icall.h, and if icall.h needs updating, that is the simplest fix.

 

curpstate stands for "current program state". It is a global variable in Unicon's virtual machine. Among other things, curpstate is accessed by macros in the Unicon runtime system in order to select which actual implementation of cnv_int() and similar C functions in iconx are in use at present: cnv_int_0 or cnv_int_1 for example. If Concurrent is enabled, that may complicate things related to curpstate further, at which point I let Jafar explain stuff.

 

To sum up: stop including Unicon header files, and change your icall.h to use cnv_int_0 instead of cnv_int. Or if you insist on including Unicon header files, figure out how to get your shared library that you are building to where it knows about and can access this global variable that lives inside iconx.exe/wiconx.exe or whatever .exe's you build using Unicon. This might involve extra command line arguments when building (especially linking) iconx, but before you get to that point, you are right, you have to be able to build your shared library first.

 

Cheers,

Clint

 


From: Sergey Logichev <slogic...@yandex.ru>
 
...step of shared linrary creation is failed:
 
>gcc -c bitcount.c -I../../../src/h -I../../../src/gdbm -I../../../src/libtp
 
>gcc -shared -Wl,--enable-auto-import -o libfunc.so bitcount.o
bitcount.o:bitcount.c:(.text+0x14): undefined reference to `curpstate'
collect2.exe: error: ld returned 1 exit status
 
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
Unicon-group mailing list
Unicon-group@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/unicon-group

Reply via email to