LINUX.ORG.RU

mesa-libs всё.

 , mesa-libs


0

1

Да они издеваются:

20210617:
  AFFECTS: users of graphics/mesa-libs
  AUTHOR: kbowling@FreeBSD.org

  Some libraries from mesa-libs are now provided by libglvnd while
  others were renamed. When building outside poudriere make sure to
  remove mesa-libs first in order to avoid conflict with libglvnd.

  For portmaster users:
  # pkg delete -f mesa-libs
  # portmaster -a

  For portupgrade users:
  # pkg delete -f mesa-libs
  # portupgrade -a

Мы будем по ним скучать:

% pkg info -r mesa-libs
mesa-libs-20.2.3:
	firefox-89.0.1,2
	mpv-0.33.1_3,1
	libreoffice-7.1.3.2_1
	ffmpeg-4.4_1,1
	mesa-demos-8.4.0_2
	java3d-1.5.2_6
	cairo-1.17.4,3
	xorg-server-1.20.11,1
	libepoxy-1.5.8
	thunderbird-78.11.0
	glew-2.2.0
	xf86-video-ati-19.1.0_3,1
	mesa-dri-20.2.3_1
	xscreensaver-5.44
	nvidia-settings-460.73.01
	webkit2-gtk3-2.30.5_1
	gstreamer1-plugins-gl-1.16.2_1
	freeglut-3.0.0_2
	chromium-90.0.4430.212_1
	swt-4.7.3.a
	libGLU-9.0.1
★★★★★

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

Восхитительная система, вместо того, чтобы в зависимостях указывать заголовочные файлы, они завязались на имена пакетов!

(Суть драмы: GL.h переехал в другой пакет)

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

Ну дык у вошедших в заговор выход только один раз и на вечно только в америке знаю цену настоящему архитектору

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

Суть драмы: GL.h переехал в другой пакет

и из-за этого нужно перекомпилировать ВСЁ установленное ПО!!! (На самом деле нет, но тс-с-с… Школотроны в действии!)

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

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

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

Ты чё такой дерзкий. Одного из разработчиков мезы, очевидно же.

Harald ★★★★★
()

А в чёт тайный смысл переименования пакета? Типа у нас вот такое именуетяся теперь во правилу xxx-yyy_zzz-sss, поэтому мы теперь всё переименуем. А вы пердольтесь ГЫЫЫЫЫЫЫЮ.

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

На деле оно вообще насрать в каком пакете быть должно, ну переехал и чёрт с ними аналога update-alternative нету? Или каноничного места где лежат GL заголовки? Бред какой то.

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

какое ещё имя пакета? всегда было #include<pisecka.h>

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

Я имел ввиду:
Checking integrity... done (0 conflicting)
The most recent versions of packages are already installed

PS: Я уже пошел ПО компилировать. Разработчики взялись за портирование костылей для видеодрайверов под фряху. Не знаю что с библиотеками, у меня релиз 13.

Aeeioyqee
()

Удалить mesa-libs через pkg delete -f, потом установить virtualgl и снова mesa-libs. Это проблема? И к чему вся эта драма от пользователя freebsd со стажем?

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

В одной отсталой студенческой системе - GNU/Linux - есть программа pkg-config, которая сама может имя нужного пакета, если его разработчик озаботился тем, чтобы прописать соответствующую информацию. Конечно, далеко не все авторы пакетов так сильно заморачиваются, но для системных вещей вроде GL.h/EGL.h это сделано. И потому не важно, в какой пакет в следующий раз перенесут заголовочные и объектный файлы, при компиляции проблемы не возникнут. Очень странно, что профессура из FreeBSD не сделала аналогичного механизма. Ну или может сделали, но почему-то забыли нормально прописать мезу.

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

Вообще-то как раз наоборот, pkg-config по имени пакета (которое нужно знать заранее) выдаёт пути к заголовочникам и библиотеки, с которыми нужно линковаться. В моём pkg-config на моей отсталой студенческой системе GNU/Linux по крайней мере так.

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

Тебя вводит в заблуждение справка. В реальности для pkg-config прописывают не имя пакета, а имя библиотеки или имя заголовочного файла. После чего система сборки сможет посмотреть список файлов, доступных в пакетах, найти там нужный .pc и установить этот пакет. Я уже сталкивался именно с этой проблемой и именно таким образом. Меза у меня была новая, в которой уже небыло заголовочных файлов, а libglvnd был старый, в котором иже еще небыло. И в результате сборка застревала на ошибке, что невозможно найти нужный пакет. Хотя нигде явно этот пакет небыл прописан, только через макросы вроде pkgconfig(GL)

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

Удалить mesa-libs через pkg delete -f, потом установить virtualgl и снова mesa-libs.

Если самостоятельно собираешь из портов, достаточно просто снести graphics/mesa-libs и форсированно переустановить (пересобранные с новыми зависимостями) пакеты.

А вот пользователям официальной бинарной репы повезло меньше, они могут словить. (%

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

Из libglvnd, как и в современных линуксах. Но один фиг там abi неизменный должен быть по стандарту, так что перелинковываться в теории не нужно.

Khnazile ★★★★★
()

Согласен с анонимом. Наброс неудачен.

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

Школотроны издеваются — прямым текстом в /usr/pors/UPDATING пишут, что для пользования graphics/mesa-libs нужно сначала удалить «источник» проблем, а потом пересобрать ВЕСЬ установленный софт.

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

для пользования graphics/mesa-libs нужно сначала удалить «источник» проблем, а потом пересобрать ВЕСЬ установленный софт

Это я как бы в курсе, вот только в ОП ты пытаешься запутать.

То есть graphics/mesa не всё, он есть и будет, просто для тех кто собирает себе софт из портов сам, один раз пострадает.

Заметь, что те кто юзают бинарную репу, могут пострадать более одного раза!

mord0d ★★★★★
()

Что за истерика? Force delete не удаляет зависимости.

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

Здорово. Можно теперь не иметь Месы в системе. libglx.so из состава X-Server слинкуется с libglvnd, а заголовочные файлы возьмёт от Khronos Group.

А больше вроде и не нужен никому OpenGL в системе. Только для компилирования этой библиотеки.

Хотя для Qt вроде нужен OpenGL. Для компиляции библиотеки QtOpenGL.

И для Wayland, хотя кому он нужен-то? Кстати, GBM-то, без которого Wayland не работает, находится в составе Mesa... Так что Mesa всё-таки нужна для сборки базовой системы.

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

Я пробовал скомпилировать Gentoo без Месы. И у меня это получилось.

Как раз тогда появился ебилд virtual/opengl, созданный специально для пользователей Gentoo на MacOS. Этот пакет позволяет программам быть скомпилированными не только с Месой, но и с любой другой реализацией OpenGL

Сначала я взял заголовочные файлы из драйвера NVIDIA. Начиная с драйвера версии 177.xx, драйвер NVIDIA не устанавливает хедеры в систему. Но они по-прежнему есть в run-файле (по-моему только в драйвере 430.xx их удалили). При помощи параметра --opengl-headers их можно установить.

Но заголовочные файлы от драйвера NVIDIA, оказывается, умеют OpenGL максимум второй версии. Собственно, потому их и перестали устанавливать в драйвере 177.xx - именно тогда появился OpenGL 3.

Поэтому я стал пользоваться файлами с сайта Khronos Group. И всё работает. Линкуется с проприетарной библиотекой, а о том, откуда хедеры, я уже говорил.

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

Теперь стало:

> pkg info -r mesa-libs
mesa-libs-20.2.3_1:
	chromium-91.0.4472.114
	mpv-0.33.1_3,1
	mesa-demos-8.4.0_2
	xorg-server-1.20.11,1
	mesa-dri-20.2.3_1
	java3d-1.5.2_6
	swt-4.7.3.a

и состав:

> pkg info mesa-libs
mesa-libs-20.2.3_1
Name           : mesa-libs
Version        : 20.2.3_1
Installed on   : Fri Jun 18 16:32:27 2021 MSK
Origin         : graphics/mesa-libs
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : graphics
Licenses       : 
Maintainer     : x11@FreeBSD.org
WWW            : https://www.mesa3d.org/
Comment        : OpenGL libraries that support GLX and EGL clients
Options        :
	PLATFORM_WAYLAND: off
	PLATFORM_X11   : on
	WAYLAND        : off
	ZSTD           : on
Shared Libs required:
	libX11.so.6
	libxshmfence.so.1
	libexpat.so.1
	libXext.so.6
	libxcb-xfixes.so.0
	libXdamage.so.1
	libxcb-present.so.0
	libX11-xcb.so.1
	libxcb-glx.so.0
	libdrm.so.2
	libxcb-sync.so.1
	libXxf86vm.so.1
	libxcb-dri3.so.0
	libxcb-dri2.so.0
	libxcb.so.1
	libXfixes.so.3
Shared Libs provided:
	libgbm.so.1
	libglapi.so.0
	libGLX_mesa.so.0
	libEGL_mesa.so.0
Annotations    :
	FreeBSD_version: 1300507
Flat size      : 1.27MiB
Description    :
This package contains the Mesa OpenGL libraries for GLX and EGL clients.
These include libEGL, libGL, and libglesv2 as well as utlity libraries
libglapi and gbm.

WWW: https://www.mesa3d.org/

Содержимое пакета:

> pkg info -l mesa-libs
mesa-libs-20.2.3_1:
	/usr/local/etc/libmap.d/mesa.conf
	/usr/local/include/EGL/eglextchromium.h
	/usr/local/include/EGL/eglmesaext.h
	/usr/local/include/gbm.h
	/usr/local/lib/libEGL_mesa.so
	/usr/local/lib/libEGL_mesa.so.0
	/usr/local/lib/libEGL_mesa.so.0.0.0
	/usr/local/lib/libGLX_mesa.so
	/usr/local/lib/libGLX_mesa.so.0
	/usr/local/lib/libGLX_mesa.so.0.0.0
	/usr/local/lib/libgbm.so
	/usr/local/lib/libgbm.so.1
	/usr/local/lib/libgbm.so.1.0.0
	/usr/local/lib/libglapi.so
	/usr/local/lib/libglapi.so.0
	/usr/local/lib/libglapi.so.0.0.0
	/usr/local/libdata/pkgconfig/gbm.pc
	/usr/local/share/glvnd/egl_vendor.d/50_mesa.json
iZEN ★★★★★
() автор топика
Ответ на: комментарий от ZenitharChampion

Что касается libglvnd

Зависимости:

> pkg info -r libglvnd
libglvnd-1.3.2:
	chromium-91.0.4472.114
	libreoffice-7.1.3.2_1
	firefox-89.0.1,2
	thunderbird-78.11.0
	mpv-0.33.1_3,1
	ffmpeg-4.4_1,1
	mesa-demos-8.4.0_2
	glew-2.2.0
	xf86-video-ati-19.1.0_3,1
	xorg-server-1.20.11,1
	libepoxy-1.5.8
	xscreensaver-5.44
	nvidia-settings-460.73.01
	webkit2-gtk3-2.30.5_1
	cairo-1.17.4,3
	gstreamer1-plugins-gl-1.16.2_1
	freeglut-3.0.0_2
	libGLU-9.0.1

Состав:

> pkg info libglvnd
libglvnd-1.3.2
Name           : libglvnd
Version        : 1.3.2
Installed on   : Fri Jun 18 16:11:30 2021 MSK
Origin         : graphics/libglvnd
Architecture   : FreeBSD:13:amd64
Prefix         : /usr/local
Categories     : graphics
Licenses       : MIT, APACHE20
Maintainer     : x11@FreeBSD.org
WWW            : https://gitlab.freedesktop.org/glvnd/libglvnd
Comment        : GL Vendor-Neutral Dispatch library
Options        :
	X11            : on
Shared Libs required:
	libX11.so.6
Shared Libs provided:
	libGL.so.1
	libGLESv1_CM.so.1
	libOpenGL.so.0
	libGLdispatch.so.0
	libGLESv2.so.2
	libEGL.so.1
	libGLX.so.0
Annotations    :
	FreeBSD_version: 1300507
Flat size      : 3.83MiB
Description    :
libglvnd is a vendor-neutral dispatch layer for arbitrating OpenGL API calls
between multiple vendors. It allows multiple drivers from different vendors to
coexist on the same filesystem, and determines which vendor to dispatch each
API call to at runtime.

Both GLX and EGL are supported, in any combination with OpenGL and OpenGL ES.

WWW: https://gitlab.freedesktop.org/glvnd/libglvnd

Содержимое пакета:

> pkg info -l libglvnd
libglvnd-1.3.2:
	/usr/local/include/EGL/egl.h
	/usr/local/include/EGL/eglext.h
	/usr/local/include/EGL/eglplatform.h
	/usr/local/include/GL/gl.h
	/usr/local/include/GL/glcorearb.h
	/usr/local/include/GL/glext.h
	/usr/local/include/GL/glx.h
	/usr/local/include/GL/glxext.h
	/usr/local/include/GLES/egl.h
	/usr/local/include/GLES/gl.h
	/usr/local/include/GLES/glext.h
	/usr/local/include/GLES/glplatform.h
	/usr/local/include/GLES2/gl2.h
	/usr/local/include/GLES2/gl2ext.h
	/usr/local/include/GLES2/gl2platform.h
	/usr/local/include/GLES3/gl3.h
	/usr/local/include/GLES3/gl31.h
	/usr/local/include/GLES3/gl32.h
	/usr/local/include/GLES3/gl3ext.h
	/usr/local/include/GLES3/gl3platform.h
	/usr/local/include/KHR/khrplatform.h
	/usr/local/include/glvnd/GLdispatchABI.h
	/usr/local/include/glvnd/libeglabi.h
	/usr/local/include/glvnd/libglxabi.h
	/usr/local/lib/libEGL.so
	/usr/local/lib/libEGL.so.1
	/usr/local/lib/libEGL.so.1.1.0
	/usr/local/lib/libGL.so
	/usr/local/lib/libGL.so.1
	/usr/local/lib/libGL.so.1.7.0
	/usr/local/lib/libGLESv1_CM.so
	/usr/local/lib/libGLESv1_CM.so.1
	/usr/local/lib/libGLESv1_CM.so.1.2.0
	/usr/local/lib/libGLESv2.so
	/usr/local/lib/libGLESv2.so.2
	/usr/local/lib/libGLESv2.so.2.1.0
	/usr/local/lib/libGLX.so
	/usr/local/lib/libGLX.so.0
	/usr/local/lib/libGLX.so.0.0.0
	/usr/local/lib/libGLdispatch.so
	/usr/local/lib/libGLdispatch.so.0
	/usr/local/lib/libGLdispatch.so.0.0.0
	/usr/local/lib/libOpenGL.so
	/usr/local/lib/libOpenGL.so.0
	/usr/local/lib/libOpenGL.so.0.0.0
	/usr/local/libdata/pkgconfig/egl.pc
	/usr/local/libdata/pkgconfig/gl.pc
	/usr/local/libdata/pkgconfig/glesv1_cm.pc
	/usr/local/libdata/pkgconfig/glesv2.pc
	/usr/local/libdata/pkgconfig/glx.pc
	/usr/local/libdata/pkgconfig/libglvnd.pc
	/usr/local/libdata/pkgconfig/opengl.pc
	/usr/local/share/licenses/libglvnd-1.3.2/APACHE20
	/usr/local/share/licenses/libglvnd-1.3.2/LICENSE
	/usr/local/share/licenses/libglvnd-1.3.2/MIT
	/usr/local/share/licenses/libglvnd-1.3.2/catalog.mk
iZEN ★★★★★
() автор топика
Ответ на: комментарий от Khnazile

Насчёт фермы. У меня тут SLES 11 в качестве сборочной фермы. Потому то тут старые библиотеки, с которыми линкуется приложение, и в итоге работает даже на старом линуксе.

Тут Меса странно собрана: в ней есть GL, GLES и GLES2, но нет EGL. Забыли? Я пересобрал. И при этом вообще не стал собирать ни один драйвер, кроме софтварного рендеринга. Потому что билд-ферма.

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

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

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

Всё дело в обратной совместимости.

SLES 11 вышел с Mesa 7.7. Потом выходили SLES 11 SP1, SP2 и так далее. Там несколько раз обновляли Месу, остановившись на версии 9.0. При этом не стали собирать EGL, потому что изначально его не было.

Другой пример - пакет coreutils. Его тоже несколько раз обновляли. При этом туда вернули утилиту su, которую в одной из версий удалили (в апстриме её перенесли в другой набор утилит, кажется util-linux). При этом НЕ добавили утилиту realpath, которая появилась в одной из новых версий. Просто потому что «раньше же её не было» и «обратная совместимость».

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