Summary: | explicitly symlinking libraries without libtool breaks OpenBSD build | ||
---|---|---|---|
Product: | Mesa | Reporter: | Jonathan Gray <jsg> |
Component: | Other | Assignee: | mesa-dev |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | OpenBSD | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Jonathan Gray
2013-04-08 14:18:55 UTC
Hi Jonathan Just pushed a series that handles the symbolic links correctly, and makes building mesa a bit friendlier to non-linux plarforms. Give it a try and feel free to reopen if you're still having symlink related issues. commit 22c133546a5b4bec399d4e20cf63455b1c4b0959 Author: Emil Velikov <emil.l.velikov@gmail.com> Date: Sun Mar 9 11:50:44 2014 +0000 automake: create compat symlinks only for linux systems Hi Emil, I saw your series of patches on the list and pulled them into my branch with some other fixes required to build with and I could indeed complete a build. Unfortunately since then the way libraries are created has been changed to use an ld option that isn't present in the version of binutils included in OpenBSD (or the one in FreeBSD). --dynamic-list seems to have been introduced in binutils 2.18 from what I can make out. /bin/sh ../../../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall -fno-strict-aliasing -fno-builtin-memcmp -g -O0 -module -avoid-version -Wl,--version-script=./radeon.link -shared -no-undefined -Wl,--dynamic-list=./radeon.dyn -L/usr/local/lib -o r300_dri.la -rpath /usr/mesa/lib/dri drm_target.lo ../../../../../src/mesa/drivers/dri/common/libdricommon.la ../../../../../src/mesa/libmesagallium.la ../../../../../src/gallium/auxiliary/libgallium.la ../../../../../src/gallium/state_trackers/dri/drm/libdridrm.la ../../../../../src/gallium/winsys/radeon/drm/libradeonwinsys.la ../../../../../src/gallium/drivers/galahad/libgalahad.la ../../../../../src/gallium/drivers/trace/libtrace.la ../../../../../src/gallium/drivers/rbug/librbug.la ../../../../../src/gallium/drivers/r300/libr300.la -L/usr/X11R6/lib -ldrm -lexpat -lm -lpthread -L/usr/X11R6/lib -ldrm_radeon libtool: link: g++ -shared -fPIC -DPIC .libs/drm_target.o -Wl,--whole-archive ../../../../../src/mesa/drivers/dri/common/.libs/libdricommon.a ../../../../../src/mesa/.libs/libmesagallium.a ../../../../../src/gallium/auxiliary/.libs/libgallium.a ../../../../../src/gallium/state_trackers/dri/drm/.libs/libdridrm.a ../../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a ../../../../../src/gallium/drivers/galahad/.libs/libgalahad.a ../../../../../src/gallium/drivers/trace/.libs/libtrace.a ../../../../../src/gallium/drivers/rbug/.libs/librbug.a ../../../../../src/gallium/drivers/r300/.libs/libr300.a -Wl,--no-whole-archive -L/usr/local/lib -L/usr/X11R6/lib -ldrm -lexpat -lm -lpthread -ldrm_radeon -O2 -O0 -Wl,--version-script=./radeon.link -Wl,--dynamic-list=./radeon.dyn -o .libs/r300_dri.so /usr/bin/ld: unrecognized option '--dynamic-list=./radeon.dyn' /usr/bin/ld: use the --help option for usage information collect2: ld returned 1 exit status Makefile:669: recipe for target 'r300_dri.la' failed gmake[3]: *** [r300_dri.la] Error 1 gmake[3]: Leaving directory '/usr/users/jsg/src/mesa/src/gallium/targets/r300/dri' Makefile:493: recipe for target 'all-recursive' failed gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory '/usr/users/jsg/src/mesa/src/gallium/targets' Makefile:479: recipe for target 'all-recursive' failed gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory '/usr/users/jsg/src/mesa/src' Makefile:530: recipe for target 'all-recursive' failed gmake: *** [all-recursive] Error 1 Kind of unrelated to the symlinking but afaics you have three options * revert commit 8c136b53b79 * update binutils * nag the patch author to add a *BSD quirk :-) I'm not entirely sure why *BSD are still stuck with binutils 2.17 (afaics released Aug2011), but I'm guessing that that the quickest solution/workaround would be just to revert the commit locally. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.