Установка lapack: "econf failed"[РЕШЕНО]
just a guest 16 марта, 2011 - 01:37
Пробовал поставить KDE, после попытки компиляции вылетает с ошибкой некоего blackreference. Выяснил, что принадлежит он к пакету lapack. Ощибка следующая:
*eHor:sci-libs/blackreference-20070226 failed(compile phase) *econf failed
Что бы это могло быть?
»
- Для комментирования войдите или зарегистрируйтесь
Сделал весь вывод emerge
Сделал весь вывод emerge lapack в файл -- стало видно, что он писал выше:
Как-то так.
Надо же -- я буквально за несколько часов перед этим, пока KDE компилилось, случайно увидел пару раз слово Фортран, и подумал: <<Блин, надо было поставить -fortran>>. Правда не поставил -- поздно уже. Но судя по ошибке, система и без меня решила от этого избавиться.
Неужели кто-то еще использует это старье?!
Ладно собственно по теме: какой пакет для него нужно поставть? Похоже это как раз причина ошибки.
ты, эээ, ммм серьёзно
ты, эээ, ммм серьёзно думаешь, что Fortran - старье ?
P.S ржал до не возможности
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
slepnoga написал(а):ты, эээ,
Я написал что-то неправильно? Конечно я не разбираюсь в Фортране, но хорошего на данный момент я о нем знаю мало:
Дальше не дописал, но там упоминаеться о плохо обозначеных в нем управляющих структурах, и инструкциях GOTO, превращающих программу в "спагетти"(не мое, но зато точное выражение).
P.S.
Кучу времени угрохал, что бы найти конвертер из PDF в человечекий текст. Было два варианта, но один, минут на десять загрузив проц выкинул сообщение об ошибке, и почти повесил Винду, др. отконверировал, но зачем-то только английский текст. Пришлось вручную переписывать. :(
Это все так, но на нем
Это все так, но на нем написано огромное количество программ и библиотек, которые лениво или некому переписывать на С++, да программа на 77 фортране зачастую работает быстрее, чем С/С++
Цитата: да программа на 77
Насколько позволяют мне ответить мои скромные познания в этом -- быстрее С++: может быть, там очень много процессорного времени уходит на вызовы конструкторов при каждом "удобном" случае, а вот быстрее чем С: едва ли.
в фортране 77 нет
в фортране 77 нет динамической памяти и указателей, соответственно простор для оптимизации во время компиляции выше
Благодарю за пост, я наконец
Благодарю за пост, я наконец удосужился глянуть в Вики про кучу(для меня это как раз больной вопрос: учу С++. Особенно учитывая то, что делаю это по самоучителю, и задать вопрос некому).
А вот насчет указателей я бы поспорил: какая разница, sum=a+b или sum=*a+*b ? После компиляции что а, что *а превратиться в указатель( :) ) на память с неким значением.
нет, не применение тормозит
нет, не применение тормозит работу программы, а сама возможность использования указателей затрудняет оптимизацию.
Например, если указателей нет, то sum=a+b можно считать в любой момент после того, как a и b станут известны, при возможной наличии указателей практически не реально убедиться, что значения переменных не изменятся, даже не смотря на отсутствие прямых упоминаний переменных.
Все равно не пойму. Вот
Все равно не пойму. Вот требует от меня, скажем, программа площади квадрата ввода переменной "а". После чего внутри нее все начинает бурлить, кипеть, скрежетать -- происходит умножение, и по адресу "сумма" заноситься результат.
Эта прога будет абсолютно одинаково скомпилирована, независимо от использования в исходнике прямых переменных, либо указателей.
Если речь о ситуации, когда а заранее задана, и можно на стадии компиляции высчитать сумму; исключая, как если дальше полно функций, которые перед умножением могут, при определенных условиях совершить что-то с переменной "а": так в этих функциях можно использовать и указатель и прямое имя переменной, с одинаковым результатом -- компилятор ее сразу вычислять не станет.
Вот требует от меня, скажем,
теперь возьмем, для примера, совсем простенькую задачку под названием
и попробуем как нарисовать это на столь любимой тобой сишечке/крестах. Для простоты картины примем, что мат. модель у нас есть.
(/ме на этом месте уже добро ухмыляется).
Да посчитать, к примеру воздействие отраженной волны давления 3-го поядка на увеличение выбросов NO/CH двигателем.
Велакм ин реал лайф, вобщем.
П.С а фортран уже давно с ООП, если что ;)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
я вкурсе, поэтому и писал про
я вкурсе, поэтому и писал про фортран 77, т.к. почему современный фортран лучше не знаю, кроме его общей заточенности под сложные математические вычисления
Я собственно говоря,
Я собственно говоря, адресовал это топикстратеру ;)
П.С А мат вычисления там для профф математика очень простые
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
А в чем, скажи мне проблема
А в чем, скажи мне проблема подключить дополнительные библиотеки?! И будут те же самые функции, только с чуть другим названием.
вы не поняли, я не говорю про
вы не поняли, я не говорю про разницу в вычислениях простой переменной и указателя, я говорю, о том, что места где может поменяться обычная переменная - найти тривиально, а вот гарантировать что где-нибудь через указатель не за запишется что-то - не реально.
И уже не важно происходит это или нет, просто доказать неизменность нельзя, соответственно использовать этот факт при оптимизации тоже.
just a guest написал(а): Все
Это ключевая фраза!.. :) - учитесь, разбирайтесь в первоисточниках, но не домысливайте сами - смотрите что происходит на самом деле! Иначе действительно будет трудно понять.
- сам придумал?! - а ты лучше скомпиль варианты и посмотри в ассемблерные коды... и все станет ясно!
Вообще я знаю, каков будет
Вообще я знаю, каков будет ответ: программы на Фортране довольно часто появляються(ну или по-крайней мере поддерживаються), следовательно он популярный язык. И вообще -- Fortran forever!
Ну что тут можно сказать. Тех людей, кто когда-то был мастером в своем деле, знает все узкие места, возможные оптимизации, чуть ли не всю библиотеку функций, тех кто всю жизнь посвятил работе на этом языке трудно будет перегнать в другую, совершенно незнакомую среду программирования. Их просто не убедить, что С лучше. Да и не будет для них новый язык лучше.
Их тоже можно понять.
молодой человек, у вас или
молодой человек, у вас или юношеский максимализм, или сишка головного мозга - в любом случае, вы все еще мыслите как кодер; учитесь,совершенствуйтесь - и может быть когда то вы поймете, что язык это инструмент, заточенный под определнную задачу, и что задача программирования - это не задача описания данного вам алгоритма на каком либо языка ;)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Цитата: задача
Хм..? А что же?
Это задача его разработки :),
Это задача его разработки :), а задача описания - это работа для подмастерья - кодера
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Цитата: вы все еще мыслите
То же не совсем согласен. По крайней мере по опыту: когда-то начинал с бейсика, потом был паскаль. Сейчас просто настроен потом работать и учу С++ не ради кодерства, поздновато в 20 лет заниматься этим. И насколько я мог видеть все эти языки: они ничем не отличаються, кроме того, что паскаль короче бейсика, а короче паскаля С/С++(я про размер программ). Вот скажите мне для чего они могут быть заточены?
Если пишете что-то небольшое
Если пишете что-то небольшое для себя, то язык не важен. Если же есть какие-то лимиты, по времени выполнения, времени на написание, переносимости и т.д. то уже язык начинает играть роль. И это справедливо для любой деятельности - любители пользуются любыми подручными инструментами и получают удовольствие, профессионалы хотят что-то определенное.
+1 :) Уточню:
+1 :)
Уточню: любитель/дилетант выбирает тот язык, который знает, а профессионал - тот который лучше подходит под задачу. Критерии, конечно, разные играют: и специфика задачи, и корпоративные стандарты, и другие факторы могут быть...
В большинстве случаев
В большинстве случаев программистов и прилагающиеся к ним навыки выбирают для того или иного проекта, а сам программист выбирает свою область в которой хочет быть профессионалом и точит свои навыки именно в ней.
Как пример:
Если вы хотите приложение скажем на as3, к кому вы обратитесь?...
ИМХО профессионал берется за то дело в котором он профессионал.
Что то ты программистов и
Что то ты программистов и кодеров путаешь ;)
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
.
Есть люди, которые пишут "A programmer is someone who does nothing but code new features and (if you're lucky) fix bugs. They don't write specs. They don't write automated test cases. They don't help keep the automated build system up to date. They don't help customers work out tough problems. They don't help write documentation. They don't help with testing. They don't even read code. All they do is write new code." но мы не будем брать с них пример.
а эта строка - это просто подпись
Цитата: A programmer,
Кодеры в основном malware пишут ;)
Так вы мне скажите все-таки одну вещь: разве С++ не будет на уровне Фортрана, если просто подключить соответствующие библиотеки функций? ;)
.
http://shootout.alioth.debian.org/u64/performance.php?test=spectralnorm
http://shootout.alioth.debian.org/u64/performance.php?test=nbody
и так далее
а эта строка - это просто подпись
Кодер это устаревшее понятие,
Кодер это устаревшее понятие, которое сейчас используют не по назначению.
линк
P.S. офтоп уже помоему...
Н-да, вот уж действительно
Н-да, вот уж действительно разные везде значения. Как то так получилось, что "кодер -- плохой программист" я абсолютно не слышал. Зато много раз слышал/читал обозначение, что кодеры -- кто устраивают из интернета зооэкзотариум, в который без антивируса жутко выходить.
Впрочем, что-то мы действительно немного нафлудили...
gcc с юзом fortran, и да,
gcc с юзом fortran, и да, просто не ставь игрушки и прочие plot'ы
Compute:
Bosch M2.8.1 -> custom Bosch M2.8.3 clone from Russia.
Speed about 260 km,Ram 2 pers.,HDD - 70 kg,210 FLOPS ;)
Чуть исправил в заголовке
Вывод после правки use флагов ничуть не изменился: ему все так же требуется этот хлам :)
Может для него нужен отдельно какой-то пакет?
emerge newuse решил проблему.
emerge newuse решил проблему. Изменить то флаги мало )
Форумчане! Народ! Товарищи!
Форумчане! Народ! Товарищи! Сломим диктатуру Мелкомягких! Даешь Дженту в каждый дом! Поможем еще одному рекруту поставить нашу ОС! Еще чуть-чуть и сэр просто-гость будет одним из нас, Прсто-Гость -- с большой буквы!
Ну неужели никто не сталкивался с этой проблемой(нет, не гигантомания -- ошибка при компиляции)? Если это глупый вопрос, так и скажите, дайте ссылку на FAQ? Потому что для меня лично это совсем не безсмысленный вопрос.
.
У меня профиль default/linux/amd64/10.0/desktop/kde
И, вероятно, он наследует /usr/portage/profiles/default/linux/make.defaults
а там есть строка USE="${USE} fortran mudflap openmp"
То есть если кто сознательно не отламывает fortran, то у того он работает:
Поэтому на вопрос "неужели никто не сталкивался" ответ такой - нет, не сталкивались.
а эта строка - это просто подпись
Так нет, написал же: я хотел
Так нет, написал же: я хотел его "отломить". Но оставил.
В самом деле, надо будет попробовать сделать emerge kde-meta вместо base.
Удали lapack.
Удали lapack.
Не грусти, товарищ! Всё хорошо, beautiful good!
??? Зачем? Он у меня наоборот
??? Зачем? Он у меня наоборот не становиться. Лично мне никакой лапак не нужен, и я бы с радостью его не устанавливал, но мне нужно KDE, которому в свою очередь нужен этот lapack. Вот такая вот невеселая цепочка...
.
emerge wgetpaste && emerge --info | wgetpaste
and https://forums.gentoo.org/viewtopic-t-844944.html ?