[oi-dev] GDL chokes on semaphore (GraphicsMagick)

[Andreas Wacknitz]

Am 06.02.23 um 12:05 schrieb Udo Grabowski (IMK):
> On 05/02/2023 23:23, Andreas Wacknitz wrote:
>> Am 03.02.23 um 14:25 schrieb Udo Grabowski (IMK):
>>> On 28/01/2023 15:40, Bob Friesenhahn wrote:
>>>> On Fri, 27 Jan 2023, Udo Grabowski (IMK) wrote:
>>>>
>>>>> pkg:/scientific/gdl at 0.9.7-2020.0.1.4 (OI hipster illumos-aa33dce46b
>>>>> and older)
>>>>>
>>>>> for user and root:
>>>>> /usr/bin/gdl stops on assertion test in GraphicsMagick (semaphore.c):
>>>>
>>>> With almost 100% certainty this is because the dependent program has
>>>> not invoked
>>>> InitializeMagick() before using other GraphicsMagick APIs. It is
>>>> acceptable to
>>>> invoke this function any number of times and InitializeMagick(NULL)
>>>> is OK for
>>>> dynamically linked programs.
>>>>
>>>> A very long time ago (since 1.3.8 in 2010) GraphicsMagick
>>>> initialization was
>>>> changed to require InitializeMagick() to be invoked first. Before it
>>>> was just
>>>> recommended.
>>>>
>>>> OpenIndiana recently stepped forward from using a very old version of
>>>> GraphicsMagick, so that may be what provoked this issue.
>>>
>>> Indeed, the problem seems to be exactly that and has been fixed in the
>>> 1.0.2
>>> branch in 2019 with this commit:
>>>
>>> <https://github.com/gnudatalanguage/gdl/commit/d4045d4469f3c8fae435a4bc6b182ac8417b8461#diff-fee07a0c71823f10358bdf47d478390d>
>>>
>>>
>>> GNU Data Language moved from sourceforge to github:
>>> <https://github.com/gnudatalanguage/gdl>
>>>
>> I have updated several packages related to gdl and this package itself
>> today.
>> We don't seem to have many interested people in scientific use anymore.
>> I recommend that someone interested will take care for these packages in
>> the future.
>> Eg. there hasn't been a release of plplot in several years, resulting in
>> the optional dependency on an outdated qhull version (2015).
>> But there seem to be many merged commits still for plplot. Maybe they
>> need some friendly works to create a new release that supports qhull as
>> of 2020.
>> Furthermore gdl could make use of several small packages we don't have
>> yet (I have added proj because turning it off for gdl didn't work).
>> We need someone with more interest in this area than me.
>>
>
> Thanks a lot, that works now. Unfortunately, I'm neither a C or C++
> programmer, so I'm just hacking and googleing here or there until it
> works,
You only need very little C or C++ knowledge in order to maintain OI
packages.
What you need is a build environment (running latest OI and a clone of
our userland repository).
And some knowledge about the packages you maintain so you can test
updates or fixes and will
be able to discusss problems with upstream projects. As I mentioned
before plplot would benefit
from a new release, GDL would benefit if more packages would be
"migrated". Look at what I have done
for proj as an example. It had nothing to do with programming in any
language but configuring the build.
If you start programming you would be most certainly on a wrong path.

> I've just wrestled with an old GDL 0.9.8 and nearly got it just to the
> final linker step (where  it failed by some namespace issues). As a
> scientist, my daily work horses are (of course) Fortran 90, IDL
> (here as GDL) for the plotting, and Perl for hacking all the ugly
> management stuff. As Python for the younger staff seems to be important
> (and I still don't know why...), I also got a Sun Studio CC compiled
> numpy running under (old) Python, which seems to be currently missing
> (and I guess
> that the hurdles I stumbled over are still there...). So I can test stuff
> and give some hints here or there, but have no capacity to take over
> whole packages and their dependencies. As I'm currently updating all
> our stuff to current Hipster, there may will be the one or other
> package to build that can also be useful for OI. Maybe I should set up
> my own package depot for that stuff, so that integration into OI
> could be readily done from there.
If you clone the oi-userland repository and run "gmake setup" inside
you'll get your own repository.
You can always supplement this with your own pkg depot but that's not
necessary if you have file access to the repository clone.
http://docs.openindiana.org/dev/userland/ should provide you with all
the necessary information to get started.
And of course concrete questions are always welcome on our mailing lists.