kpriv/pkgsrc
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
pkgsrc/graphics/MesaLib/hacks.mk

61 lines
2.1 KiB
Makefile
Raw Normal View History

Update to Mesa-7.0.4 (the head of the 7.0 branch in GIT). Basically, lots of bug fixes; the intent of my update was mostly to fix problems with i915 and r300 dri drivers and to provide the best environment possible for the xorg server update to the 1.4 branch. Morever, many of our patches from pkgsrc, i.e. those removed in this commit, are now included upstream. Additionally, MesaDemos now builds. NOTES: - MesaLib now requires xf86driproto 2.0.4, as earlier versions install dri_interface.h, which is not correct. - glu now exports its symbols via libtool's -export-symfile. The symfile is generated pre-build--see glu/Makefile. - glxinfo/glxgears do not seem to need to be linked to libpthread, and this seems to cause problems on NetBSD with the new drm code. If I am wrong about this, please let me know. The only program that seems to need libpthread is glthreads in MesaDemos.
2008-07-27 02:03:42 +02:00
# $NetBSD: hacks.mk,v 1.13 2008/07/27 00:03:42 bjs Exp $
added support for IRIX 5. Including inttypes.h, as introduced through patch-am, is necessary on IRIX 5 to have int64_t defined whereas it is not needed on IRIX 6, but should not hurt there either.
2006-10-01 22:31:13 +02:00
.if !defined(MESALIBS_HACKS_MK)
MESALIBS_HACKS_MK= # defined
### [Fri Dec 30 21:00:59 CET 2005 : schwarz]
### make sys/types.h not conflict with inttypes.h
### (issue is specific to IRIX 5.3)
###
Welcome to Mesa-7.0.3. Changes from 6.4.2 are (obviously) far too numerous to mention! This package brings with it support for the Direct Rendering Infrastructure (DRI) on NetBSD-current; the kernel DRM was committed approximately one year ago. Patches for NetBSD 4.0 are available in the mailing list archives (I think), but are _not supported_. Developers and other interested parties are encouraged to read the TODO file, as well as my remarks in options.mk. There is still a significant amount of work to be done. Users of NetBSD/i386 (-current) shouldn't have much trouble getting mainstream cards (Intel i915 and Radeon 9600- R430 are by far the most tested) to work. I have taken great pains to ensure that this works properly, but inevitably there will be problems--especially on heretofore untested (read: non-x86) hardware. Your questions, comments, problem reports, and of course bug fixes are welcome. NOTE: There are currently problems (on NetBSD, at least) linking some executables, e.g. compiz, due to unresolved symbols for libpthread functions. This is due to libX11's thread stubs, which should not be enabled on NetBSD >= 2.0; see the TODO For more information and the URL of an interim patch.
2008-04-24 09:40:23 +02:00
. if !empty(MACHINE_PLATFORM:MIRIX-5.3-*)
added support for IRIX 5. Including inttypes.h, as introduced through patch-am, is necessary on IRIX 5 to have int64_t defined whereas it is not needed on IRIX 6, but should not hurt there either.
2006-10-01 22:31:13 +02:00
PKG_HACKS+= sys_types_h-inttypes_h-conflict
post-wrapper:
As discussed on tech-pkg@ revert for now the last updates of the Mesa packages. Downgraded graphics/MesaLib to 6.4.2nb3 Downgraded graphics/glu to 6.4.2 Downgraded graphics/glut to 6.4.2 Downgraded graphics/glx-utils to 6.4.2 Downgraded graphics/MesaDemos to 6.4.2 Downgraded graphics/Mesa to 6.4.2 Approved byg agc@.
2007-08-13 13:18:28 +02:00
${MKDIR} ${BUILDLINK_DIR}/include/sys && ${GREP} -v '^typedef.*[^u_]int[12368]*_t;' /usr/include/sys/types.h > ${BUILDLINK_DIR}/include/sys/types.h
added support for IRIX 5. Including inttypes.h, as introduced through patch-am, is necessary on IRIX 5 to have int64_t defined whereas it is not needed on IRIX 6, but should not hurt there either.
2006-10-01 22:31:13 +02:00
# should match int8_t, int16_t, and int32_t (only)
Welcome to Mesa-7.0.3. Changes from 6.4.2 are (obviously) far too numerous to mention! This package brings with it support for the Direct Rendering Infrastructure (DRI) on NetBSD-current; the kernel DRM was committed approximately one year ago. Patches for NetBSD 4.0 are available in the mailing list archives (I think), but are _not supported_. Developers and other interested parties are encouraged to read the TODO file, as well as my remarks in options.mk. There is still a significant amount of work to be done. Users of NetBSD/i386 (-current) shouldn't have much trouble getting mainstream cards (Intel i915 and Radeon 9600- R430 are by far the most tested) to work. I have taken great pains to ensure that this works properly, but inevitably there will be problems--especially on heretofore untested (read: non-x86) hardware. Your questions, comments, problem reports, and of course bug fixes are welcome. NOTE: There are currently problems (on NetBSD, at least) linking some executables, e.g. compiz, due to unresolved symbols for libpthread functions. This is due to libX11's thread stubs, which should not be enabled on NetBSD >= 2.0; see the TODO For more information and the URL of an interim patch.
2008-04-24 09:40:23 +02:00
. endif
.include "../../mk/compiler.mk"
###
### Ordinarily, this is defined by the build. However, in pkgsrc,
Update to Mesa-7.0.4 (the head of the 7.0 branch in GIT). Basically, lots of bug fixes; the intent of my update was mostly to fix problems with i915 and r300 dri drivers and to provide the best environment possible for the xorg server update to the 1.4 branch. Morever, many of our patches from pkgsrc, i.e. those removed in this commit, are now included upstream. Additionally, MesaDemos now builds. NOTES: - MesaLib now requires xf86driproto 2.0.4, as earlier versions install dri_interface.h, which is not correct. - glu now exports its symbols via libtool's -export-symfile. The symfile is generated pre-build--see glu/Makefile. - glxinfo/glxgears do not seem to need to be linked to libpthread, and this seems to cause problems on NetBSD with the new drm code. If I am wrong about this, please let me know. The only program that seems to need libpthread is glthreads in MesaDemos.
2008-07-27 02:03:42 +02:00
### policy dictates that we do it here.
Add comment about not using -ffast-math pending further testing. It seems to cause instability, at least for me on NetBSD/amd64 (4.99.63).
2008-05-21 07:58:52 +02:00
###
### XXXbjs: -ffast-math seems to cause instability, at least on amd64.
### I have disabled it pending further testing.
Welcome to Mesa-7.0.3. Changes from 6.4.2 are (obviously) far too numerous to mention! This package brings with it support for the Direct Rendering Infrastructure (DRI) on NetBSD-current; the kernel DRM was committed approximately one year ago. Patches for NetBSD 4.0 are available in the mailing list archives (I think), but are _not supported_. Developers and other interested parties are encouraged to read the TODO file, as well as my remarks in options.mk. There is still a significant amount of work to be done. Users of NetBSD/i386 (-current) shouldn't have much trouble getting mainstream cards (Intel i915 and Radeon 9600- R430 are by far the most tested) to work. I have taken great pains to ensure that this works properly, but inevitably there will be problems--especially on heretofore untested (read: non-x86) hardware. Your questions, comments, problem reports, and of course bug fixes are welcome. NOTE: There are currently problems (on NetBSD, at least) linking some executables, e.g. compiz, due to unresolved symbols for libpthread functions. This is due to libX11's thread stubs, which should not be enabled on NetBSD >= 2.0; see the TODO For more information and the URL of an interim patch.
2008-04-24 09:40:23 +02:00
###
. if !empty(CC_VERSION:Mgcc-[34]*)
PKG_HACKS+= no-strict-aliasing
CFLAGS+= -fno-strict-aliasing
Add new round of distribution patches (update code to head of Mesa_7_0_branch). While here, ensure that all instances of pthread_getspecific are replaced with __libc_thr_getspecific on NetBSD (fixes linking issues with compiz, at least).
2008-05-21 06:11:37 +02:00
#PKG_HACKS+= gcc-fast-math
#CFLAGS+= -ffast-math
Welcome to Mesa-7.0.3. Changes from 6.4.2 are (obviously) far too numerous to mention! This package brings with it support for the Direct Rendering Infrastructure (DRI) on NetBSD-current; the kernel DRM was committed approximately one year ago. Patches for NetBSD 4.0 are available in the mailing list archives (I think), but are _not supported_. Developers and other interested parties are encouraged to read the TODO file, as well as my remarks in options.mk. There is still a significant amount of work to be done. Users of NetBSD/i386 (-current) shouldn't have much trouble getting mainstream cards (Intel i915 and Radeon 9600- R430 are by far the most tested) to work. I have taken great pains to ensure that this works properly, but inevitably there will be problems--especially on heretofore untested (read: non-x86) hardware. Your questions, comments, problem reports, and of course bug fixes are welcome. NOTE: There are currently problems (on NetBSD, at least) linking some executables, e.g. compiz, due to unresolved symbols for libpthread functions. This is due to libX11's thread stubs, which should not be enabled on NetBSD >= 2.0; see the TODO For more information and the URL of an interim patch.
2008-04-24 09:40:23 +02:00
. endif
. if !empty(CC_VERSION:Mgcc-[4-9]*)
# Don't hide symbols for glut by default, it doesn't know how to unhide them.
Backout last change. It's insufficient as already pointed out by Tobias Nygren and breaks the build of the "gle" package on XFree86 systems again.
2008-06-25 13:21:20 +02:00
. if empty(PKGNAME:M*glut*)
We want to use -fvisibility=hidden _unless_ we're building graphics/glut, not the other way around. - This is the way that mesa expects things to be. - Not doing this for MesaLib (at least for dri on NetBSD/amd64) will result in reloc-related errors at link-time. Building on NetBSD/amd64 was broken without this.
2008-06-24 20:55:44 +02:00
PKG_HACKS+= gcc-hidden-visibility
graphics/MesaLib/hacks.mk: revert to rev 1.8 graphics/MesaLib/patches/patch-aw: export glXGetProcAddressARB graphics/MesaLib/Makefile: bump PKGREVISION graphics/glu/Makefile: bump PKGREVISION Please help out by giving this change as extensive testing as possible before 2008Q2 is branched.
2008-06-27 15:24:39 +02:00
CFLAGS+= -fvisibility=hidden
Welcome to Mesa-7.0.3. Changes from 6.4.2 are (obviously) far too numerous to mention! This package brings with it support for the Direct Rendering Infrastructure (DRI) on NetBSD-current; the kernel DRM was committed approximately one year ago. Patches for NetBSD 4.0 are available in the mailing list archives (I think), but are _not supported_. Developers and other interested parties are encouraged to read the TODO file, as well as my remarks in options.mk. There is still a significant amount of work to be done. Users of NetBSD/i386 (-current) shouldn't have much trouble getting mainstream cards (Intel i915 and Radeon 9600- R430 are by far the most tested) to work. I have taken great pains to ensure that this works properly, but inevitably there will be problems--especially on heretofore untested (read: non-x86) hardware. Your questions, comments, problem reports, and of course bug fixes are welcome. NOTE: There are currently problems (on NetBSD, at least) linking some executables, e.g. compiz, due to unresolved symbols for libpthread functions. This is due to libX11's thread stubs, which should not be enabled on NetBSD >= 2.0; see the TODO For more information and the URL of an interim patch.
2008-04-24 09:40:23 +02:00
. endif
. endif
Add some SUBST magic for NetBSD to change the name of the function called in the x86/x86_64 assembler dispatch routine to __thr_getspecific to avoid an unresolved symbol error from ld at link-time. This is a weak alias in libc and a strong alias in libpthread, so everything should work fine. This could probably be fixed in a better way, but for now, I think "it works" is a plus. Bump rev.
2008-04-25 22:11:11 +02:00
###
### XXX this shoddy hack is here to fix the unresolved symbol error that
Add new round of distribution patches (update code to head of Mesa_7_0_branch). While here, ensure that all instances of pthread_getspecific are replaced with __libc_thr_getspecific on NetBSD (fixes linking issues with compiz, at least).
2008-05-21 06:11:37 +02:00
### results due to '.extern pthread_getspecific' in the x86/x86-64
### assembler dispatch routines. Morever, there are also link-time
### issues with certain other applications due to pthread_getspecific()
### in glthread.c and glxext.c, so "fix" those also.
Add some SUBST magic for NetBSD to change the name of the function called in the x86/x86_64 assembler dispatch routine to __thr_getspecific to avoid an unresolved symbol error from ld at link-time. This is a weak alias in libc and a strong alias in libpthread, so everything should work fine. This could probably be fixed in a better way, but for now, I think "it works" is a plus. Bump rev.
2008-04-25 22:11:11 +02:00
###
. include "../../mk/bsd.fast.prefs.mk"
. if ${OPSYS} == "NetBSD" && !empty(MACHINE_ARCH:M*86*) && \
empty(PTHREAD_STUBLIB:U:M*pthstub*)
SUBST_CLASSES+= asm-hack
SUBST_FILES.asm-hack= src/mesa/x86/glapi_x86.S
Add new round of distribution patches (update code to head of Mesa_7_0_branch). While here, ensure that all instances of pthread_getspecific are replaced with __libc_thr_getspecific on NetBSD (fixes linking issues with compiz, at least).
2008-05-21 06:11:37 +02:00
SUBST_FILES.asm-hack+= src/mesa/x86-64/glapi_x86-64.S
SUBST_FILES.asm-hack+= src/mesa/glapi/glthread.c
SUBST_FILES.asm-hack+= src/glx/x11/glxext.c
Update to Mesa-7.0.4 (the head of the 7.0 branch in GIT). Basically, lots of bug fixes; the intent of my update was mostly to fix problems with i915 and r300 dri drivers and to provide the best environment possible for the xorg server update to the 1.4 branch. Morever, many of our patches from pkgsrc, i.e. those removed in this commit, are now included upstream. Additionally, MesaDemos now builds. NOTES: - MesaLib now requires xf86driproto 2.0.4, as earlier versions install dri_interface.h, which is not correct. - glu now exports its symbols via libtool's -export-symfile. The symfile is generated pre-build--see glu/Makefile. - glxinfo/glxgears do not seem to need to be linked to libpthread, and this seems to cause problems on NetBSD with the new drm code. If I am wrong about this, please let me know. The only program that seems to need libpthread is glthreads in MesaDemos.
2008-07-27 02:03:42 +02:00
SUBST_MESSAGE.asm-hack=Teaching glapi about NetBSD thread stubs
Add some SUBST magic for NetBSD to change the name of the function called in the x86/x86_64 assembler dispatch routine to __thr_getspecific to avoid an unresolved symbol error from ld at link-time. This is a weak alias in libc and a strong alias in libpthread, so everything should work fine. This could probably be fixed in a better way, but for now, I think "it works" is a plus. Bump rev.
2008-04-25 22:11:11 +02:00
SUBST_SED.asm-hack= -e 's,pthread_getspecific,__libc_thr_getspecific,g'
SUBST_STAGE.asm-hack= post-patch
. endif
added support for IRIX 5. Including inttypes.h, as introduced through patch-am, is necessary on IRIX 5 to have int64_t defined whereas it is not needed on IRIX 6, but should not hurt there either.
2006-10-01 22:31:13 +02:00
.endif
Reference in a new issue Copy permalink