Cannot start omnetpp on linux

[comejv]

Hello,
I've installed VEINS through opp_env, but when starting it with omnetpp I got :

An error has occurred. See the log file
/home/comev/x/net/project/omnetpp-5.7.1/ide/configuration/1736606902224.log.

In which we can read :

java.lang.UnsatisfiedLinkError: Could not load SWT library. Reasons:
        no swt-pi4-gtk-4958r2 in java.library.path: /nix/store/c26i7fk96p0h496y7qmhrx7vi27mwsl4-mesa-24.3.2-drivers/lib:/nix/store/qw8xdx53jf0pxc7$
        no swt-pi4-gtk in java.library.path: /nix/store/c26i7fk96p0h496y7qmhrx7vi27mwsl4-mesa-24.3.2-drivers/lib:/nix/store/qw8xdx53jf0pxc73zydqgs$
        no swt-pi4 in java.library.path: /nix/store/c26i7fk96p0h496y7qmhrx7vi27mwsl4-mesa-24.3.2-drivers/lib:/nix/store/qw8xdx53jf0pxc73zydqgsknc1$
        Can't load library: /home/comev/.swt/lib/linux/x86_64/libswt-pi4-gtk-4958r2.so
        Can't load library: /home/comev/.swt/lib/linux/x86_64/libswt-pi4-gtk.so
        Can't load library: /home/comev/.swt/lib/linux/x86_64/libswt-pi4.so

I tried solving it by adding swt to my home-manager config, did not work because I end up with liswt-pi3.so. Then I downloaded swt-4.35M1-gtk-linux-x86_64.zip which had a .jar that I unpacked and found a libswt-pi4.so inside. So I put that one in my ~/.swt/lib/linux/x86_64/. But then omnetpp would still not launch because apparently I'm missing the right version of glibc.

Did I miss something during the installation ? All of that tinkering does not seem like it should happen had the nix installation gone through properly...

Thanks for the help.

[rhornig]

The 'missing libswt-pi4.so' is actually misleading. Normally the IDE should actally load libswt-pi3.so' i.e. it should actually use the GTK3 version of the SWT library. It seems that for some reason it cannot read that and it silently gives up on loading it and the tries to fall back to the GTK4 version which is also missing and then it complains about that. Still the original problem is that the GTK3 version is failing for some reason.

What opsystem you are on? Is it possibly Nix OS?

[comejv]

I see ! I'm on debian 12, however I do use home-manager and nix for most of my packages. Do I need to add any specific package from nix ?
I should also mention that I ran opp_env from a nix-shell with (among other packages) virtualenv.

[rhornig]

In theory, opp_env should install a self contained development shell, so you should not require anything additional. In practice, it seems certain dependencies are pulled from the host environemnt and in this particular case this causes some incompatibility. We did not test opp_env inside a nix-shell (but we should). Can you possibly say what packages were installed in the nix-shell from which opp_env were used? I need to reproduce this locally as catching these implicit references are hard.

[comejv]

Sure, here is the shell (although I have to say it is an impure shell) :

{
  pkgs ? import <nixpkgs> { },
}:
let
  custom-tex = pkgs.texlive.combine {
    inherit (pkgs.texlive)
      scheme-small
      siunitx
      fvextra
      pythontex
      xstring
      pgfopts
      currfile
      ;
  };
in
pkgs.mkShell {
  buildInputs = with pkgs; [
    # TeX distribution
    custom-tex

    # Build tools
    texlivePackages.latexmk

    # Language server for LaTeX
    texlab
    tex-fmt

    # Scientific environment
    python312Packages.sympy

    # Project
    zotero
    virtualenv
    sumo
  ];
}

[comejv]

I think I found the culprit : when running Kitty terminal with NixGL, all new programs started from it will use nixGL.
This is a known issue. It does this through setting LD_LIBRARY_PATH, LIBGL_DRIVERS_PATH and LIBVA_DRIVERS_PATH. I have not yet found a solution, but I may try to run opp_env after having unset them or switch from NixGL to Nix System Graphics some day. In the meantime I'll just use Instant VEINS.

[rhornig]

Thanks for the followup. It's good to know. In fact the pointer to Nix System Graphics is very interesting to me. I was not able to get the opp_env ecosystem working with OpenGL enabled, mainly because most of the projects required some kind of wrapping of the excusable to enable access to the host's graphics stack and this wrapping method is very unfriendly with omnetpp (as every model executable have to be wrapped, but then debugging gets complicated).

This project looks interesting as it does not seem to require wrapping. I will take a look as time allows.