Сбой XMonad: как сделать правильную сборку со стеком и пользовательским скриптом сборки?

ОС: линукс генту 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

ОБНОВЛЕНИЕ №1

По запросу комментария о том, что проблема связана с глобально установленной версией 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

ОБНОВЛЕНИЕ №2

Я понял часть этого благодаря комментарию; Мне нужно было обновить мой 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

Какая у вас операционная система?

sjakobi 21.11.2022 21:07

Я вижу, что один из путей говорит linux. Я подозревал проблему с нечувствительностью к регистру в MacOS. Что произойдет, если вы добавите -dppr-debug к ghc-options вместо xmonad-vem, как это предлагается в сообщении об ошибке?

sjakobi 21.11.2022 21:10

Странно, что задействованы два разных хеша для xmonad-contrib: KtuI6PQ7yCQKkNv0hd26Wj и Jq55vblrWW56gRIiMssDFv. Хотя понятия не имею, в чем может быть причина. Я бы, наверное, сообщил об этом на github.com/commercialhaskell/stack/issues.

sjakobi 21.11.2022 21:17

ОС @sjakobi — это Linux. Я отредактировал пост, чтобы включить эту информацию, а также результат попытки -dppr-debug

Oh Fiveight 22.11.2022 05:18

Что такое /var/cache/distfiles/? Обычно стек находит пакеты из собственного преобразователя. Поскольку у вас задействованы два разных xmonad-contrib (судя по двум разным хэшам), может ли что-то, что вы делаете, зависеть от xomand-contrib от распознавателя, а что-то еще зависит от xmonad-contrib, которое у вас есть в /var/cache/distfiles/?

Ben 22.11.2022 07:36

не могли бы вы включить файл package.yaml?. Мне кажется, что у вас есть две разные версии xmonad-contrib-0.17.0, и stack запутался в этом.

lsmor 22.11.2022 11:34

Кроме того, после этого ответа Возможно, вы установили xmonad-contrib глобально, но ваш текущий проект указывает на другую локальную версию в var/cache/.... Они предлагают отменить регистрацию глобального пакета. stack exec ghc-pkg unregister xmonad-contrib-0.17.0 а потом stack build

lsmor 22.11.2022 11:39

@lsmor действительно /var/cache/distfiles/ - это место, где установлен исходный код для определенных версий этого программного обеспечения. Более подробная информация добавлена ​​в редактирование сообщения под названием ОБНОВЛЕНИЕ #1.

Oh Fiveight 22.11.2022 17:29

Не могли бы вы проверить, обновляется ли /home/myuser/.local/bin/xmonad при сборке? Я не понимаю использование пользовательского сценария сборки. Когда вы создаете жесткую ссылку, что возвращает stack exec -- which $EXE_NAME_XMONAD? Обратите внимание, что stack build создаст исполняемый файл, видимый только stack в папке .stack-work (возможно, unset STACK_YAML изменит это поведение... не знаю).

lsmor 23.11.2022 09:19

также обратите внимание, что ваш исполняемый файл называется xmonad вместо xmonad-x86_64-linux. Я пытаюсь найти документы об этих двух, но исполняемый файл AFAIK xmonad является своего рода средством запуска для xmonad-x86_64-linux, который является исполняемым файлом для вашей собственной конфигурации. Вы вынуждены использовать собственный скрипт сборки?

lsmor 23.11.2022 11:01

@lsmor Компиляция и связывание файлов работают правильно, и исполняемый файл в моей локальной корзине правильный (тот, что из корзины .stack-work). Но полезно знать о поведении XMonad при компиляции. Вероятно, я неправильно вызываю свой скрипт сборки. Прямо сейчас я просто напрямую вызываю его через ./build.sh. Я настрою его по-другому и попробую вместо этого вызвать $HOME/.local/bin/xmonad --recompile. Я скоро сообщу вам о своих результатах... Мне потребовалось некоторое время, чтобы сделать это и опубликовать свои результаты здесь, потому что я делаю это без настройки сервера отображения, поскольку X/XMonad - это то, что я обычно использую для этого.

Oh Fiveight 23.11.2022 14:10

Обновление @lsmor: решено. То, что вы сказали о том, что xmonad двоичный файл является средством запуска для xmonad-x86_64-linux, заставило меня понять, что мой скрипт сборки должен принимать аргумент и ссылаться на него, а не на мою корзину. Добавлен ответ с дальнейшим объяснением ниже. Большое спасибо! В настоящее время я печатаю это из своего рабочего диспетчера дисплеев.

Oh Fiveight 23.11.2022 14:51
Шаблоны Angular PrimeNg
Шаблоны Angular PrimeNg
Как привнести проверку типов в наши шаблоны Angular, использующие компоненты библиотеки PrimeNg, и настроить их отображение с помощью встроенной...
Создайте ползком, похожим на звездные войны, с помощью CSS и Javascript
Создайте ползком, похожим на звездные войны, с помощью CSS и Javascript
Если вы веб-разработчик (или хотите им стать), то вы наверняка гик и вам нравятся "Звездные войны". А как бы вы хотели, чтобы фоном для вашего...
Документирование API с помощью Swagger на Springboot
Документирование API с помощью Swagger на Springboot
В предыдущей статье мы уже узнали, как создать Rest API с помощью Springboot и MySql .
Начала с розового дизайна
Начала с розового дизайна
Pink Design - это система дизайна Appwrite с открытым исходным кодом для создания последовательных и многократно используемых пользовательских...
Шлюз в PHP
Шлюз в PHP
API-шлюз (AG) - это сервер, который действует как единая точка входа для набора микросервисов.
14 Задание: Типы данных и структуры данных Python для DevOps
14 Задание: Типы данных и структуры данных Python для DevOps
проверить тип данных используемой переменной, мы можем просто написать: your_variable=100
4
12
267
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Я понял это. Вот что я должен был сделать:

#1

Используйте следующее в качестве отправной точки для конфигурации стека.

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; в отличие от попыток использовать глобально установленные версии, которые у меня есть на моей машине.

#2

Обновите мой скрипт 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, передав двоичный путь (ваш личный двоичный файл конфигурации) в качестве аргумента скрипту. Он не делает ничего другого.

lsmor 23.11.2022 15:07

Кстати, видимо xmonad ищет скрипт под названием build не build.sh но видимо я что-то упускаю так как он у вас работает

lsmor 23.11.2022 15:08

@lsmor О да, я поставил build.sh просто чтобы уточнить тип сценария в посте. Я исправил это в ответе сейчас

Oh Fiveight 23.11.2022 21:26

Другие вопросы по теме