Hello, Vedge,
Huge fan of libagar. I'm Brian Tiffin, with the GnuCOBOL project (in Ottawa by the way), and have almost finished up on a user defined function repository binding to a fair number of Agar features and widgets.
I work on a GNU/Linux 64bit machine, and some of the inline modifiers are making the integration a little tricky. The GnuCOBOL CALL verb relies on dynamic linking via dlsym. Some functions, AG_Unit2Unit for instance are coming up
prompt$ cobc -xj units.cob $(agar-config --libs)
libcob: cannot find module 'AG_Unit2Unit'
Some of the COBOL for this trial
call "AG_FindUnit" using
by content "ft" & x"00"
returning address of agar-feet
call "AG_FindUnit" using
by content "m" & x"00"
returning address of agar-metres
move pi to metres
call "AG_Unit2Unit" using
by value metres
by reference agar-metres agar-feet
returning feet
The static inline double declaration is not creating a dlsym findable link symbol. Where as the FindUnit call works ok, due to the entry in BEGIN_DECLS, sans inline. This issue is many fold worse when trying (salivating for) AG_Web and --enable-web 1.5.1 builds.
To give you a more complete picture, I've documented most of the work behind the current bindings in a thread on SourceForge, https://sourceforge.net/p/open-cobol/discussion/cobol/thread/c2ac66c1/
The objective with the function repository is for developer code in COBOL along the lines of
move agar-unit2unit(metric-measure, ag-metres, ag-feet) to standard-measure
I've hacked up a compile of 1.5.1 on Ubuntu and Fedora so far, but I'm a bit defeated on finding the symbols that are small t and not big T in nm listings.
One technical point, seemed easy to get round in web.c. GNU/Linux has no sun_len element in sockaddr_un the and it only seems to be a place holder (perhaps needed when the field is supported), but the code lines end up as sunLen = strlen(sun.sun_path)+1 + sizeof(sun.sun_family); which gcc doesn't choke on. Alas, I've not gotten to testing much 1.5.1 due to my less than stellar attempts at getting the storage classes correct, complicated by compile time or link time fails.
And now, I'm asking for a little advice. Do I try and maintain a patch set exposing some of the inline definitions that end up with no entry point? Or might I ask for more direct assistance in getting clean shared libraries on GNU/Linux and perhaps a more solid binding to Agar from COBOL? Big Smiley here, maybe the puppy dog eyes if you can see them?
It's a nice toolkit, Vedge. I'm really looking forward to bragging about GnuCOBOL with Web features. There is already a demo of AG_Net as COBOL functions in the link above.
If this all works out, and it'll be some work, there will be trials of runtime checks for COBOL screen section (curses based terminal user interface) to Agar based graphical user interface, no change to the COBOL required. That's a dream, and it will take some work, so, may happen. Dreams do sometimes come true.
Have good, make well,
Brian