new DLM functionality missing symbols from idl_export.h?

[seanm10660]

Hi, I was eager to try out the new DLM functionality in v1.2 prerelease. I've tried to get working this library that handles postgreqsl queries:
https://github.com/segasai/pg_idl

But when I try to get it to work in GDL, there is an error about undefined symbol IDL_SignalRegister
I see this defined inside idl_export.h; is there something I am doing wrong to try to get it working in GDL, or are some components like this still not fully implemented?
GDL> linkimage, 'PGSQL_QUERY', '/home/smoran/pg_idl/pgsql_query.so', 'PGSQL_QUERY', /keywords, /funct
% Type conversion error: Unable to convert given STRING: 'PGSQL_QUERY' to LONG.
% LINKIMAGE: Error linking procedure/DLL: PGSQL_QUERY -> PGSQL_QUERY (/home/smoran/pg_idl/pgsql_query.so) : Couldn't open /home/smoran/pg_idl/pgsql_query.so: /home/smoran/pg_idl/pgsql_query.so: undefined symbol: IDL_SignalRegister

Thanks!

[GillesDuvert]

syntax is LINKIMAGE, Name, Image [, Type [, Entry]] [, /DEVICE] [, /FUNCT] [, /KEYWORDS] [, MAX_ARGS=value] [, MIN_ARGS=value]

I see that you did not enter 'Type' before 'Entry' (necessary if "Entry" is given). Type is 0 for a procedure, 1 for a function.

I suggest to use the DLM "syntax", with a pgsql_query.dlm file. It makes the call to linkimage automatically.

[seanm10660]

Thank you for pointing out my syntax error there. Unfortunately, I get the same error message even with correct syntax. I only started playing with LINKIMAGE because the automatic DLM recognition did not work. There is a pgsql_query.dlm file, and its location is in IDL_DLM_PATH. This works correctly in IDL, but when I try to call the function in GDL, it is simply not found. I tried DLM_REGISTER as well, but it simply returns silently and calling PGSQL_QUERY still does not work:

GDL> DLM_REGISTER, '/home/smoran/pg_idl/pgsql_query.dlm'

GDL> test=pgsql_query('select * from table;')
% Function not found: PGSQL_QUERY

Other IDL DLM files in the normal IDL path also do not work for me, though the example 'Powell.dlm' in GDL does seem to work. Any other thoughts on what I am doing wrong?

[GillesDuvert]

@seanm10660 can you clarify, what is your OS ?

[seanm10660]

Sorry for the missing info. I'm using Ubuntu 24.04, kernel 6.8.0. When my IDL_DLM_PATH includes just the default directory, I get some of the dlms loaded on startup, but not all of those in the directory:
GDL> help, /dlm
** GMEM - IDL global shared memory library support DLM
Version: 4.1.6, Build_Date: DATE JUL 18 2025, Source: NV5 Geospatial Solutions, Inc.
Path: /usr/local/harris/idl92/bin/bin.linux.x86_64/idl_gmem.so
** GMEM - IDL global shared memory library support DLM
Version: 4.1.6, Build_Date: DATE JUL 18 2025, Source: NV5 Geospatial Solutions, Inc.
Path: /usr/local/harris/idl92/bin/bin.linux.x86_64/idl_gmem.so
** IDL_IDLBRIDGE - IDL to IDL Bridge support DLM
Version: 3.2.0, Build_Date: DATE JUL 18 2025, Source: NV5 Geospatial Solutions, Inc.
Path: /usr/local/harris/idl92/bin/bin.linux.x86_64/idl_idlbridge.so
** IDL_IDLBRIDGE - IDL to IDL Bridge support DLM
Version: 3.2.0, Build_Date: DATE JUL 18 2025, Source: NV5 Geospatial Solutions, Inc.
Path: /usr/local/harris/idl92/bin/bin.linux.x86_64/idl_idlbridge.so
** idl_svm - IDL SVM for classification support DLM
Version: libsvm 2.8.2, Build_Date: DATE JUL 18 2025, Source: NV5 Geospatial Solutions, Inc.
Path: /usr/local/harris/idl92/bin/bin.linux.x86_64/idl_svm.so

[GillesDuvert]

@seanm10660 I am sorry, I read you report too fast. Indeed, the IDL_SignalRegister function has not been (yet) programmed, so it is not possible to run this particular loadable image.
I must confess, I did not expect the first DLM to be tried with GDL would need such a function. Especially as the IDL doc about external development is (rightly) quite verbose about the difficulty of using them.
Actually adding the relevant code ( IDL_SignalRegister, IDL_SignalUnregister ) in export.cpp seems quite easy.

[seanm10660]

Ah, ok, thanks for the explanation. I found that IDL_SignalRegister was just being used in my module to handle the case of 'Ctrl-C'-ing out of the query to Postgresql server. It seems a minimal risk of error in my use case, so I commented out the relevant lines in the module's code and recompiled. However I'm now getting an error about missing IDL_VarGetString
This seems to be used to parse the input argument to make sure it is a string; I'm not sure if it is strictly necessary either.
queryVptr = argv[0];
query = IDL_VarGetString(queryVptr);

[GillesDuvert]

Ah, I missed that one, I'm afraid. I definitely need to add these functions ASAP.

[seanm10660]

Thanks for your work on this. I'm really excited to finally dump IDL and all its licensing headaches, and this seems so close!
To add one more to your list: I worked around IDL_VarGetString, got the module to compile and load, but running it leads to a segfault when calling IDL_KWProcessByOffset

[GillesDuvert]

Ah, IDL_KWProcessByOffset, that one was tough, and I'm a bit disappointed that it does not work, as it works with the IDL examples.
At least now it's clear that pg_idl is a good test. I'll try to install it and replicate your tries.

[GillesDuvert]

This is a bit hasty but see #2060 .

[GillesDuvert]

Ah, for the record: the IDL-made DLMs (in the IDL path, as you mention) cannot work at all, they all use undocumented proprietary functions. And POWELL is a 'GDL-native' DLM that uses exclusively C++ GDL code (which makes it currently not working on Windows and OSX, alas).

[GillesDuvert]

@seanm10660 tried to install pg_idl on a mageia 9, there is a complation error when building postgresql.

[seanm10660]

I finally had a chance to try this out. It looks to me like IDL_VarGetString and IDL_SignalRegister/Unregister are working (I was not able to test whether a Ctrl-C signal is passed back up to GDL, but at least nothing crashes.)
Unfortunately, IDL_KWProcessByOffset is still triggering a segfault for me.

[seanm10660]

@seanm10660 tried to install pg_idl on a mageia 9, there is a complation error when building postgresql.

For some reason we originally used a much older version of postgresql source to compile, v9.4.2, which seemed to compile ok. And I think it is ok because it just needs the library for the public API, as far as I understand, which is pretty stable between versions. Out of curiosity, I tried just now with a postgresql 14.18 tarball, and got a compile error as well.