[debian][amd64]Как собрать 32-битный софт?

Ставь слаку, как раз есть статья, как сделать слаку мультилибной.

Чрут (debootstrap)?

Чрут

По сравнению с тем, как оно в Федоре - это... Это... Блин, слов подходящих нет. Наверное, пора говорить, что X (какашка) по сравнению с Y (мегакруть) - это как Дебиан против Федоры.

Нет, ну внатуре! В следующем году будет 10 лет, как x86 научилось сразу в двух нормальных режимах работать (32 и 64 бита).

Ну если не изменяет склероз ставишь

apt-get install g++-multilib gcc-multilib ia32-libs, 

Плюсую. Вроде так и делалось

потом просто собираешь

А теперь представь, что нужно штук 20 32-битных версий библиотек поставить.

Нет, ну толсто же.

Да, Debian - не-multilib-дистрибутив. И, думается мне, ещё несколько лет таковым не будет.

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

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

Ну здрастье, чё это они не совместимые? Для x86-64 даже декодер в процессоре не пришлось переделывать, все опкоды в старые влезли (путём кастрации некоторых устаревших фич).

+1, ибо для пользователя оно не нужно. а девелопер... он себе чрут в состоянии сбацать.

>Ну здрастье, чё это они не совместимые?

Я не могу запустить x86_64-бинарник на процессоре архитектуры x86. Следовательно, вот.


Более того, я могу фразу расширить на любые две разные архитектуры. Надеюсь, что x86_64 и x86 - разные архитектуры, спорить никто не будет.

Хотите 64-битную систему? Ставьте все пакеты 64-битные. Если есть то, что перекомпилировать под 32 бита нельзя или оно не работает - ставьте 32-битную систему. Зачем смешвать?

>перекомпилировать под 32 бита нельзя

s/32/64, конечно же.

scm + hudson ? :)

man pbuilder

+1, ибо для пользователя оно не нужно. а девелопер... он себе чрут в состоянии сбацать.

Так и запишем: дебиан - для хомячков. А девелопер способен поставить Федору, где нормально софт писать можно, не танцуя с бубном вокруг ограничений пакетного менеджера дистрибутива. И где из openssl «лишние» функции не убирают :)

Троллинг на эту тему у Reset-а лучше выходит.
А плохим танцорам всегда что-то мешает ...

Так и запишем - Fedora для горе-девелоперов, поставивших 64-битную систему, но продолжающих жрать какт^W^W разрабатывать под ней 32-bit-only приложения ;)

Я не могу запустить x86_64-бинарник на процессоре архитектуры x86. Следовательно, вот.

Ты ровно также не можешь запустить 64-битный виндовый бинарник на 64-битном линуксе, хотя формат команд одинаковый. Надеюсь, про намёк на ELF32/64 ты понял.

А так, если не использовать расширенные регистры и то реально небольшое количество новых фич, появившихся в x86-64, то код будет совместим с ia32 даже на бинарном уровне.

Более того, я могу фразу расширить на любые две разные архитектуры. Надеюсь, что x86_64 и x86 - разные архитектуры, спорить никто не будет.

Я буду. Между ними разницы даже меньше, чем между 80186 и 80386.

Хотите 64-битную систему? Ставьте все пакеты 64-битные. Если есть то, что перекомпилировать под 32 бита нельзя или оно не работает - ставьте 32-битную систему. Зачем смешвать?

А вот в более продвинутых дистрибутивах можно.

Троллинг на эту тему у Reset-а лучше выходит. А плохим танцорам всегда что-то мешает ...

Так я хороший девелопер. Конторы, в которых я работаю, ждут счастье и процветание. И на трёх последних используемых мной дистрибутивах (Fedora, Gentoo и текущий Arch) с мультилибом никаких проблем нет.

Так и запишем - Fedora для горе-девелоперов, поставивших 64-битную систему, но продолжающих жрать какт^W^W разрабатывать под ней 32-bit-only приложения ;)

Если жрать кактусы - это мой выбор, то я хочу, чтобы инструмент меня в моём же желании не ограничивал.

>> Хотите 64-битную систему? Ставьте все пакеты 64-битные. Если есть то, что перекомпилировать под 32 бита нельзя или оно не работает - ставьте 32-битную систему. Зачем смешвать?

А вот в более продвинутых дистрибутивах можно.

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

>Я буду. Между ними разницы даже меньше, чем между 80186 и 80386.

А вот, видимо, разработчики Fedora и остальных дистрибутивов думают иначе, раз собирают разные пакеты для i386 и amd64 :)

Ты ровно также не можешь запустить 64-битный виндовый бинарник на 64-битном линуксе, хотя формат команд одинаковый. Надеюсь, про намёк на ELF32/64 ты понял.

Крокодил зелёный, а стул на полу стоит. Нет, намёка не понял.

А вот в более продвинутых дистрибутивах можно.

Любой искусственный костыль ведёт за собой увеличение количества и уменьшение качества кода, а также простор для хитрых ошибок, типа недавней уязвимости в ядре Linux, связанной как раз с выполнением 32-битного кода в 64-битном ядре, ЕМНИП.

тогда chroot

>и тут можно, снова смотри доки pbilder

pbuilder - это тот же chroot, только в удобной для сборки пакетов обёртке. mv же хочет полноценную смешанную систему.

и тут можно, снова смотри доки pbilder

Это чрут. К тому же, заворачивать левый софт в deb - это тот ещё геморр. У нас используется убунту в качестве типа корпоративного стандарта, и вот я как-то пару недель назад решил на неё переползти. Поставил, обрезал, накатил свой аскетичный набор. So far, so good. Решил пересобрать SBCL. Скачал сорцы пакеты, посмотрел, закрыл, перегрузился в Арч. Арч - святая простота, я ему за PKGBUILD мильон проблем прощаю.

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

ЕМНИП, в Федоре можно так через mock собирать.

Тебе хочетцца поместный костыль, а не нормальное решение для разработчика.

Есть малораспростанённая софтина, не завёрнутая в пакет. В 64-битном виде она работает немного не так, как требуется. В Федоре пересобрать её под 32 бита и установить нужные по зависимостям 32-битные версии пакетов - как два пальца об асфальт.

Надеюсь, про намёк на ELF32/64 ты понял.

не помнишь как переменная-структуры эта называется, в которой указывается что за архитектура используется?! Вроде emachine?!

А вот, видимо, разработчики Fedora и остальных дистрибутивов думают иначе, раз собирают разные пакеты для i386 и amd64 :)

x86_64, а не amd64. И обе архитектуры, кстати, на x86-64 отлично уживаются.

Крокодил зелёный, а стул на полу стоит. Нет, намёка не понял.

Я выше достаточно подробно объяснил, что бинарной разницы между ia32 и x86-64 совсем чуть.

Любой искусственный костыль ведёт за собой увеличение количества и уменьшение качества кода, а также простор для хитрых ошибок, типа недавней уязвимости в ядре Linux, связанной как раз с выполнением 32-битного кода в 64-битном ядре, ЕМНИП.

Бороться с ошибками, появляющимися при разработке, путём запрета разработки - оригинальненько. Головную боль гильотиной не лечите?

не помнишь как переменная-структуры эта называется, в которой указывается что за архитектура используется?! Вроде emachine?!

Там недостаточно только тип машины поменять, все структуры тоже расползаются из-за 64-битной адресации. kdump для PAE, кстати, в ELF64 корку ядра сохраняет.

> pbuilder - это тот же chroot, только в удобной для сборки пакетов обёртке.

ну да , а вопрос удобства не на последнем плане.

mv же хочет полноценную смешанную систему.

ну это и нафиг не надо
Зачем мне засорять 32-битами основную систему ?))
Только от того, что так делает кто-то и где-то ?

Зачем мне засорять 32-битами основную систему ?))

Небось, когда флешплагин только 32-битным был, сношались с враппером и пачкой 32-битных либ для него ;)

>И обе архитектуры, кстати, на x86-64 отлично уживаются.

О да. Костыль в ядре, костыль в менеджере пакетов нижнего уровня, костыль в менеджере пакетов верхнего уровня, уродливое разделение lib32/lib64 либо лишний triplet в PREFIX - всего-то ничего.

Я выше достаточно подробно объяснил, что бинарной разницы между ia32 и x86-64 совсем чуть.

И? Архитектуры от этого одинаковыми быть не стали.

Бороться с ошибками, появляющимися при разработке, путём запрета разработки - оригинальненько. Головную боль гильотиной не лечите?

Нет. А вот бритву Оккама в отношении костылей - да, стараюсь применять.

для таких случаев (еще напомню wine) есть удобные пользовательские обертки для софта.
А для девелопинга используют pbilder - тем самым , разом накрывают больше проблем и вопросов.
И да, rpm-щикам хватит того, инфраструктуру сборки
rpm-навоза я должен лицезреть де-факто в дебдистрах (по стандартам lsb).

Дебдистры в техническом плане ничего из себя не представляют. И у них слабое лобби в комитете стандартизации :) Против шапки в плане разработки платформы противостоять бесполезно.

> Дебдистры в техническом плане ничего из себя не представляют.

О да, когда там раздуплится RH релизом и чем-то похожим на современное ?

Что-то сильно уже смахивает на корпоративный дом для престарелых ))

Против шапки в плане разработки платформы противостоять бесполезно.

Ну нафиг трогать их и лупится со старыми пнями ?
И так себе окочурятся.

О да, когда там раздуплится RH релизом и чем-то похожим на современное ?

Судя по бетам, совсем скоро. К тому же, «старый» RHEL-5 по промышленным фичам и их интеграции куда круче, чем «новый» сид или альфа очередной бубунты.

Мантры ... для жителей склепов.

В Debian'е только через chroot, в ia32-libs ничерта нет, а 32х битные пакеты в убогом Debian'е ставить нельзя.

> а 32х битные пакеты в убогом Debian'е ставить нельзя.

а вот и унылые склеротики пожаловали:

dpkg --force-help

> dpkg --force-help

Данный способ не позволяет одновременно поставить amd64 и i386 версии пакетов, поэтому не является решением.

> Данный способ не позволяет одновременно поставить amd64 и i386 версии пакетов
так нельзя или не подходит ? - определитесь уже.
Я не вижу никакого смысла ставить одновременно gedit 64 бит и gedit 32
бит. А про задачи разработки я уже сказал.
Эти хотелки практически бессмысленны даже в рамках одной архитектуры.
Пример:
1. Дано:Lenny 32, и надо собрать пакет для testing 32 или sid 32.

2. Дано: testing 32 , и надо собрать пакет для lenny 32

....

>Я буду. Между ними разницы даже меньше, чем между 80186 и 80386.

Вам бы матчасть подтянуть. Чтоб не палиться подобным бредом, тем более - на ЛОРе:)

>К тому же, «старый» RHEL-5 по промышленным фичам и их интеграции куда круче, чем «новый» сид или альфа очередной бубунты.

Ага, вот только если надо поставить что-то современное, то приходится перепортить весь «оттестированный ынтерпрайз», наставив левых пакетов с малопонятных варезников^W репозиториев. Либо собирать ту же кучу ручками через rpms-как-его-там.

Увы, но новый софт иногда _нужен_.

>Ага, вот только если надо поставить что-то современное, то приходится перепортить весь «оттестированный ынтерпрайз», наставив левых пакетов с малопонятных варезников^W репозиториев. Либо собирать ту же кучу ручками через rpms-как-его-там.

Увы, но новый софт иногда _нужен_.

Ключевое слово - «иногда». И при этом, если анонимусы думают, что им «нужен новый софт», то в 90% случаев они ошибаются

Вам бы матчасть подтянуть. Чтоб не палиться подобным бредом, тем более - на ЛОРе:)

Ну давай, устрой разоблачение.

во-первых это костыль и не позволяет автоматизировать процесс с помощью apt-get, а во-вторых оно не работает из-за кривого разделения на lib32/lib64

Собрать пакет и вести разработку это разные вещи.

иногда нужно, так как ia32-libs в дебианобунтах сильно ограничен и не позволяет запускать любой 32х битный софт

>во-первых это костыль

Во-первых - это не костыль, а тебе просто так этого хочется.
Мне проще доказать , что навязываемые вами подходы (и по дурным привычкам практики) именно и есть самые натуральные костыли и захламление системы, а не путь разработки нормальных инструментов для других архитектур CPU и версий дистров.

и не позволяет автоматизировать процесс с помощью apt-get

Во-вторых, не надо фигню всякую автоматизировать, так как
чего нет в дистре для 64 бит , то или уже упаковано в обертки 32 бит, или же существование его неоправдано вовсе.
А разовое втыкание инородного пакета, это скорее как несчастный случай , а пример нормальной практики обслуживания системы.
ps:
Настойчивое желание непонятного можно пояснить только стремлением к закрытым блобам x86 или же «пригибанием» на скорую руку поганого кода «only x86 by design».
Т.е., фактически имеет место быть лечение последствий, а не причин - а это и есть костылестроение в чистом виде.

>а пример нормальной

fix: а не пример нормальной

>Собрать пакет и вести разработку это разные вещи.

Несомненно , а инструменты могут быть и общие.

Мне проще доказать , что навязываемые вами подходы (и по дурным привычкам практики) именно и есть самые натуральные костыли и захламление системы

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

чего нет в дистре для 64 бит , то или уже упаковано в обертки 32 бит, или же существование его неоправдано вовсе.

типичный аргумента фанатика — если система Х чего-то не умеет, то значит этого не нужно

Настойчивое желание непонятного можно пояснить только стремлением к закрытым блобам x86 или же «пригибанием» на скорую руку поганого кода «only x86 by design».

предлагаешь отказаться от проприетарного софта?