Продолжает кататься по сраному говну? Ожидаемо.

Ох, чую сколько софта перестанет собираться

а чо, там нет какой-нибудь переменной типа $LIB_64_DIR? Все хардкодят этот ужас ручками?

а чо, там нет какой-нибудь переменной типа $LIB_64_DIR? Все хардкодят этот ужас ручками?

Ога. Это не только придется кучу FindXXX в cmake патчить, но еще и все *.pc файлы, поставляемые с либами. Спрашивается нафейхуа они так сделали? Разработчиков бубунты надо за яйца вешать за такое.

Собирать на убунте? Что ты как маленький! Кушай что дают.

Разработчиков бубунты надо за яйца вешать

Fix

> нафейхуа они так сделали

оно само сделалось. Без мозга жить забавно - всё вокруг само делается ;)

Да ладно ты брось, главное - нескучные обои ж и самый свежий софт испаропки.

Все правильно, хомячки боятся длинных имен каталогов в дебрях системы.

К сожалению не я выбирал target-платформу. Я бы, естественно, выбрал rhel.

> Все правильно, хомячки боятся длинных имен каталогов в дебрях системы.

Хомячки боятся всего, чего не понимают. А поскольку не понимают они 99% окружающего мира...

У меня тут вдруг возник вопрос: Марк совсем идиот, или же это изменение как-то обосновано?

>Ох, чую сколько софта перестанет собираться

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

Кстати, а зачем бубунта это сделала?

Естественно, в исходниках пути никто не прибивает, но если либы вместо того, чтобы лежать в /usr/lib64 лежат в /usr/lib/hui, то надо совершать дополнительные телодвижения при сборке.

Пути прибиты в средствах поиска библиотек. Если средства поиска не справляются, то приходится писать портянки ./configure --libxxx1-path=... --libxxx2-path=.... и тоже самое для cmake.

а в новой бубунте

В 10.10 у меня уже есть /usr/lib/x86_64-linux-gnu/ Так что я думаю ты что-то путаешь.

ls -l /usr/lib что говорит?

>Если средства поиска не справляются, то приходится писать портянки ./configure --libxxx1-path=... --libxxx2-path=.... и тоже самое для cmake.

Вот и надо пропатчить средства поиска, чтобы они справлялись. Сделать какую-нибудь опцию, чтобы указывать, где прежде всего искать библиотеки.

Поскольку линковка а также поиск библиотек при запуске обычно осуществляются с помощью ld, а его вполне можно пропатчить или просто написать правильный ld.so.conf, то поиск библиотек путем компиляции тестовой программы, слинкованной с этими библиотеками, вообще не должен сломаться.

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

Надо сказать, что если попытаться собрать LFS и не соблюсти filesystem hierarchy standard, то явственно наблюдается, что прибитые гвоздями пути есть в гораздо большем числе программ, чем того хотелось бы.

не понял - они что, ВСЕ либы в эти 2 каталога запихали?! оО

да, и какая разница-то? под бубунту всё равно всё через ж собирается. Традиция.

FHS запрещает? Я что-то не понял повода для истерики. Сборке это не должно мешать.

А вообще стоит взглянуть на иерархию в MacOS X и расслабиться, гнутый софт там собирается в своей массе безо всяких косяков.

> ls -l /usr/lib что говорит?

~$ ls -l /usr/lib
total 468964

[тут куча файлов]

>под бубунту всё равно всё через ж собирается.

Я бы посоветовал вам измерить кривизну рук или уменьшить толщину троллинга.

Я понял о чём ты говоришь, в 10.10 всё же по-старому. Поживём-увидим чем закончится. Раньше выстрела не падай :).

Может оно и к лучшему что так разнесли.

вот, а в 11.04 никакой тучи файлов не будет, всё будет перенесено в указанные директории

Скажи спасибо что не

/usr/lib (x86)/
/usr/lib (x86-64)/

Пусть скажет спасибо что не /program_files_x86.

вот так правильно :)

/Program Files (x86)

Я чего-то не понимаю, но какой более удобный способ иметь в системе 2 набора библиотек?

/usr/lib и /usr/lib64

Это единственный способ, который позволяет ставить стандартные пакеты с библиотеками от 32х битного дистрибутива на 64х битный.

Типа такой:

/usr/lib
/usr/lib64

http://www.gobolinux.org/?page=at_a_glance

>Я бы посоветовал вам измерить кривизну рук или уменьшить толщину троллинга.

дык трудно добиться такого-же радиуса кривизны рук, как у разрабов этой вашей бубунты :-(

Я знаю про эту поделку. И, да, она не нужна. О святые угодники, там еще и литеры разного регистра в путях! Пойду валерьянки накапаю.

- This is not forwards-compatible with any future ABI changes, which would require further design work and further modification of packages to handle the addition of new paths. (Indeed, this is already a concern for the MIPS architecture, which has three distinct ABIs in use in parallel.)

- The amd64 architecture must be special-cased in the library packaging, as the only architecture that uses /usr/lib64 instead of /usr/lib. (Two pre-existing 64-bit Linux ports, Alpha and IA-64, also used /usr/lib for their 64-bit libs.) This is unnecessary added complexity.

- It does not address emulation use cases, such as qemu, which could integrate much better and more efficiently with the system if the packages for a qemu arch were co-installable.

Вот что они пишут про свой выбор.

> /Program Files (x86)

Это в семёрке так? Мда, это неизлечимо.

Это во всех 64-битных оффтопиках

или же это изменение как-то обосновано?

Обосновано. Плюясь и матерясь разработчики перестанут писать говно-код с привязкой к конкретному пути, и будут пользоваться таки какими-то внешними директивами. Вот бы Марку ещё by default в бубунте запилить запрет на запись в $HOME, и разрешить только в $XDG_CONFIG_HOME и ещё несколько мест.

Симлинки не ?

>Плюясь и матерясь разработчики перестанут писать говно-код с привязкой к конкретному пути
Сейчас есть /usr/lib /usr/lib32 /usr/lib64, которые используются в зависимости от дистрибутива и архитектуры. Так в чем же смысл этого действия тогда?

запрет на запись в $HOME, и разрешить только в $XDG_CONFIG_HOME и ещё несколько мест.

Вот с этим согласен.

$ echo  $XDG_CONFIG_HOME

это тоже какое-то «изобретение» космонавта?

А что там с иерархией?

В чем изврат логического разделения 32-битных и 64-битных либ - я невижу. Я себе слабо представляю, как пишут софт для линукс, но в winapi вполне нормальные функции есть для оперделения системных каталогов, которые большинство нормальных разработчиков и использует. Это нет в unix или как?

Вопрос не в этом, а пейсателях, которые конфиги упорно суют в $HOME, а не в $XDG_CONFIG_HOME

Нет у меня такой переменной окружения. Дистрибутив Fedora 14.

Ага, «изобретение». Марк купил красивый домен и ведет там свой блог. А люди думают, что это какие-то рекомендации.

Какой? $HOME или $XDG_CONFIG_HOME?

$XDG_CONFIG_HOME

$ echo $XDG_CONFIG_HOME
/home/v/.config

Arch

http://standards.freedesktop.org/basedir-spec/basedir-spec-latest.html

Если средства поиска не справляются,

то это плохие средства поиска! Нужно впилить хорошие, годные средства. А костыли хардкодить фу

если либы лежат в /usr/local/lib64/hui то как их найдут средства поиска? через libastral чтоль ?

это тоже какое-то «изобретение» космонавта?

[olegchir@dualnote upbin]$ echo $XDG_CONFIG_HOME
/home/olegchir/.config

Arch x86_64

> через libastral чтоль ?

хранить структуру директорий дистра в виде переменных окружения или в файле с конфигом. Средства поиска будут искать сабжевые значения в них, и только потом заниматься самодеятельностью) Или с таким подходом что-то не так?