using gdl for ssw

[alenbrk]

Hello,
I have just found out that, perhaps, gdl can be used as idl. I have used idl, but have no access to the license anymore. Is it possible to use programs written in idl, using gdl?
Regards,
Alen

[alaingdl]

Welcome ! This is the goal ! Few papers detailed that
And yes, large codes and pipelines written in IDL work fine with GDL. (sometime some adjustments need to be done, bottlenecks are found, numerical problems in the code are found, and also bugs in the code itself !)

[alenbrk]

Thank you very much for the answer! it's too good to be true!:-)

ssw can also be downloaded with gdl, or one has to have it already?

[alaingdl]

the bad news : SSW is a complex & huge collection of software, some parts have been already tested, but I cannot say everything will be perfect. You can look in the issues, some tests have been done. We try to answer as quick as possible when problem arise.

First step is to install GDL and test on basic tasks on your computer ...

[alenbrk]

Thank you! I have installed it, but after typing gdl:
gdl: error while loading shared libraries: libtiff.so.6: cannot open shared object file: No such file or directory

It seems that something is missing. I use Linux Open Suse version 15.6

[alaingdl]

From my point of view, today, the bast solution is to run the script : https://github.com/gnudatalanguage/gdl/blob/master/scripts/build_gdl.sh

first step will help to add missing dependancies

[alenbrk]

I have downloaded files:
gdl-language-1.1-bp156.1.2.x86_64.rpm and
gdl-language.ymp
Then I did as su:
zypper addrepo https://download.opensuse.org/repositories/science/15.6/science.repo
zypper refresh
zypper install gdl-language

Now I have the build_gdl.sh script.
How do I run it and from which directory? As su, I guess?

[alenbrk]

I run the script:
sh build_gdl.sh prep
but it again says:
Resolving package dependencies...
6 Problems:
Problem: nothing provides 'libc.so.6(GLIBC_2.34)(64bit)' needed by the to be installed qhull-2020.2-bp156.29.1.x86_64
Problem: nothing provides 'libc.so.6(GLIBC_2.34)(64bit)' needed by the to be installed udunits2-2.2.28-bp156.10.2.x86_64
Problem: nothing provides 'libc.so.6(GLIBC_2.38)(64bit)' needed by the to be installed libnetcdf19-4.9.2-bp156.159.7.x86_64
Problem: nothing provides 'libc.so.6(GLIBC_2.38)(64bit)' needed by the to be installed libhdf5_hl200-1.12.3-bp156.217.27.x86_64
Problem: nothing provides 'libtiff.so.6()(64bit)' needed by the to be installed libgeotiff5-1.7.3-bp156.39.4.x86_64
Problem: nothing provides 'libc.so.6(GLIBC_2.38)(64bit)' needed by the to be installed eccodes-2.36.0-bp156.1.3.x86_64

How do I get the libc.so.6 and where ti install it?

[GillesDuvert]

@alenbrk I was in contact with a author of ssw, and then a few users. looking for "ssw" or "hessi" in the closed issues and conversations of GDL may help you.
At the moment, AFAIK, to run ssw (or more exactly the HESSI instrument pipeline) one must (on linux) switch to tcsh, and call 'gdl' instead of 'idl' in the start script.

[alenbrk]

Thank you Gilles! I use tcsh, but still has to install gdl!

[GillesDuvert]

@alenbrk please follow the install instructions for GDL in the wiki --- it is probably best to compile from scratch gdl, first by git-cloning this location, and then apply the build_gdl.sh script as described in the wiki (this to get the most recent gdl available)
We'll discuss how to activate ssw afterwards.

[alenbrk]

I did this:
zypper install glibc-2.34-611.13.x86_64
The result was:

Loading repository data...
Warning: Repository 'Update repository of openSUSE Backports' metadata expired since 2024-09-23 11:47:52 CEST.
Warning: Repository 'Update Repository (Non-Oss)' metadata expired since 2024-04-30 13:05:04 CEST.

Warning: Repository metadata expired: Check if 'autorefresh' is turned on (zypper lr), otherwise
manually refresh the repository (zypper ref). If this does not solve the issue, it could be that
you are using a broken mirror or the server has actually discontinued to support the repository.

Reading installed packages...
Package 'glibc-2.34-611.13.x86_64' not found.
Resolving package dependencies...
Nothing to do.
Can I download it?

[alenbrk]

Should I download something from this from the https://software.opensuse.org/package/glibc?

openSUSE Leap 15.6

openSUSE Leap 15.5

openSUSE Factory RISCV

openSUSE Backports for SLE 15 SP4

openSUSE Backports for SLE 15 SP3

SUSE SLE-15-SP2

[GillesDuvert]

I know next to nothing to Suse and zypper... I would have bet that, according to its reputation, SUSE would have all these petty things already installed... I suggest you check on internet if somebody has the same problem of said absence of glibc (same openSUSE version of course)

[GillesDuvert]

I would try to call for a less typed command like "zypper install glibc-devel" as the version number changes constantly in the repositories...

[alenbrk]

Thank you Gilles! I tried with glibc-devel, but:

Reading installed packages...
'glibc-devel' is already installed.
No update candidate for 'glibc-devel-2.31-150300.63.1.x86_64'. The highest available version is already installed.
I have to search more on the internet.

[alaingdl]

I think the answer is here to add properly libc.so.6
https://forums.opensuse.org/t/everything-asks-glibc-nothing-provides-the-dependencies-in-the-repository/172582/10

[alenbrk]

Thank you Alain! I downloaded it, but it seems to be version 2.31, and I have error saying that it needs
for some cases version 2.34 and for others 2.38.

[alaingdl]

I don't know at all the OpenSuse universe, but it is quite strange that, as long as you did clean update of the system, it is not happy with the libs you have. In the thread I read their is commands to rebuild the base, or somethings like that ...

what did you have from zypper if libc ?

I have to say that, on OSX + Brew, I created myself symbolic links to solve unclear problems related to Brew. But for libc, hum, dangerous !

[alenbrk]

Thank you Alain. The result of zypper if libc:

DESKTOP-9MM7RPI:/home/alen/gdl/scripts # zypper if libc
Loading repository data...
Warning: Repository 'Update repository of openSUSE Backports' metadata expired since 2024-09-23 11:47:52 CEST.
Warning: Repository 'Update Repository (Non-Oss)' metadata expired since 2024-04-30 13:05:04 CEST.

Warning: Repository metadata expired: Check if 'autorefresh' is turned on (zypper lr), otherwise
manually refresh the repository (zypper ref). If this does not solve the issue, it could be that
you are using a broken mirror or the server has actually discontinued to support the repository.

Reading installed packages...

package 'libc' not found.

[alenbrk]

Then I did: zypper install glibc-32b
The result was:

The following 53 NEW packages are going to be installed:
glibc-32bit krb5-32bit libacl1-32bit libattr1-32bit libaudit1-32bit libavahi-client3-32bit
libavahi-common3-32bit libcap2-32bit libcom_err2-32bit libcrack2-32bit libcrypt1-32bit libcups2-32bit
libdbus-1-3-32bit libffi7-32bit libgcrypt20-32bit libgmp10-32bit libgnutls30-32bit libgpg-error0-32bit
libhogweed6-32bit libidn2-0-32bit libjansson4-32bit libjitterentropy3-32bit libkeyutils1-32bit
libldap-2_4-2-32bit libldb2-32bit liblz4-1-32bit liblzma5-32bit libnettle8-32bit libnscd1-32bit
libnsl2-32bit libopenssl1_1-32bit libp11-kit0-32bit libpcre1-32bit libpopt0-32bit libpwquality1-32bit
libsasl2-3-32bit libselinux1-32bit libsystemd0-32bit libtalloc2-32bit libtasn1-6-32bit libtdb1-32bit
libtevent0-32bit libtirpc3-32bit libunistring2-32bit libverto1-32bit libz1-32bit libzstd1-32bit
nss-mdns-32bit pam-32bit pam_pwquality-32bit samba-client-32bit samba-client-libs-32bit systemd-32bit

53 new packages to install.
It retrieved them all, but after testing with: zypper if libc it says again: package 'libc' not found.

It seems that it is hidden somewhere. This issue needs a Suse expert.

[GillesDuvert]

Glibc-32 is the 32 bit version. I'm sure you do not need it.

[jaymurthy]

I have been using IDL since 1980 and have replaced it with GDL for the last 10 years(?). Almost always, they run seamlessly and the few errors are fixed promptly by Alain and Gilles.Jayant On Friday, January 31, 2025 at 04:26:26 PM GMT+5:30, alenbrk ***@***.***> wrote: Hello, I have just found out that, perhaps, gdl can be used as idl. I have used idl, but have no access to the license anyymore. Is it possible to use programs written in idl, using gdl? Regards, Alen — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[alenbrk]

Yes. I actually need not just idl, but ssw idl. But, before that, I have to have gdl working.

[GillesDuvert]

going back to the initial report, first time you used build_gdl.sh, above, the messages imply that build_gdl.sh wanted to install packages netcdf, eccodes, qhull ...
but
it is written in build_gdl.sh that, in case the OS is SUSE, these packages will not be installed. (they can still be installed afterwards manually if needed).
So it is as if the build_gdl.sh script did not detect your system as suse.
the detection of suse in the script is just testing the result of "grep -i opensuse /etc/*-release 2> /dev/null" which should not be void.
can you report what the above command produces?

[alenbrk]

Thank you Gilles!

The command gave:

DESKTOP-9MM7RPI:/home/alen # grep -i opensuse /etc/*-release 2> /dev/null
NAME="openSUSE Leap"
ID="opensuse-leap"
ID_LIKE="suse opensuse"
PRETTY_NAME="openSUSE Leap 15.4"
CPE_NAME="cpe:/o:opensuse:leap:15.4"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap"

On the other hand, there is the file libc.so.6 in the /lib64 directory.

DESKTOP-9MM7RPI:/lib64 # ls -al libc.so.6
lrwxrwxrwx 1 root root 12 Oct 5 2023 libc.so.6 -> libc-2.31.so
DESKTOP-9MM7RPI:/lib64 # ls -al libc-2.31.so
-rwxr-xr-x 1 root root 2300456 Oct 5 2023 libc-2.31.so

I guess the 2.31 stands for the version.

[GillesDuvert]

In that case build_gdl.sh should not have tried to install the problematic packages.

[GillesDuvert]

I've set up an opensuse 15.6 virtual machine (from osboxes.org) and tried compiling gdl from scratch using build_gdl.sh

• zypper install git
• git clone --recursive https://github.com/gnudatalanguage/
• gdl/build_gdl.sh prep

provided you are sudo, all OK.

but: build_gdl.sh does not install CMAKE (a bug) so:

• zypper install cmake

Then it would almost be OK, except that gdl/src/build_gdl.sh configure does not find some installed pakages and stops. I'm working on it (build_gdl.sh is rarely used for linux, its use is more for windows or macosx).

You could reproduce this, and, waiting for a better build_gdl.sh, go into gdl/build and repetitively type "cmake .." and try to either install the missing feature it reports, or exclude that feature, for example if qhull is not found, add "-DQHULL=OFF" to the cmake command and retry.
Once the cmake command passes OK, just type 'make -j N' where N is the number of threads on your machine, and 'make install' and it should be ready.

[alenbrk]

Thank you Gilles!

First, I have opensuse 15.4, not 15.6. Perhaps, it is the problem?
Then, I did as you suggested. It installed git (zypper install git), but the second line gave this:
DESKTOP-9MM7RPI:/home/alen # git clone --recursive https://github.com/gnudatalanguage/
Cloning into 'gnudatalanguage'...
remote: Not Found
fatal: repository 'https://github.com/gnudatalanguage/' not found
DESKTOP-9MM7RPI:/home/alen #

Also, regarding cmake:
DESKTOP-9MM7RPI:/home/alen/gdl/scripts # zypper install cmake
Loading repository data...
Warning: Repository 'Update repository of openSUSE Backports' metadata expired since 2024-09-23 11:47:52 CEST.
Warning: Repository 'Update Repository (Non-Oss)' metadata expired since 2024-04-30 13:05:04 CEST.

Warning: Repository metadata expired: Check if 'autorefresh' is turned on (zypper lr), otherwise
manually refresh the repository (zypper ref). If this does not solve the issue, it could be that
you are using a broken mirror or the server has actually discontinued to support the repository.

Reading installed packages...
'cmake' is already installed.
No update candidate for 'cmake-3.20.4-150400.4.3.1.x86_64'. The highest available version is already installed.
Resolving package dependencies...
Nothing to do.

[GillesDuvert]

sorry, it was git clone --recursive https://github.com/gnudatalanguage/gdl
a bad copy/paste my mouse is not working well.
and, you have cmake installed.

[alenbrk]

It gives as before, but I do not understand the part:

"You could reproduce this, and, waiting for a better build_gdl.sh, go into gdl/build and repetitively type "cmake .." and try to either install the missing feature it reports, or exclude that feature, for example if qhull is not found, add "-DQHULL=OFF" to the cmake command and retry."

I opened buidl_gdl.sh, but the rest do not know. Where to add "-DQHULL=OFF" or how to install the missing feature?

[GillesDuvert]

@alenbrk
I succeded in building the current version of gdl (development) as said above.

• do build-gdl.sh prep : I got no errors, BUT:
• you have to additionnaly install qhull_devel and qhullcpp-devel-static:
  sudo zypper install qhull-devel
sudo zypper install qhullcpp-devel-static

and now you must call
WITH_PYTHON=OFF gdl/scripts/build_gdl.sh configure
instead of just gdl/scripts/build_gdl.sh configure

after that, follow the rest of the procedure decribed in the wiki (build + install)

[GillesDuvert]

Also, starting from a fresh 15.6, adding repo https://download.opensuse.org/repositories/science/15.6 in Yast, one can install gdl 1.1 without problem.

[GillesDuvert]

so you may have a broken configuration between 2 different distros of suse.

[alenbrk]

Thank you Gilles!

It seems that I have to install 15.6, because it is all the same. I managed to install qhull-devel, but after
sh build-gdl.sh prep, I receive the same errors as before.

[alenbrk]

I do not know what you have changed, but it seems to me that gld/scripts/build.sh file is the same as before.

[GillesDuvert]

No, I did not (yet) change build_gdl.sh indeed. More tests should be done before allowing that.

[GillesDuvert]

building an up to date gdl from the git repo will be important if we have to interactively patch gdl in case some parts of ssw do not work with gdl.

[GillesDuvert]

Assuming you start with a fresh 15.6, in retrospect it would be a good idea to start with installing gdl-language 1.1 using the 'science' repo.
(This provides most of the needed libraries that 'build-gdl.sh prep' may have problems to find on its own.)
At that stage, you'll have a reasonably good gdl you can start using for ssw. My ssw experience is that you'll need to change a couple of ssw configuration files. Please open an issue on github when you'll be faced with that.

If gdl fails to run some ssw procedure, we should be able to patch it. just open a specific issue (not a "discussion").

To use the patched gdl, you'll need to compile the github gdl, that's where using build_gdl.sh will be necessary. At the time you'll do that, chances are that the build_gdl.sh has been patched too and there will be no errors.

[alenbrk]

Thank you for all informations Gilles!

I am going to upgrade opensuse and when the new build_gdl is ready I can try to install it.
Will it automatically install gdl-language 1.1, or I will have to apply new method?

[GillesDuvert]

At the moment I suggest you start with the suse Yast installer, add the 'science' repo and install their gdl-language that provides gdl 1.1. And not use any build_gdl.sh script yet.

[alenbrk]

I tried, but when I go into Online Update it says:

These products have reached their end of general support
and thus do not provide new updates anymore.

In case that your subscription contains extended support,
please make sure that you have activated the extension.

Contact us if you need further assistance.
openSUSE Leap 15.4

I guess I have to erase the 15.4 and install 15.6. I'll need some time for that!:-)

[alenbrk]

I used zypper instead of Yast and installed, first 15.5, and later 15.6. I am not sure if the gdl-language is installed, because when I launch Yast and go to Software and then in Software Management I find gdl-language and gdl-language-common. I click Accept it, but then the small window disappeared?! Where should I look for gdl-language?

[GillesDuvert]

@alenbrk I cannot reproduce your problem, as I have described above "starting from a fresh 15.6, adding repo https://download.opensuse.org/repositories/science/15.6 in Yast, one can install gdl 1.1 without problem." I found the Yast interface quite intuitive.

[alenbrk]

Next week I should have a fresh 15.6 version installed and will know the result.

[alenbrk]

This morning I received a message about updates of gdl-language. After the update (U did not install a complete new 15.6 version) I have gdl working. I am trying to run my scripts written in IDL. It seems gdl can not find all routines (e.g. doc_library, loadct,...). These I have from the time I tried to install gdl using build_gdl.sh and when I added that directory in the path it found them. Also, if the routine plots in X-window, there are colors, but if it prints in a ps file, colors are missing?

[GillesDuvert]

The loadct procedure not being known at gdl start means that your install is incorrect or not complete.
If you used build_gdl.sh, did you do "build_gdl.sh install" and checked there was no error? Or, you may have an IDL_STARTUP file that redefines the !PATH.
At start, gdl says what it is looking for the PATH, if as for me there is no redefinition of !PATH in a startup file, you should get:
Default library routine search path used (GDL_PATH/IDL_PATH env. var. not set): /usr/local/bin/../share/gnudatalanguage/lib
Assumed you asked for a 'color' ps device, not having colors is a bug. Until this is cured, you could use the SVG device that behaves as the X window, and if needed a tool like inkscape to create a ps file.

[alenbrk]

Thank you for the answer Gilles!

No, build_gdl.sh did not manage to install it with build_gdl.sh. Instead, last week I upgraded opensuse from 15.4 to 15.6 and, it didn't download gnudatalanguage. Today, I received a message about updates and it was the gnudatalanguage. Now, it finds procedures. I had to add in the path both the location of gdl, as well as add paths of the directories where I have my scripts. Regarding, colors, I have to adjust, because producing an SVG file and converting it to the pdf is not the same as producing a ps file and converting it to the pdf. I can say that I have gdl working. Now, I have to try to install ssw with gdl.

[GillesDuvert]

@alenbrk OK, excellent. May I suggest to close this discussion and open issues each time you get a problem with ssw?
I've made tests with ssw, running the hessi instrument (using its graphical interface with ssw's plotman behind the scenes) seems OK (I did not go far)
natively the ssw shell scripts ignore the existence of gdl (they should!!) but I found that starting hessi was just:

$ tcsh
[gildas@localhost ~]$ gdl
GDL> path_add,"$SSW",/rec
GDL> @ ssw/site/setup/IDL_STARTUP
GDL> hessi

provided ssw is correctly installed.

[alenbrk]

Yes, this discussion can be closed. Thank you and Alain for all the help!
I will open a new discussion regarding the ssw. I managed to start sswgdl,
but there were errors afterwards,...