Yes, you've found it because that's what I told you in #23 …
Yep! Thanks man!
]]>Uninstalling AOCC and setting the LD_LIBRARY_PATH to generic path of /usr/lib gave me the same problem of
solvespace: error while loading shared libraries: libomp.so: cannot open shared object file: No such file or directory
It seems that I could run the solvespace when the AOCC is installed because AOCC has OpenMP library in its directory. So, when the LD_LIBRARY_PATH is set to whatever AOCC is using the solvespace could fine the libomp.so. As it turns out my system did not have OpenMP installed, that's why I could not run solvespace neither on the terminal, when LD_LIBRARY_PATH is removed, nor via dmenu. After installing OpenMP on my system, it is now working fine.
Thanks guys!
]]>If you unset LD_LIBRARY_PATH does it still start from the console?
No it does not with the following error message.
solvespace: error while loading shared libraries: libomp.so: cannot open shared object file: No such file or directory
[rangke@Angke ~]$ printenv
SHELL=/bin/bash
SAM_SCR=/home/rangke/Work/models/sam/
WINDOWID=35654036
COLORTERM=truecolor
ECMWF_API_KEY=9d19efb50a18cd4dcbc173673a1dc907
GTK_IM_MODULE=ibus
I3SOCK=/run/user/1000/i3/ipc-socket.647
ECMWF_API_URL=https://api.ecmwf.int/v1
XMODIFIERS=@im=ibus
LIBVA_DRIVER_NAME=radoensi
XDG_SEAT=seat0
PWD=/home/rangke
LOGNAME=rangke
XDG_SESSION_TYPE=tty
SYSTEMD_EXEC_PID=552
XAUTHORITY=/home/rangke/.Xauthority
WINDOWPATH=1
MOTD_SHOWN=pam
HOME=/home/rangke
LANG=en_US.UTF-8
LS_COLORS=ex=35:*.c=32:*.py=32:*.f=32:*.f03=32:*.f=32:*.f90=32:*.mp3=91:*.mkv=91:*.mp4=91:*.MOV=91:*.mov=91:*.avi=91:*.jpg=93:*.JPG=93:*.JPEG=93:*.jpeg=93:*.png=93:*.PNG=93:*.gif=93:*.GIF=93:*.tex=96:*.pdf=96:*.txt=96
VTE_VERSION=6600
INVOCATION_ID=dc202c697f04485b88ee735451000cbf
XDG_SESSION_CLASS=user
TERM=xterm-256color
CPLUS_INCLUDE_PATH=:/home/rangke/tools/pkgs/aocc-compiler-3.1.0/include
USER=rangke
LIBRARY_PATH=/home/rangke/tools/pkgs/aocc-compiler-3.1.0/lib:/home/rangke/tools/pkgs/aocc-compiler-3.1.0/lib32:/usr/lib64:/usr/lib:/usr/lib32:
ECMWF_API_EMAIL=joonghyun.in@stonybrook.edu
DISPLAY=:0
SHLVL=2
MOZ_ENABLE_WAYLAND=1
QT_IM_MODULE=ibus
XDG_VTNR=1
XDG_SESSION_ID=1
MPLBACKEND=GTK3Agg
LD_LIBRARY_PATH=/home/rangke/tools/pkgs/aocc-compiler-3.1.0/ompd:/home/rangke/tools/pkgs/aocc-compiler-3.1.0/lib:/home/rangke/tools/pkgs/aocc-compiler-3.1.0/lib32:/usr/lib64:/usr/lib:/usr/lib32:
XDG_RUNTIME_DIR=/run/user/1000
JOURNAL_STREAM=8:24443
PATH=/home/rangke/tools/pkgs/aocc-compiler-3.1.0/bin:/home/rangke/hw_conf:/home/rangke/tools/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
C_INCLUDE_PATH=:/home/rangke/tools/pkgs/aocc-compiler-3.1.0/include
MAIL=/var/spool/mail/rangke
_=/usr/bin/printenv
[rangke@Angke ~]$ tr '\0' '\n' < /proc/$(pidof i3)/environ
SHELL=/bin/bash
GTK_IM_MODULE=ibus
XMODIFIERS=@im=ibus
LIBVA_DRIVER_NAME=radoensi
XDG_SEAT=seat0
PWD=/home/rangke
LOGNAME=rangke
XDG_SESSION_TYPE=tty
SYSTEMD_EXEC_PID=552
XAUTHORITY=/home/rangke/.Xauthority
WINDOWPATH=1
MOTD_SHOWN=pam
HOME=/home/rangke
LANG=en_US.UTF-8
INVOCATION_ID=dc202c697f04485b88ee735451000cbf
XDG_SESSION_CLASS=user
TERM=linux
USER=rangke
DISPLAY=:0
SHLVL=1
MOZ_ENABLE_WAYLAND=1
QT_IM_MODULE=ibus
XDG_VTNR=1
XDG_SESSION_ID=1
XDG_RUNTIME_DIR=/run/user/1000
JOURNAL_STREAM=8:24443
PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
MAIL=/var/spool/mail/rangke
printenv
tr '\0' '\n' < /proc/$(pidof i3)/environ
redshoe wrote:Trilby wrote:Please launch dmenu_run from a terminal then enter 'solvespace' (and hit enter) and report any errors or output on the terminal that launched dmenu_run.
This works lol. Wonder why it is not working with my window manager shortcut 'alt+d'. In my window manager I have the dmenu run it as
localectl locale locale -a
output
[rangke@Angke ~]$ localectl
System Locale: LANG=en_US.UTF-8
VC Keymap: n/a
X11 Layout: n/a
[rangke@Angke ~]$ locale
LANG=en_US.UTF-8
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_PAPER="en_US.UTF-8"
LC_NAME="en_US.UTF-8"
LC_ADDRESS="en_US.UTF-8"
LC_TELEPHONE="en_US.UTF-8"
LC_MEASUREMENT="en_US.UTF-8"
LC_IDENTIFICATION="en_US.UTF-8"
LC_ALL=
[rangke@Angke ~]$ locale -a
C
en_US.utf8
ko_KR.utf8
POSIX
I am not using any script of some sort. Just vanilla. And, about your script and the link you have provided, I don't know how those are related to my issues. Could you elaborate?
Not at all, though, in #6 you said
I can not see the script.
so, I though you may be curious about it that's all...
]]>Trilby wrote:Please launch dmenu_run from a terminal then enter 'solvespace' (and hit enter) and report any errors or output on the terminal that launched dmenu_run.
This works lol. Wonder why it is not working with my window manager shortcut 'alt+d'. In my window manager I have the dmenu run it as
localectl
locale
locale -a
Wonder why it is not working with my window manager shortcut 'alt+d'.
Likely a difference in environment variables. How do you start your i3 session?
]]>I wouldn't have expected it... well I have tried to run solvespace with a few different scripts, and they all excute it just fine. There is some bug in it I haven't investigated: 'SolveSpace! connect failed: No such file or directory' but besides that no problems
The fact it wouldn't run with 'Exec=/usr/bin/solvespace' on my side is because of my own 'dmenu_gui' script!
We can say there is probably something in your setup preventing you to use dmenu to start solvespace.
If use 'solvespace 0> /dev/null' it runs, though, it should also run just using 'solvespace'!Are you running a patched dmenu, if so wich one?
I sure I'm not of much help right now, but I also don't have a clear view of what is going awry!You said you couldn't see the script, if you're still curious:
I am using some patches...#!/bin/bash # shellcheck disable=1091 [ -f "$XDG_CONFIG_HOME"/dmenu/dmenurc ] && . "$XDG_CONFIG_HOME"/dmenu/dmenurc || dmnews='dmenu -i' desktoppath=("/usr/share/applications" "$HOME/.local/share/applications") dmenu_cache="$HOME/.cache/guiapps/apps" [ ! -e "$XDG_CACHE_HOME"/guiapps ] && mkdir "$XDG_CACHE_HOME"/guiapps [ ! -e "$XDG_CACHE_HOME"/guiapps/apps ] && touch "$XDG_CACHE_HOME"/guiapps/apps [ -f "$dmenu_cache" ] || stest -dqr -n "$dmenu_cache" "${desktoppath[@]}" findit() { find "${desktoppath[@]}" -name '*.desktop' -exec awk -F '[ =]' \ '/^Terminal=true/ { term=1; } /^Exec[^\/]*$/ { if (!term) cmds[$2] = 1; } END { for (key in cmds) print key; }' '{}' \; \ | sort -b | uniq > ~/.cache/guiapps/apps } findit < "$dmenu_cache" $dmnews -z 400 -x 750 -y 150 "$@" -p "GUI apps:"| ${SHELL:-"/bin/sh"}
edit: You can find the original code in the 'Dmenu Hacking Thread' (see) #322 & #323
https://bbs.archlinux.org/viewtopic.php?id=80145&p=13
I am not using any script of some sort. Just vanilla. And, about your script and the link you have provided, I don't know how those are related to my issues. Could you elaborate?
]]>You didn't see it yet, I assume...
The bindsym syntax you use for i3 config is wrong, have a look at the example: /etc/i3/config
Dang. What the hell. The config format changed alot! I've been using the old config file that mine looks nothing like the new one! But, adhering to the new config setup did not help with the dmenu issue.
]]>