LINUX.ORG.RU

Бинарные сборки Wine

 ,


12

8

Часто бывает так, что в очередной минорной версии разработчики Wine что-нибудь ломают для одной конкретной программы или игры, при этом все остальные программы работают нормально. И пользователю приходится либо откатываться до предыдущей версии Wine (это возможно не во всех дистрибутивах), ставить PlayOnLinux, что не всем нравится, либо компиллировать самому.

Чтобы предотвратить это неудобство, я с некоторых пор делаю бинарные сборки Wine и выкладываю их для всех желающих. Располагаются они здесь. Когда задумывал это, то вдохновлялся примером PlayOnLinux, которые тоже делают собственные бинарные сборки Wine, но обладают некоторыми недостатками:

  1. Выходят нерегулярно.
  2. Скрипта, который их формирует, я так и не нашел.
  3. Мне нужна еще версия с патчами Staging, а они не для каждой версии их делают.

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

Преимущество бинарных сборок:

  1. Идут практически любом современном дистрибутиве. За абсолютно все дистрибутивы любой давности ручаться не буду, сам проверял только на паре дистрибутивов, поэтому хотелось бы чтобы вы их протестировали и подтвердили или опровергли это утверждение.
  2. Для использования не требуется ничего, установленных зависимостей для Wine. Сам системный Wine при этом даже необязателен.
  3. Можно иметь хоть с десяток разных версий Wine для разных программ и с легкостью переключаться между ними без каких-то переустановок. Чтобы установить бинарную сборку, достаточно лишь ее распаковать в любой каталог.

В процессе создания бинарных сборок я целенаправленно не применял никаких сторонних патчей. В версии с патчами Staging присутствует только набор патчей из Staging и больше ничего. В ванильной версии не применяются никакие патчи. Даже несмотря на то, что начиная с какой-то версии из ветки 1.9.x Wine стало невозможно скомпиллировать с помощью gcc 5.3.0 и патч довольно оперативно написали, я предпочел откатиться до gcc 4.8.5, чем применять этот патч. Сомневающимся могу порекомендовать скачать мой скрипт, собрать Wine самому с помощью gcc 4.8.5 и после чего сравнить свой хэш получившегося архива с моим.

Для чего эта тема? Во-первых, для информации. Может кому-нибудь пригодятся мои бинарные сборки, мне будет приятно. И еще протестируйте их пожалуйста на своих разных дистрибутивах разных версий, чтобы посмотреть, действительно ли они дистронезависимые или нет?

И еще раз ссылки:

  1. Сайт с бинарными сборками Wine
  2. Скрипт, по которому они формируются

P.S. Перед использованием скрипта отредактируйте его и измените содержимое переменных WORKDIR (каталог, в котором будет компиллироваться Wine) и GCC_VERSION (версия GCC, которая применяется для сборки) в соответствии со своими предпочтениями. А то там сейчас стоят мои значения.

Обновлено 04.02.17:
В связи с тем, что после выхода Wine 2.0 сменилась нумерация промежуточных версий (промежуточная версия теперь 2.1 и все исходники будут лежать в папке 2.x и еще они сменили формат архива), то скрипт для сборки разделен. Скрипт wine_build_1.9.x-2.0.sh - для сборки всех предыдущих версий Wine до версии 2.0 включительно и wine_build-2.x.sh - для всех версий после 2.0. Да, это неудобно. Но это лучше, чем если бы в одном скрипте писать кучу костылей по парсингу мажорной версии, минорной версии и их какого-то совмещения. Размер скрипта значительно увеличился бы, он стал бы трудночитаемым и вряд ли это решение было бы совсем безглючным.

Обновлено 25.10.18:
Я закрываю формирование бинарных сборок в связи с тем, что Wine в последнее время оброс сторонними патчсетами, вроде esync, да и самому мне это все надоело. К тому же появился Steam Play. Все предыдущие сборки вы можете скачать отсюда, но новые формироваться вряд ли будут. Там же вы найдете скрипт, с помощью которого можно будет сделать свою собственную сборку.

★★★★★

Привет! Посмотри мой проект. Я собираю последние версии программ в билд-ферме на основе CentOS 5, чтобы они просили glibc 2.4. Проблем обычно не возникает, потому что существует Red Hat Toolset с последней версией компилятора. Устанавливаю зависимости - и вперёд. Зависимости потом кладу в архив с программой (за исключением GTK, libpng, libjpeg, freetype и иксовых либ, потому что стандарт LSB гарантирует их наличие в дистрах). Проблема состоит только в том, что я не знаю что собрать.

Wine не собираю по этим причинам: 1). Мега-сложно: десятки зависимостей. 2). Отсутствие в дистре X Input 2.0 и непонятно что с этим делать. По этой причине в Crossover 12.0 прекратили поддержку RHEL5. 3). Есть же Crossover, один бинарь под все дистры.

ZenitharChampion ★★★★★ ()
Последнее исправление: ZenitharChampion (всего исправлений: 2)

забавный выбор gcc .... gcc:5.3.0 = ~ и удивляться что где-то косячит как минимум глупо gcc:4.9.3 = stable и у него нет тех проблем что есть у 4.8.5

а теперь вопрос : почему gcc:4.8.5 ?

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

А почему бы и нет? Я не слышал о проблемах в 4.8.5, но когда столкнулся с тем, что новую версию невозможно скомпиллировать тем компиллятором, который у меня в качестве основного, поэтому поставил в другой слот версию постарее, чтобы уж наверняка. Наверное можно было бы и 4.9.3, это не принципиально.

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

ЗдОрово! А сборки делаешь по скрипту или руками? Если по скрипту, то можешь поделиться?

Мега-сложно: десятки зависимостей

Я тоже пробовал собирать в самой древней из еще поддерживаемых Ubuntu 12.04. На меня свалилась тонна development-пакетов, некоторые при этом еще и стали конфликтовать друг с другом. Поэтому я тоже забил на это, в Gentoo собирать проще всего.

Отсутствие в дистре X Input 2.0 и непонятно что с этим делать

Перейти на CentOS 6? Или тогда теряется весь профит в сборке для старой версии glibc?

Rinaldus ★★★★★ ()
Последнее исправление: Rinaldus (всего исправлений: 3)
Ответ на: комментарий от Rinaldus

Руками. Поэтому на моей страничке по-прежнему старые сборки.

В 12.04 Wine прекрасно собирается: sudo apt-get build-dep wine. Должен быть включен этот репозиторий.

>> Отсутствие в дистре X Input 2.0 и непонятно что с этим делать

> Перейти на CentOS 6?

А это мысль! :-) Glibc 2.12 всяко лучше 2.20! Я сделаю исключение для Wine, и только он будет для версии 2.12.

ZenitharChampion ★★★★★ ()
Последнее исправление: ZenitharChampion (всего исправлений: 1)
Ответ на: комментарий от ZenitharChampion

Т.е чтобы собранный Wine запустился у максимально широкой аудитории, его надо собирать минимум в CentOS 6. Там сейчас glibc 2.12, судя по distrowatch.com. Я сравнил с другими популярными дистрибутивами (Ubuntu, Debian), эта версия была примерно в 2010-2011 году. Это примерно уровень Debian 7 или Ubuntu 11.04. Т.е это уже достаточно старые дистрибутивы, у которых поддержка уже истекает и мало кто на них сидит. Значит обхват аудитории будет практически максимальным: у всех уже более новые версии glibc. Проблема в том, что мне накладно арендовать еще одну VDS с CentOS 6. Может быть bootstrap поможет для того, чтобы оставаться в рамках моей текущей VDS или что-нибудь в этом роде?

Руками. Поэтому на моей страничке по-прежнему старые сборки.

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

Rinaldus ★★★★★ ()
Последнее исправление: Rinaldus (всего исправлений: 1)
Ответ на: комментарий от Rinaldus

Проблема в том, что мне накладно арендовать еще одну VDS с CentOS 6.

Запихать в чрут, не? Правда если не хватает места - тогда облом

Pinkbyte ★★★★★ ()
Последнее исправление: Pinkbyte (всего исправлений: 1)
Ответ на: комментарий от Pinkbyte

Поставлю CentOS 6 на виртуалку и попробую разобраться, как там компиллить Wine и что конкретно для этого нужно. Для этого потребуется некоторое время, поскольку CentOS я практически не знаю, не приходилось с ним работать. Если получится, то запихну архив корневого каталога в tar, перенесу на сервер и буду там пользоваться уже из-под chroot.

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

Если тебе нужны бинарные сборки, то конечно бери, если хочешь. Хотя лично для меня GUI для Wine не нужен. Я предпочитаю по старинке, по многолетней отработанной схеме.

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

Ты только новые версии будешь делать? Или остальные(7, 6, 5, 4, 3) тоже планируется?

P.S. А почему не пользуешь GUI? Удобно же, два щелчка - и все! К тому же в Wine Wizard можно все сделать, то же что и вручную. Я скрипты ведь добавил, там что хочешь пиши(они, естественно, запускаются с предупреждением).

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

Нет, ветки 1.7 и предыдущие делать не буду. Лично мне они не нужны, в них нет особого смысла ввиду того, что в версиях 1.8/1.9 ничего не сломано. Если кто-то захочет, то он сможет скомпиллировать их для себя с помощью моего скрипта.
GUI не использую, потому что уже много лет устанавливаю игры в отдельный Wine-префикс (в каталог /путь_к_игре/wine-имя_игры) и потом всегда делаю в каталоге с игрой крошечный bash скрипт launch:

#!/bin/bash
export WINEPREFIX=/путь_к_игре/wine-имя_игры
wine "$WINEPREFIX/путь_к_exe"
И так уже на протяжении нескольких лет. Зачем мне перегружать систему лишними для меня GUI? Кроме того, Wine в последнее время становится все больше и больше не у дел. Современные игры выходят либо на DirectX 11, которые Wine не умеет, либо нативные, вообще не нуждающиеся в нем. Поэтому у меня есть 2-3 игры (уже установленных), для которых нужен Wine, а для всего остального он становится не нужен, как это ни удивительно осознавать. Хотя если он обретет приемлемую поддержку DirectX 11, у него будет второе дыхание. Но это еще не скоро.

Rinaldus ★★★★★ ()
Последнее исправление: Rinaldus (всего исправлений: 3)

Я, кстати, вот что еще подумал: мой ресурс будет полезен даже тем, кто программу не будет ставить. Нужно только оценки сделать, работает ли решение. Тогда сможешь смотреть, какие библиотеки ставить и версию Wine. А можешь вообще скрипт накатать, который будет решения с моего сайта ставить.

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

я хз но пакеты в живой системе собирать не очень верно, для этого есть всяческие chroot обертки для создания временного окружения pbuilder, mock, может еще чего. Иногда пересобираю себе что-нить, никаких проблем. Можно собирать под нужную версию дистра и тп. ХЗ в общем зачем эти скрипты если честно

Drolyk ★★★ ()

Чтобы установить бинарную сборку, достаточно лишь ее распаковать в любой каталог.

У вайн столько этих loader'ов да wrapper'ов, но при этом он умеет работать из любого каталога несмотря на то, что как и для любой программы каталог установки жёстко задаётся на момент конфигурации (даже не на момент сборки):

configure --prefix=$WORKDIR/install/$NAME

Значит, с одной стороны запутали, а с другой хорошо написали.

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

Playonlinux собирает свои сборки неизвестно каким скриптом и к тому же они запрятаны у них в недрах серверов. У меня же все прозрачно: и скрипт выложен и адрес сервера для скачивания более простой.

Rinaldus ★★★★★ ()

велосипедишь, прошу:
https://www.archlinux.org/packages/?sort=&q=wine&maintainer=&flag...

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

старьё тут — https://archive.archlinux.org/packages/w/

amorpher ★★★★★ ()
Последнее исправление: amorpher (всего исправлений: 1)
Ответ на: комментарий от amorpher

Я сильно сомневаюсь, что эти пакеты пригодны для любого дистрибутива. Хотя бы из-за того, что размер пакета 40 МБ, а размеры каждого моего архива > 200 МБ.

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

пригодны для любого
просто забираешь из пакета bin, lib (lib32), share и вперёд
2 год делаю так

размеры каждого моего архива > 200 МБ.

кхм-кхм )

amorpher ★★★★★ ()
Последнее исправление: amorpher (всего исправлений: 2)
Ответ на: комментарий от Rinaldus

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

Ориентируюсь в первую очередь на минт и убунту, а так да, основная ОС у меня арч.

amorpher ★★★★★ ()
Последнее исправление: amorpher (всего исправлений: 1)
Ответ на: комментарий от amorpher

Если ты, находясь в арче, скачал его нативный пакет и просто распаковал его вместо того, чтобы установить с помощью Pacman'а (а по сути сделал за него его работу), то ничего удивительного, что этот пакет в результате будет работать.
Что касается Mint и Ubuntu (конструктивно это одна и та же система), то возможно это совпадение.
Я скачал арчевский пакет, распаковал его у себя в Gentoo и протестировал работу игр от Blizzard. У Battle.net Launcher белый фон вместо содержимого окна. WoW правда работает, но дальше экрана выбора персонажей я не заходил.
Я все же своим архивам доверяю больше, потому что я их собираю по дистронезависимой инструкции, которая дана на официальном сайте Wine. Распакованные пакеты от других дистрибутивов может и будут с некоторыми программами работать, но все же это может быть чревато багами.

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

Если ты, находясь в арче, скачал его нативный пакет и просто распаковал его вместо того, чтобы установить с помощью Pacman'а (а по сути сделал за него его работу), то ничего удивительного, что этот пакет в результате будет работать. Что касается Mint и Ubuntu (конструктивно это одна и та же система), то возможно это совпадение.

Сделал уже десятки сборок, жалоб нет, работает всё это как написал в предыдущем комментарии (на счёт требующихся порою некоторых либ).
Плюс в некоторых сборках необходимые для работы приложений (игр) виндолибы (dx*, vc etc) естественно уже есть в префиксе изначально.

amorpher ★★★★★ ()
Последнее исправление: amorpher (всего исправлений: 1)

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

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

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

amd_amd ()

В связи с тем, что после выхода Wine 2.0 сменилась нумерация промежуточных версий (промежуточная версия теперь 2.1 и все исходники будут лежать в папке 2.x и еще они сменили формат архива), то скрипт для сборки разделен. Скрипт wine_build_1.9.x-2.0.sh - для сборки всех предыдущих версий Wine до версии 2.0 включительно и wine_build-2.x.sh - для всех версий после 2.0. Да, это неудобно. Но это лучше, чем если бы в одном скрипте писать кучу костылей по парсингу мажорной версии, минорной версии и их какого-то совмещения. Размер скрипта значительно увеличился бы, он стал бы трудночитаемым и вряд ли это решение было бы совсем безглючным.

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

Я написал для себя небольшой скрипт-загрузчик. Вот он:

#!/bin/bash

wget http://wine.rinaldus.ru/vanilla/1.9/wine-$1-vanilla.tar.gz
tar xvf wine-$1-vanilla.tar.gz
rm wine-latest-vanilla # удаляем симлинк от старой версии
ln -s /media/Other/Programs/wine/wine-$1-vanilla /media/Other/Programs/wine/wine-latest-vanilla # делаем симлинк для новой версии
rm wine-$1-vanilla.tar.gz
ls -la wine-latest-vanilla # можно обойтись без этой строчки, но я предпочитаю убедиться, что все сделано правильно
Подправь для себя пути и можешь пользоваться.
А в качестве менеджера я использую линуксовские переменные. Добавь эти строчки в ~/.bashrc или куда-нибудь еще (у меня мои пользовательские переменные находятся в скрипте env_home, а его я вызываю из .bashrc при помощи команды source):
export WINE_VANILLA="/media/Other/Programs/wine/wine-latest-vanilla/bin/wine"
export WINECFG="/media/Other/Programs/wine/wine-latest-vanilla/bin/winecfg"
Опять же, подправь пути на свои. И теперь любую игру можно вызвать такой командой:
$WINE_VANILLA /media/Games/GameName/game.exe
Чтобы отредактировать префикс с помощью winecfg от моей сборки просто набрать команду $WINECFG.

Rinaldus ★★★★★ ()
Последнее исправление: Rinaldus (всего исправлений: 1)

установлен wine 2.6, как научить программы запущенные из под wine видеть usb-устройства, штатный explorer в комплекте с wine - их видит, а весь остальной запущенный софт нет, конкретно хочу обновить карты garmin через mapchecker - сам mapchecker запускается без проблем, но подключеного устройства не видит, в pcmanfm - его видно, в wine-вском explorer то же видно, поэкспериментировал с другими утилитами которые работают с usb, например rufus - таже картина сам стартует - флешек не видит...

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

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

Rinaldus ★★★★★ ()