LINUX.ORG.RU

ghci что то сломалось

 , ,


0

2

Мужики че за дела ?

% ghci
GHCi, version 7.4.2: http://www.haskell.org/ghc/  :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... ghc: /usr/lib64/ghc-7.4.2/base-4.5.1.0/HSbase-4.5.1.0.o: unknown symbol `stat'
ghc: unable to load package `base'
дистр - gentoo. Тащемта дома все работает, только на работе такое. И там и там 64 битная gentoo, haskell-updater сделал.

ghc компилирует нормально, не запускается только интерпретатор

Ответ на: комментарий от dmitry_malikov

Nensha, в оверлее есть свой ghci?

(ghc) быть может он и одинаковый...

в любом случае флаг binary должен спасти отца чего-то там...

Nensha ()
Ответ на: комментарий от dmitry_malikov

В любом случае 7.4.2 есть только в оверлее =)

у меня работает за счёт binary, сейчас попробую без этого флага

Nensha ()

Вам же четко ghc написал, что пакет base зафейлился. Мой вам совет: не ставьте хаскеллевые либы через гентушный пакетный менеджер и не будет таких проблем. А пока могу дать два совета по решению проблемы:

1. Перемерджите пакет base (хз, в какой гентушный пакет он у вас входит, сами разберетесья, я думаю)

2. fuck the system! Через cabal-install поставьте локальную версию base или глобально через ключ --global (чревато!)

delete83 ★★ ()
Ответ на: комментарий от delete83

Перемерджите пакет base

Находится он в пакете GHC-7.4.2 как ни странно

fuck the system!

Вообще пробовал собрать haskell-platform из сорцов в хомяк, но были ошибки компиляции, как всегда загадочные без четких сообщений что не так.

Пересборка base из cabal-install не получается, говорит что пакет уже установлен (что вполне логично), персборку GHC выполнял без результатно.

Может есть рецепт кроссдистрибутивной установки haskell-platform и GHC в хомяк ? Ну то есть даже GHC не ставить из пакетника ?

s9gf4ult ★★ ()
Ответ на: комментарий от s9gf4ult

Может есть рецепт кроссдистрибутивной установки haskell-platform и GHC в хомяк ?

Скачать бинарную сборку GHC, сделать ./configure --prefix=хомяк && make install. Потом скачать cabal-install и сделать sh bootstrap.sh, добавить $HOME/.cabal/bin в $PATH, сделать cabal update и дальше cabal install что угодно. Платформу НЕ ставить.

quasimoto ★★★★ ()
Ответ на: комментарий от delete83

Мой вам совет: не ставьте хаскеллевые либы через гентушный пакетный менеджер и будут такие проблемы

dmitry_malikov ★★ ()

У меня работает и собранный. Попробуйте собрать с флагом binary,

1. откройте bug в нужном месте

2. приложите emerge --info

и да,

fuck the system! Через cabal-install поставьте локальную версию base или глобально через ключ --global (чревато!)

http://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a...

Учить параграф: Why you should use your distribution’s package management system

Nensha ()

А ты ставь больше через дистр. Оне тебе понаставят.

Хотя действительно странно... Криво слинкировалось?

Лично я беру бинарники с офсайта и ставлю их в ~/opt/ghc (configure --prefix=$HOME/opt/ghc && make install)

Cabal по-умолчанию с опцией --user хранит пакеты в ~/.cabal

Ставлю cabal-install c опцией --user (с ним по-жизни масса мороки). После чего, добавляю ~/opt/ghc/bin и ~/.cabal/bin в PATH

Затем cabal install alex; cabal install happy

Cabal-install понимает, что пакеты писать нужно в юзерскую область.

Все отлично работает, хранится в хомяке и не засоряет систему (Ubuntu x86_64).

Macil ★★★★★ ()
Ответ на: комментарий от Macil

Гордый убунту юзер, у меня для тебя плохие новости, ты делаешь лишнюю и никому ненужную работу.

Nensha ()
Ответ на: комментарий от Nensha

Учить параграф: Why you should use your distribution’s package management system

Если человек думает, что пакетный менеджер нежен не для менеджа пакетов, то тут уже поздно что-то учить.
«Fuck the system!» же

dmitry_malikov ★★ ()
Ответ на: комментарий от Macil

Подробные описания подстилок и подпорок на пять предложений замечательно подчёркивают отличность и удобность работы.

Особенно хорошо убунта проявляет себя при новом релизе гхц
!

dmitry_malikov ★★ ()
Ответ на: комментарий от dmitry_malikov

Особенно хорошо убунта проявляет себя при новом релизе гхц

можно просто закрыть глаза и представить, что это религия

Nensha ()
Ответ на: комментарий от anonymous

А почему, собственно?

Ну, данный способ предполагает установку минимума - GHC и утилиты cabal-install (cabal-install is a package manager, but with lack of 'unmerge'), всё остальное можно доставить. Платформа это несколько другой способ - может кому-то и нужно. Она, в принципе, ставится точно так же - сначала GHC, потом тарбол платформы вместо тарбола cabal-install и уже вместе с дополнительными пакетами, которые, возможно, и не нужны (OpenGL, например, не всем нужен).

quasimoto ★★★★ ()
Ответ на: комментарий от quasimoto

Звучит так, как будто платформа не является простым множеством пакетов с фиксированными версиями.

dmitry_malikov ★★ ()
Ответ на: комментарий от quasimoto

but with lack of 'unmerge'

Но соответствующий костыль легко пишется.

quasimoto ★★★★ ()
Ответ на: комментарий от delete83

Вам же четко ghc написал, что пакет base зафейлился. Мой вам совет: не ставьте хаскеллевые либы через гентушный пакетный менеджер и не будет таких проблем.

это конечно ЛОР, но всё же убедительно попрошу не давать вредных советов. Спасибо за понимание.

qnikst ★★★★★ ()
Ответ на: комментарий от anonymous

потому, что это неполный набор либ с фиксированными версиями, которого не хватит для более-менее полноценной разработки.

qnikst ★★★★★ ()
Ответ на: комментарий от Pinkbyte

ща попробую в коробке воспроизвести и там уж разбираться будем. А то единственный живой ноут у меня с outdated версиями.

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

Научитесь сначала хаскелевые пакеты через свой portage правильно контролировать, а потом учите, что вредно, а что полезно.

delete83 ★★ ()
Ответ на: комментарий от delete83

конкретные проблемы назовёшь? пока управление пакетами через emerge удобнее _любого_ из остальных вариантов, т.к. хотябы наличием haskell-updater.

qnikst ★★★★★ ()

и да ТС, #gentoo-haskell или issue tracker оверлея это гораздо более правильное место, чтобы решить проблему, если ты в это заинтересован.

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

Я вот думаю что «правильно» это когда твой хаскелевый пакет можно всегда развернуть на любой системе (в идеале даже офтопик), по этому ставить пакеты из portage и рассчитывать, что везде будет только уютненький гентомирок - это не сурьезно. Жабы, питоны, руби, лиспы - у всех свой пакетник, который умеет ставить пакеты в хомяк, и управлять ими независимым от дистра способом. Это еще более актуально для хаскеля, у которого версия библиотеки может сильнее влиять на результат чем название лол.

Квест пройден на домашнем компе запустился leksah, кстати почему его называют устаревшим Г ? Работает прекрасно, настоящая ИДЕ для хаскеля.

Проверю на работке - отпишусь.

s9gf4ult ★★ ()
Ответ на: комментарий от s9gf4ult

есть только 1 способ правильно написать билд систему хацкельного пакета это использовать .cabal. И это совершенно никак не относится к разворачиванию пакета в системе.

Для того, чтобы не превращать систему в помойку есть два способа: 1). быть Ъ lxf-щиком, 2). использовать пакетный менеджер дистрибутива.

Что такое ebuild для haskell пакетов - это обёртка вокруг сборки кабалом, которая так же указывает зависимости так, чтобы их понимал пакетный менеджер генты. Так же возможность подправить зависимости, т.к. зачастую в пакетах на hackage они излишне жесткие, и добавить патчи, т.к. зачастую без них пакеты могут криво работать. Все эти исправления делаются сразу и по возможности отдаются в апстрим.

При этом в 95% ebuild генерируется автоматически, программой hackport.

Таким образом: при использовании пакетного менеджера ты получаешь system-wide консистентный набор пакетов, которые протестированы (минимум на собираемость вместе + тесты в пакетах).

Учитывая, что haskell пакеты используют статическую линковку + очень сильно изменчивый ABI + то что кабал сам не разруливает изменения в dependencies (что приводит к смене ABI), использование менеджера пакетов это очень логично. Т.к. ручное управление приводит к танцам с ghc-pkg --unregister и в конечном счёте часто проще удалить .cabal, чем разбираться.

P.S. можешь ещё посмотреть как сделаны g-ctan, g-cpan и т.п. для летехов, перлов, пхп идея та же.

qnikst ★★★★★ ()
Ответ на: комментарий от qnikst

ух-ты Nensha уже тоже успел в девах оказаться? о.О =)

Та для меня тоже новость... Я пока только wannabe :3

Nensha ()
Ответ на: комментарий от s9gf4ult

Я вот думаю что «правильно» это когда твой хаскелевый пакет можно всегда развернуть на любой системе

Не правильно. Если я хочу установить Leksah на win я скачаю msi или другой нормальный установщик, если я захочу установить на RedHat я буду использовать rpm, если я захочу установить на LFS я буду писать скрипты, которые заменят мне то, что делает portage.

Квест пройден на домашнем компе запустился leksah, кстати почему его называют устаревшим Г ?

Тоже иногда им пользуюсь, не знаю почему.

Nensha ()
Ответ на: комментарий от delete83

Научитесь сначала хаскелевые пакеты через свой portage правильно контролировать, а потом учите, что вредно, а что полезно.

Ну ты ведь знаешь как их «правильно» контроллировать и уже готов поделиться своими достижениями?

Nensha ()
Ответ на: комментарий от Nensha

Ну ты ведь знаешь как их «правильно» контроллировать и уже готов поделиться своими достижениями?

Да, я знаю, как правильно. У хаскеля пакеты не раскиданы по всему интернету, а хранятся в одной базе на hackage (за редкими исключениями), и есть свой пакетный менеджер. Вот и оставьте хаскель в покое. Пусть все зависимости и конфликты разруливают cabal-install и ghc-pkg.

А то получается какое-то половинчатое решение. Какие-то пакеты у вас в дереве есть, каких-то нет и начинаются танцы с бубном при установке тех пакетов, которых у вас нет в вашем portage.

В чем конкретно мои претенции к portage в отношении haskell сейчас уже не скажу, потому что бросил это дрочерство где-то год назад и обратно на генту что-то не тянет. Помню только, что долго мучился с portage и в итоге плюнул и поставил все ручками через cabal-install.

delete83 ★★ ()
Ответ на: комментарий от delete83

Эта претензия ко всем породам linux относится, кстати. Нафига пихать в свои базы пакетов хаскелевые либы, если не в состоянии заменить cabal-install и hackage?

delete83 ★★ ()
Ответ на: комментарий от delete83

У хаскеля пакеты не раскиданы по всему интернету, а хранятся в одной базе на hackage

если ты читал, что написал qnikst, то именно их-то все и используют

и есть свой пакетный менеджер

где?

Пусть все зависимости и конфликты разруливают cabal-install и ghc-pkg

ещё раз повторяю специально для вас... http://en.wikipedia.org/wiki/Package_management_system

a collection of tools to automate the process of installing, upgrading, configuring, and removing software packages from a computer.

cabal-install и ghc-pkg никак не могут отлеживать non-cabal зависмости в системе (да, если ты посмотришь в оверлей скажем, то оказывается таких зависимостей очень много) - это лишь первый шаг как вы будете загаживать свою систему, кроме того как cabal-install будет решать проблемы совместимости? поддержка stable / unstable, вся работа этих пакетов будет просто отдельно жить от системы, но вы забываете как она зависит он неё, поговори с меинтейнерами cabal-install, Common Architecture for Building Applications and Libraries is not designed to be a package manager.

Какие-то пакеты у вас в дереве есть, каких-то нет и начинаются танцы с бубном при установке тех пакетов, которых у вас нет в вашем portage

hackport merge x11-wm/xmonad - если это танцы с бубном, то мне вас просто жаль, но да действительно часто не хватает просто взять пакет из hackport, на некоторые пакеты накладываются патчи, корректируются зависимости и делается другая работа, что бы облегчить пользователям жизнь.

Помню только, что долго мучился с portage и в итоге плюнул и поставил все ручками через cabal-install.

Portage и экосистема пакетов не так сложна как кажется на первый взгляд, хотя я соглашусь, конечно, что многим просто проще работать не вникая в то как работает система, в этом случае, конечно, Gentoo не для вас.

Nensha ()
Ответ на: комментарий от Nensha

ещё раз повторяю специально для вас... http://en.wikipedia.org/wiki/Package_management_system

Какой-то убунтоид не знает, что бывают и другие пакетные менеджеры. И что?

если ты читал, что написал qnikst, то именно их-то все и используют

Спасибо, Кэп, а я и не знал...

cabal-install и ghc-pkg никак не могут отлеживать non-cabal зависмости в системе (да, если ты посмотришь в оверлей скажем, то оказывается таких зависимостей очень много) - это лишь первый шаг как вы будете загаживать свою систему, кроме того как cabal-install будет решать проблемы совместимости? поддержка stable / unstable, вся работа этих пакетов будет просто отдельно жить от системы, но вы забываете как она зависит он неё, поговори с меинтейнерами cabal-install, Common Architecture for Building Applications and Libraries is not designed to be a package manager.

Знаешь... И об этом я в курсе, но это еще не повод городить свои костыли в отдельно взятой системе. К тому же кроме cabal-install (который 'not designed to be a package manager') есть еще ghc-pkg. Он тоже не пакетный менеджер? А вместе?

С зависимостями от нехаскелевых библиотек и программ конечно сложно, но проблему эту нужно решать несколько иначе, чем пытаясь интегрировать hackage в систему. Вы, конечно, можете думать по-другому, это лишь мое мнение.

hackport merge x11-wm/xmonad - если это танцы с бубном, то мне вас просто жаль, но да действительно часто не хватает просто взять пакет из hackport, на некоторые пакеты накладываются патчи, корректируются зависимости и делается другая работа, что бы облегчить пользователям жизнь.

Про hackport не знал. Спасибо, но уже не попробую. Но все равно спасибо.

Portage и экосистема пакетов не так сложна как кажется на первый взгляд, хотя я соглашусь, конечно, что многим просто проще работать не вникая в то как работает система, в этом случае, конечно, Gentoo не для вас.

portage и экосистема действительно не так сложны, но в некоторых случаях они добавляют лишние ограничения и использовать их становится неудобно. Gentoo я бросил по другой причине в любом случае. У меня банально слабый комп, чтобы постоянно что-то компилировать. И напоследок...

хотя я соглашусь, конечно, что многим просто проще работать не вникая в то как работает система

Многим хочется работать, а не настраивать постоянно систему. С этим я соглашусь.

delete83 ★★ ()
Ответ на: комментарий от delete83

Какой-то убунтоид не знает, что бывают и другие пакетные менеджеры. И что?

facepalm, Нужно было почитать: что такое пакетный менеджер

И об этом я в курсе, но это еще не повод городить свои костыли в отдельно взятой системе.

Ещё как повод! А «костылями» я назову ваши действия по обновлению пакетов, контроль зависимостей, удаление пакетов с зависимостями, обновление базовой платформы и пр...

Вы, конечно, можете думать по-другому, это лишь мое мнение.

Звучит уже лучше, чем «не ставьте хаскеллевые либы через гентушный пакетный менеджер и не будет таких проблем»

portage и экосистема действительно не так сложны, но в некоторых случаях они добавляют лишние ограничения и использовать их становится неудобно.

Все ограничения так же просто снимаются при желании, разве нет?

У меня банально слабый комп, чтобы постоянно что-то компилировать.

Ну в это я не поверю. 1 - это обширная база бинарных пакетов 2 - это ваше «постоянно».

Многим хочется работать, а не настраивать постоянно систему. С этим я соглашусь.

Только уберите слово постоянно. Конечно, многие из нас одержимы этим, может быть даже и я (хотя для работы уж как-то нахожу время, ну когда на лоре не сижу), но другая половина спокойно работает =) Слишком как-то часто у вас «постоянно».

Nensha ()
Ответ на: комментарий от Nensha

Замените слово «постоянно» на «систематически». Уже легче?

delete83 ★★ ()
Ответ на: комментарий от delete83

Спасибо, Кэп, а я и не знал...

судя по тому, что ты писал после моего поста, ты не знаешь это и сейчас, в крайнем случае - недопонимаешь.

Знаешь... И об этом я в курсе, но это еще не повод городить свои костыли в отдельно взятой системе. К тому же кроме cabal-install (который 'not designed to be a package manager') есть еще ghc-pkg. Он тоже не пакетный менеджер? А вместе?

нет это не пакетный менеджер, это первое к нему приближение, т.к. вместе они не решают проблему конфликтных ситуаций, блокировок и восстановления после сбоев (которые в haskell либах случаются часто из-за смены ABI). Поэтому если к cabal-install и ghc-pkg добавить ещё и пользователя, то тогда ты можешь считать это пакетным менеджером.

1). ты накатал кучу больших постов, но так и не удосужился объяснить почему это костыли. Действительно, для пользователя появляется только одна новая проблема - сгенерировать ебилд хакпортом; ну на самом деле ещё подправить зависимости, из-за одной полезной политики haskell-team. Зато в замен у пользователя существует 1). единое средство управления пакетами (а не костыль под язык) 2). средство опознавания и разрешения блокировок, 3). средство восстановления системы. Разница на порядок, сравнимый уровень удобства может быть только в контролируемой помойке типа nixos, но AFIU там тоже используются свои пакеты.

Многим хочется работать, а не настраивать постоянно систему. С этим я соглашусь.

только непонятно, почему ты ругаешь средства предназначенные для этого, при этом явно не понимая как они работают, какие проблемы решают, и отказываешься называть реальные проблемы, возникающие при их использовании.

qnikst ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.