ОС: линукс генту 6.0.9
Я пытаюсь создать пользовательскую версию XMonad, используя Stack и написанный мной скрипт сборки, который во многом основан на вот этом.
build.sh
:
#!/bin/sh
SRC_DIR=$HOME/.config/xmonad
EXE_DIR=$HOME/.local/bin
EXE_NAME=xmonad
######################
unset STACK_YAML
cd $SRC_DIR
stack build 2>.log
ln -f -T $(stack exec -- which $EXE_NAME) $EXE_DIR/$EXE_NAME 2>.log
rm ./src/$EXE_NAME.hi ./src/$EXE_NAME.o 2>/dev/null
Приведенный выше вызов stack build
не может скомпилировать написанный мной модуль под названием Prompt.Man
(не путать с XMonad.Prompt.Man
, который я не писал), который ранее скомпилировался нормально, и я вообще не понимаю ошибку GHC; когда я пытаюсь просмотреть файл, на который ссылается ошибка (XMonad/Actions/OnScreen.dyn_hi
), это двоичный файл.
.log
:
Building executable 'xmonad-vem:xmobar'.
Other executables with the same name might be overwritten: 'xmobar:xmobar'.
Building executable 'xmonad-vem:xmonad'.
Other executables with the same name might be overwritten: 'xmonad:xmonad'.
Building all executables for `xmonad-vem' once. After a successful build of all of them, only specified executables will be rebuilt.
xmonad-vem> configure (exe)
xmonad-vem> Configuring xmonad-vem-0.3...
xmonad-vem> build (exe)
xmonad-vem> Preprocessing executable 'xmobar' for xmonad-vem-0.3..
xmonad-vem> Building executable 'xmobar' for xmonad-vem-0.3..
xmonad-vem> [9 of 9] Compiling Prompt.Man
xmonad-vem>
xmonad-vem> /home/myuser/.config/xmonad/src/Prompt/Man.hs:9:1: error:
xmonad-vem> Bad interface file: /home/myuser/.config/xmonad/.stack-work/install/x86_64-linux-tinfo6/11f8cebbee3588011a80cb3a0acfb83ab68c1e233a64bf2f944fbcae91e1b2fb/8.10.6/lib/x86_64-linux-ghc-8.10.6/xmonad-contrib-0.17.0-KtuI6PQ7yCQKkNv0hd26Wj/XMonad/Actions/OnScreen.dyn_hi
xmonad-vem> Something is amiss; requested module xmonad-contrib-0.17.0:XMonad.Actions.OnScreen differs from name found in the interface file xmonad-contrib-0.17.0-Jq55vblrWW56gRIiMssDFv:XMonad.Actions.OnScreen (if these names look the same, try again with -dppr-debug)
xmonad-vem> |
xmonad-vem> 9 | import XMonad.Actions.OnScreen (onlyOnScreen)
xmonad-vem> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- While building package xmonad-vem-0.3 (scroll up to its section to see the error) using:
/home/myuser/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_3.2.1.0_ghc-8.10.6 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-3.2.1.0 build exe:xmobar exe:xmonad --ghc-options ""
Process exited with code: ExitFailure 1
Добавление флага -dppr-debug
к ghc-opts
в package.yaml
, как это было предложено GHC, приводит к точно такому же сообщению об ошибке при попытке перестроить.
Я также пытался удалить свои каталоги .stack
и .stack-work
, а затем повторно запустить в качестве безнадежной попытки посмотреть, исправит ли это что-нибудь, но безрезультатно.
Что вызывает эту ошибку и как ее устранить?
stack.yaml
:
resolver: lts-18.7
packages:
- .
- /var/cache/distfiles/xmobar-0.44.1
- /var/cache/distfiles/xmonad-0.17.0
- /var/cache/distfiles/xmonad-contrib-0.17.0
extra-deps: []
flags:
xmobar:
with_xpm: false
with_threaded: false
with_xft: true
with_rtsopts: false
with_alsa: true
with_mpd: false
with_weather: false
with_dbus: false
with_mpris: false
with_inotify: false
with_nl80211: false
with_iwlib: false
with_datezone: false
with_uvmeter: false
with_kraken: false
arch: x86_64
/var/cache/distfiles/
здесь у меня хранятся конкретные версии исходного кода для xmonad, xmonad-contrib и xmobar.
package.yaml
:
name: xmonad-vem
version: 0.3
ghc-options: -Wall -Wcompat -Wincomplete-record-updates -Wincomplete-uni-patterns -Wredundant-constraints -O2 -j -dynamic
dependencies:
- base
- containers
- directory
- filepath
- process
- regex-tdfa
- utf8-string
- unix
- xmobar
- xmonad >= 0.17
- xmonad-contrib >= 0.17
source-dirs:
- src
executables:
xmonad:
main: xmonad.hs
dependencies:
- xmonad
- X11 >= 1.10
xmobar:
main: xmobar.hs
dependencies:
- xmobar
По запросу комментария о том, что проблема связана с глобально установленной версией xmonad-contrib-0.17.0
, я попробовал stack exec ghc-pkg unregister xmonad-contrib-0.17.0 && stack build
, который теперь компилируется, но сразу же вылетает во время выполнения со следующей ошибкой:
discover_other_daemon: 0/home/myuser/.local/bin/xmonad: error while loading shared libraries: libHSxmonad-contrib-0.17.0-Jq55vblrWW56gRIiMssDFv-ghc8.10.6.so: cannot open shared object file: No such file or directory
Я понял часть этого благодаря комментарию; Мне нужно было обновить мой stack.yaml
, чтобы он не включал локальные версии xmonad, xmonad-contrib и xmobar, и позволить Stack просто получить их для меня:
stack.yaml
:
resolver: lts-18.7
packages:
- .
extra-deps:
- xmonad-0.17.0
- xmonad-contrib-0.17.0
- xmobar-0.44.1
xmobar:
with_xpm: false
with_threaded: false
with_xft: true
with_rtsopts: false
with_alsa: true
with_mpd: false
with_weather: false
with_dbus: false
with_mpris: false
with_inotify: false
with_nl80211: false
with_iwlib: false
with_datezone: false
with_uvmeter: false
with_kraken: false
arch: x86_64
...и немного отредактируйте скрипт сборки:
build.sh
:
#!/bin/sh
SRC_DIR=$HOME/.config/xmonad
EXE_DIR=$HOME/.local/bin
EXE_NAME_XMONAD=xmonad
EXE_NAME_XMOBAR=xmobar
######################
unset STACK_YAML
cd $SRC_DIR
stack build 2>.log
ln -f -T $(stack exec -- which $EXE_NAME_XMONAD) $EXE_DIR/$EXE_NAME_XMONAD 2>.log
ln -f -T $(stack exec -- which $EXE_NAME_XMOBAR) $EXE_DIR/$EXE_NAME_XMOBAR 2>.log
rm ./src/$EXE_NAME_XMONAD.hi ./src/$EXE_NAME_XMONAD.o ./src/$EXE_NAME_XMOBAR.hi ./src/$EXE_NAME_XMOBAR.o 2>/dev/null
И я все еще получаю аналогичную ошибку времени выполнения после выполнения build.sh
и попытки запустить новые xmonad
и xmobar
из /home/myuser/.local/bin
на X-сервере:
discover_other_daemon: 0XMonad is recompiling and replacing itself with another XMonad process because the current process is called "xmonad" but the compiled configuration should be called "xmonad-x86_64-linux"
XMonad will use build script at "/home/myuser/.config/xmonad/build" to recompile.
XMonad recompiling because a custom build script is being used.
XMonad recompilation process exited with success!
/home/myuser/.cache/xmonad/xmonad-x86_64-linux: error while loading shared libraries: libHSxmonad-contrib-0.17.0-KtuI6PQ7yCQKkNv0hd26Wj-ghc8.10.6.so: cannot open shared object file: No such file or directory
Я вижу, что один из путей говорит linux
. Я подозревал проблему с нечувствительностью к регистру в MacOS. Что произойдет, если вы добавите -dppr-debug
к ghc-options
вместо xmonad-vem
, как это предлагается в сообщении об ошибке?
Странно, что задействованы два разных хеша для xmonad-contrib
: KtuI6PQ7yCQKkNv0hd26Wj
и Jq55vblrWW56gRIiMssDFv
. Хотя понятия не имею, в чем может быть причина. Я бы, наверное, сообщил об этом на github.com/commercialhaskell/stack/issues.
ОС @sjakobi — это Linux. Я отредактировал пост, чтобы включить эту информацию, а также результат попытки -dppr-debug
Что такое /var/cache/distfiles/
? Обычно стек находит пакеты из собственного преобразователя. Поскольку у вас задействованы два разных xmonad-contrib
(судя по двум разным хэшам), может ли что-то, что вы делаете, зависеть от xomand-contrib
от распознавателя, а что-то еще зависит от xmonad-contrib
, которое у вас есть в /var/cache/distfiles/
?
не могли бы вы включить файл package.yaml
?. Мне кажется, что у вас есть две разные версии xmonad-contrib-0.17.0, и stack
запутался в этом.
Кроме того, после этого ответа Возможно, вы установили xmonad-contrib
глобально, но ваш текущий проект указывает на другую локальную версию в var/cache/...
. Они предлагают отменить регистрацию глобального пакета. stack exec ghc-pkg unregister xmonad-contrib-0.17.0
а потом stack build
@lsmor действительно /var/cache/distfiles/
- это место, где установлен исходный код для определенных версий этого программного обеспечения. Более подробная информация добавлена в редактирование сообщения под названием ОБНОВЛЕНИЕ #1.
Не могли бы вы проверить, обновляется ли /home/myuser/.local/bin/xmonad
при сборке? Я не понимаю использование пользовательского сценария сборки. Когда вы создаете жесткую ссылку, что возвращает stack exec -- which $EXE_NAME_XMONAD
? Обратите внимание, что stack build
создаст исполняемый файл, видимый только stack
в папке .stack-work
(возможно, unset STACK_YAML
изменит это поведение... не знаю).
также обратите внимание, что ваш исполняемый файл называется xmonad
вместо xmonad-x86_64-linux
. Я пытаюсь найти документы об этих двух, но исполняемый файл AFAIK xmonad
является своего рода средством запуска для xmonad-x86_64-linux
, который является исполняемым файлом для вашей собственной конфигурации. Вы вынуждены использовать собственный скрипт сборки?
@lsmor Компиляция и связывание файлов работают правильно, и исполняемый файл в моей локальной корзине правильный (тот, что из корзины .stack-work
). Но полезно знать о поведении XMonad при компиляции. Вероятно, я неправильно вызываю свой скрипт сборки. Прямо сейчас я просто напрямую вызываю его через ./build.sh
. Я настрою его по-другому и попробую вместо этого вызвать $HOME/.local/bin/xmonad --recompile
. Я скоро сообщу вам о своих результатах... Мне потребовалось некоторое время, чтобы сделать это и опубликовать свои результаты здесь, потому что я делаю это без настройки сервера отображения, поскольку X/XMonad - это то, что я обычно использую для этого.
Обновление @lsmor: решено. То, что вы сказали о том, что xmonad
двоичный файл является средством запуска для xmonad-x86_64-linux
, заставило меня понять, что мой скрипт сборки должен принимать аргумент и ссылаться на него, а не на мою корзину. Добавлен ответ с дальнейшим объяснением ниже. Большое спасибо! В настоящее время я печатаю это из своего рабочего диспетчера дисплеев.
Я понял это. Вот что я должен был сделать:
Используйте следующее в качестве отправной точки для конфигурации стека.
stack.yaml
:
resolver: lts-18.7
packages:
- .
extra-deps:
- xmonad-0.17.0
- xmonad-contrib-0.17.0
- xmobar-0.44.1
xmobar:
with_xpm: false
with_threaded: false
with_xft: true
with_rtsopts: false
with_alsa: true
with_mpd: false
with_weather: false
with_dbus: false
with_mpris: false
with_inotify: false
with_nl80211: false
with_iwlib: false
with_datezone: false
with_uvmeter: false
with_kraken: false
arch: x86_64
package.yaml
:
name: xmonad-vem
version: 0.3
ghc-options: -Wall -Wcompat -Wincomplete-record-updates -Wincomplete-uni-patterns -Wredundant-constraints -O2 -j -dynamic
dependencies:
- base
- containers
- directory
- filepath
- process
- regex-tdfa
- utf8-string
- unix
- xmobar
- xmonad >= 0.17
- xmonad-contrib >= 0.17
source-dirs:
- src
executables:
xmonad:
main: xmonad.hs
dependencies:
- xmonad
- X11 >= 1.10
xmobar:
main: xmobar.hs
dependencies:
- xmobar
Требуется, чтобы убедиться, что Stack использует в качестве зависимостей версии xmonad, xmonad-contrib и xmobar, которые я хочу использовать в качестве отправной точки, как указано в зависимостях в package.yaml
; в отличие от попыток использовать глобально установленные версии, которые у меня есть на моей машине.
Обновите мой скрипт build
следующим образом:
#!/bin/sh
SRC_DIR=$HOME/.config/xmonad
EXE_NAME=xmonad
unset STACK_YAML
FAIL=0
cd $SRC_DIR
stack build 2>.log || FAIL=1
ln -f -T $(stack exec -- which $EXE_NAME) $1 2>.log || FAIL=2
rm ./src/*.hi ./src/*.o 2>/dev/null
exit $FAIL
то вызов xmonad --recompile && startx
работает так, как должен.
Процесс перекомпиляции для XMonad делает больше, чем мой скрипт сборки. В моем случае я просто связывал скомпилированные бинарные файлы xmonad
и xmobar
непосредственно с моей локальной корзиной и выходил, а затем вызывал ./build
в командной строке для перекомпиляции xmonad; однако вызов скрипта сборки через xmonad --recompile
фактически передает аргумент ./build
и должен связать с ним двоичные файлы.
Спасибо @lsmor за указание на это.
Рад, что вы нашли решение!. Когда вы сказали, что запускаете скрипт вручную, я заподозрил, что это неправильно, ха-ха. Если вы посмотрите на исходный код , xmonad --recompile
запустится скрипт build
, передав двоичный путь (ваш личный двоичный файл конфигурации) в качестве аргумента скрипту. Он не делает ничего другого.
Кстати, видимо xmonad
ищет скрипт под названием build
не build.sh
но видимо я что-то упускаю так как он у вас работает
@lsmor О да, я поставил build.sh
просто чтобы уточнить тип сценария в посте. Я исправил это в ответе сейчас
Какая у вас операционная система?