Re: [Mesa-dev] [PATCH 1/1] Link libEGL.so against libglapi.so
On Fri, Jan 28, 2011 at 9:22 AM, Jammy Zhou jammy.z...@linaro.org wrote: Just to make sure that this patch was sent out, so replied again here. Hi Chia-I, Could you please review this small patch? Sorry for the slow response. I recently had a surgery and I was not able to spend much time on my inbox. I will start catching up in the following weekend. When _glapi_get_proc_address is missing, I think egl_dri2 should dlopen libglapi.so. If --enable-shared-glapi is not given (libGL.so does not use the shared libglapi.so), egl_dri2 should disable EGL_OPENGL_BIT as libglapi.so and libGL.so are conflicting. Regards, Jammy On Thu, Jan 27, 2011 at 1:32 PM, Jammy Zhou jammy.z...@linaro.org wrote: egl_dri2 has been made built-in driver of EGL recently, and it depends on _glapi_get_proc_address symbol, which is defined in libglapi.so. So add the dependency of libglapi.so to libEGL Signed-off-by: Jammy Zhou jammy.z...@linaro.org --- src/egl/main/Makefile | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/egl/main/Makefile b/src/egl/main/Makefile index c710631..fcbce2b 100644 --- a/src/egl/main/Makefile +++ b/src/egl/main/Makefile @@ -58,7 +58,7 @@ LOCAL_LIBS = ifeq ($(filter dri2, $(EGL_DRIVERS_DIRS)),dri2) LOCAL_CFLAGS += -D_EGL_BUILT_IN_DRIVER_DRI2 LOCAL_LIBS += $(TOP)/src/egl/drivers/dri2/libegl_dri2.a -EGL_LIB_DEPS += $(XCB_DRI2_LIBS) $(LIBUDEV_LIBS) $(DLOPEN_LIBS) $(LIBDRM_LIB) +EGL_LIB_DEPS += $(XCB_DRI2_LIBS) $(LIBUDEV_LIBS) $(DLOPEN_LIBS) $(LIBDRM_LIB) -l$(GLAPI_LIB) endif ifeq ($(filter glx, $(EGL_DRIVERS_DIRS)),glx) LOCAL_CFLAGS += -D_EGL_BUILT_IN_DRIVER_GLX -- 1.7.1 -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33374] [bisect] FTBFS on commit 9767d3b5 (glapi: Fix OpenGL ES 1.1 and 2.0 interop)
https://bugs.freedesktop.org/show_bug.cgi?id=33374 Sergey Kondakov virtuous...@gmail.com changed: What|Removed |Added CC||virtuous...@gmail.com --- Comment #4 from Sergey Kondakov virtuous...@gmail.com 2011-01-28 01:11:56 PST --- hm, something similar happened with me on Gentoo while building 32bit mesa from git on 64bit system. config: ./configure --prefix=/usr --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib32 --enable-32-bit --disable-64-bit --with-x --disable-debug --disable-selinux --disable-static --enable-glx-tls --enable-xcb --disable-glw --disable-motif --disable-asm --enable-egl --enable-glu --disable-glut --enable-opengl --enable-openvg --enable-shared-glapi --enable-gles1 --enable-gles2 --with-dri-drivers= --enable-gallium --enable-gallium-egl --enable-gallium-swrast --with-state-trackers=,glx,egl,dri,vega --enable-gallium-llvm --disable-gallium-noop --disable-gallium-svga --disable-gallium-nouveau --disable-gallium-i915 --disable-gallium-i965 --disable-gallium-radeon --enable-gallium-r600 --with-egl-platforms=,x11,drm,fbdev --disable-gallium-llvm piece of log: python2 -t -O -O ../../../../src/mapi/mapi/mapi_abi.py \ --printer shared-glapi --mode lib ../gen/gl_and_es_API.xml ../../../../src/mapi/shared-glapi/glapi_mapi_tmp.h gmake[3]: Leaving directory `/var/tmp/portage/media-libs/mesa--r3/work/32/Mesa-/src/mapi/glapi/gen-es' running /usr/bin/makedepend *** glibc detected *** /usr/bin/makedepend: free(): invalid next size (fast): 0x01c66430 *** === Backtrace: = /lib/libc.so.6(+0x795c2)[0x2b74113235c2] /lib/libc.so.6(cfree+0x73)[0x2b74113273f3] /usr/bin/makedepend[0x403a10] /usr/bin/makedepend[0x403f6e] /usr/bin/makedepend[0x403a10] /usr/bin/makedepend[0x403c1f] /usr/bin/makedepend[0x403f6e] /usr/bin/makedepend[0x403a10] /usr/bin/makedepend[0x402604] /lib/libc.so.6(__libc_start_main+0xfd)[0x2b74112c8cdd] /usr/bin/makedepend[0x400fc9] === Memory map: 0040-00407000 r-xp 08:03 1049927 /usr/bin/makedepend 00606000-00607000 r--p 6000 08:03 1049927 /usr/bin/makedepend 00607000-00608000 rw-p 7000 08:03 1049927 /usr/bin/makedepend 00608000-0061c000 rw-p 00:00 0 01bc-01d67000 rw-p 00:00 0 [heap] 2b7410e76000-2b7410e96000 r-xp 08:03 153382 /lib64/ld-2.12.2.so 2b7410e96000-2b7410f06000 rw-p 00:00 0 2b7411095000-2b7411096000 r--p 0001f000 08:03 153382 /lib64/ld-2.12.2.so 2b7411096000-2b7411097000 rw-p 0002 08:03 153382 /lib64/ld-2.12.2.so 2b7411097000-2b7411098000 rw-p 00:00 0 2b7411098000-2b74110a7000 r-xp 08:03 1259011 /usr/lib64/libsandbox.so 2b74110a7000-2b74112a6000 ---p f000 08:03 1259011 /usr/lib64/libsandbox.so 2b74112a6000-2b74112a7000 r--p e000 08:03 1259011 /usr/lib64/libsandbox.so 2b74112a7000-2b74112a8000 rw-p f000 08:03 1259011 /usr/lib64/libsandbox.so 2b74112a8000-2b74112aa000 rw-p 00:00 0 2b74112aa000-2b7411424000 r-xp 08:03 153383 /lib64/libc-2.12.2.so 2b7411424000-2b7411624000 ---p 0017a000 08:03 153383 /lib64/libc-2.12.2.so 2b7411624000-2b7411628000 r--p 0017a000 08:03 153383 /lib64/libc-2.12.2.so 2b7411628000-2b7411629000 rw-p 0017e000 08:03 153383 /lib64/libc-2.12.2.so 2b7411629000-2b741163 rw-p 00:00 0 2b741163-2b7411632000 r-xp 08:03 153366 /lib64/libdl-2.12.2.so 2b7411632000-2b7411832000 ---p 2000 08:03 153366 /lib64/libdl-2.12.2.so 2b7411832000-2b7411833000 r--p 2000 08:03 153366 /lib64/libdl-2.12.2.so 2b7411833000-2b7411834000 rw-p 3000 08:03 153366 /lib64/libdl-2.12.2.so 2b7411834000-2b7411836000 rw-p 00:00 0 2b7411878000-2b741188d000 r-xp 08:03 140819 /lib64/libgcc_s.so.1 2b741188d000-2b7411a8c000 ---p 00015000 08:03 140819 /lib64/libgcc_s.so.1 2b7411a8c000-2b7411a8d000 r--p 00014000 08:03 140819 /lib64/libgcc_s.so.1 2b7411a8d000-2b7411a8e000 rw-p 00015000 08:03 140819 /lib64/libgcc_s.so.1 2b741400-2b7414021000 rw-p 00:00 0 2b7414021000-2b741800 ---p 00:00 0 7fff08f63000-7fff08f88000 rw-p 00:00 0 [stack] 7fff08fe9000-7fff08fea000 r-xp 00:00 0 [vdso] ff60-ff601000
Re: [Mesa-dev] [PATCH 1/1] Link libEGL.so against libglapi.so
On Fri, Jan 28, 2011 at 4:52 PM, Chia-I Wu olva...@gmail.com wrote: On Fri, Jan 28, 2011 at 9:22 AM, Jammy Zhou jammy.z...@linaro.org wrote: Just to make sure that this patch was sent out, so replied again here. Hi Chia-I, Could you please review this small patch? Sorry for the slow response. I recently had a surgery and I was not able to spend much time on my inbox. I will start catching up in the following weekend. Take care and have a good rest. ;) When _glapi_get_proc_address is missing, I think egl_dri2 should dlopen libglapi.so. If --enable-shared-glapi is not given (libGL.so does not use the shared libglapi.so), egl_dri2 should disable EGL_OPENGL_BIT as libglapi.so and libGL.so are conflicting. Hmm... The problem happens for me when load libEGL.so before libGLESv2.so. Of course the problem can be avoided in application side to load libGLESv2.so first. But I think we should better solve the dependency of libEGL.so (egl_dri2) on libglapi.so/libGL.so in mesa. If we can make libGL.so use libglapi.so, the issue becomes simple. Otherwise, it may be not easy to handle, because in that case we don't know if libGL.so will be used or not when load libEGL.so. Do you have plan to make libGL.so use libglapi.so by default? And I'm curious for what is blocking it. Regards, Jammy On Thu, Jan 27, 2011 at 1:32 PM, Jammy Zhou jammy.z...@linaro.org wrote: egl_dri2 has been made built-in driver of EGL recently, and it depends on _glapi_get_proc_address symbol, which is defined in libglapi.so. So add the dependency of libglapi.so to libEGL Signed-off-by: Jammy Zhou jammy.z...@linaro.org --- src/egl/main/Makefile |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/egl/main/Makefile b/src/egl/main/Makefile index c710631..fcbce2b 100644 --- a/src/egl/main/Makefile +++ b/src/egl/main/Makefile @@ -58,7 +58,7 @@ LOCAL_LIBS = ifeq ($(filter dri2, $(EGL_DRIVERS_DIRS)),dri2) LOCAL_CFLAGS += -D_EGL_BUILT_IN_DRIVER_DRI2 LOCAL_LIBS += $(TOP)/src/egl/drivers/dri2/libegl_dri2.a -EGL_LIB_DEPS += $(XCB_DRI2_LIBS) $(LIBUDEV_LIBS) $(DLOPEN_LIBS) $(LIBDRM_LIB) +EGL_LIB_DEPS += $(XCB_DRI2_LIBS) $(LIBUDEV_LIBS) $(DLOPEN_LIBS) $(LIBDRM_LIB) -l$(GLAPI_LIB) endif ifeq ($(filter glx, $(EGL_DRIVERS_DIRS)),glx) LOCAL_CFLAGS += -D_EGL_BUILT_IN_DRIVER_GLX -- 1.7.1 -- o...@lunarg.com ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] st/mesa: support for 1D/2D texture arrays
On 01/27/2011 01:57 PM, Christoph Bumiller wrote: This doesn't work, you use pipe_resource.depth0 for the array size but the gallium interface wants you to use pipe_resource.array_size. Do we fix the state tracker or the interface ? Yeah, I messed up there. I started fixing this last night but it's quite a bit of work, actually. OpenGL stores the array size as the texture height or depth but gallium has a separate array_size field. There's a lot of places where we do comparisons like st_width == pipe_width that need to be fixed. I got most of it worked out but I ran out of time yesterday. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] st/mesa: support for 1D/2D texture arrays
Am 28.01.2011 16:08, schrieb Brian Paul: On 01/27/2011 01:57 PM, Christoph Bumiller wrote: This doesn't work, you use pipe_resource.depth0 for the array size but the gallium interface wants you to use pipe_resource.array_size. Do we fix the state tracker or the interface ? Yeah, I messed up there. I started fixing this last night but it's quite a bit of work, actually. OpenGL stores the array size as the texture height or depth but gallium has a separate array_size field. There's a lot of places where we do comparisons like st_width == pipe_width that need to be fixed. I got most of it worked out but I ran out of time yesterday. Yeah, it seemed appropriate to have a separate field for array_size (and at that time less error prone due to having to change less existing code). Transfers etc. however unify the 3rd dimension parameter (z/cube face/array slice) hence it would be entirely possible to unify depth and array_size in the resource struct into a single member too. Though using the first unused member (height) for 1d arrays (like GL does) definitely would look like a hack to me at the resource level. Roland ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glcpp: Demote macro redefined from an error to a warning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/27/2011 09:16 PM, Carl Worth wrote: Module: Mesa Branch: master Commit: d3df641f0aba99b0b65ecd4d9b06798bca090a29 URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=d3df641f0aba99b0b65ecd4d9b06798bca090a29 Author: Carl Worth cwo...@cworth.org Date: Mon Aug 23 11:38:45 2010 -0700 Given the date on this commit, I'm going to assume that you pushed this by mistake. We decided months ago that this test case was just plain wrong, and we removed it from the test list. Could you please revert this commit? glcpp: Demote macro redefined from an error to a warning The GLSL specification is vague here, (just says as is standard for C++), though the C specifications seem quite clear that this should be an error. However, an existing piglit test (CorrectPreprocess11.frag) expects this to be a warning, not an error, so we change this, and document in README the deviation from the specification. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1C8e8ACgkQX1gOwKyEAw+QhQCghRJ3w7qiIOtIi3a/GyYz3y7l rIQAn3fvw3pfm/3rHrB+I+RFuMdlV4ZY =GB0c -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH 1/2] mesa: support internalFormat=GL_BGRA in TexImage2D
On 01/25/2011 06:49 AM, José Fonseca wrote: On Sat, 2011-01-22 at 19:18 -0800, Chad Versace wrote: On Sat, Jan 22, 2011 at 17:46, Ian Romanick i...@freedesktop.org wrote: What I want is a way with cmake to build files twice. The first time will be in the existing way. The second time will compile with - -DUSE_OPENGL_ES and will generate a .o file with a different name. ... I don't know cmake well enough to do that, and I keep forgetting to ask Chad. I have done just that with cmake recently; that is, building an executable twice, once using GL and again with GLES2. When Monday arrives, I'll take a look at how to best coerce Piglit to do this. It looks you already know a better way, but just in case, a straightforward way to do this is using out-of-source builds, one runs configures cmake with two seperate build directories (e.g., build/gl, build/gles) enabling GLES on the latter, and then its simply a matter of doing make -C build/gl make -C build/gles Jose If only Pilgit supported out-of-tree builds... The CMakeLists and Python scripts are hardcoded to expect an in-tree build. This deficiency of the CMakeLists is easily fixed (I've done so in a private branch). But, the Python scripts pose a more thorny problem. -- Chad Versace c...@chad-versace.us ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [RFC mesa-demos] Add --with-system-data-files configure option
Hello One of the problems with mesa-demos is that the demos have hardcoded paths to data files (example: fopen(../images/something.rgb, ...)). Distributions shipping the package need to sed all those paths in order to ship working demos. This patch introduces a DEMOS_DATA_DIR definition that should be used when trying to open a data file. After this patch, distros packaging mesa-demos only need to specify --with-system-data-files when building and the apps will automatically look for the file in the right place. If you're a developer that doesn't use make install, everything will still work as always: just don't use the new option, the patch is backwards-compatible. I have to admit that my autotools-fu is bad, so if you know any better way to implement this feature, please tell me: I'll be happy to learn and implement. IMHO, the ugliest part is the addition of the ac_define_dir m4 macro (stolen from the xserver tree, btw). For the CMake system, I only added a definition to keep backward-compatibility. Suggestions are welcome here too. Another detail is that image files were moved from src/images to src/data (since data/ contais not only image files, but .dat files too). As a last note, I didn't do anything to .vert, .geom and .frag files. Maybe they should be handled the same way? Some of these files are mentioned in .shtest files, and I didn't have time to investigate how these files work (maybe the only way would be using .in files?). As a consequence of moving images/ to data/, the patch file is 3.9MB long, so you can grab it here: http://www.inf.ufpr.br/paulo/0002-Add-with-system-data-files-option.patch Any comments, improvements or objections? Cheers, Paulo -- Paulo Zanoni ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH mesa-demos] cmake: fix egl/opengl compilation (needs -lm)
Signed-off-by: Paulo Zanoni pzan...@mandriva.com
---
My cmake-fu is not good. Maybe there are better ways to fix this. Suggestions
are always welcome =D
src/egl/opengl/CMakeLists.txt |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/egl/opengl/CMakeLists.txt b/src/egl/opengl/CMakeLists.txt
index ede9ec3..3a012e1 100644
--- a/src/egl/opengl/CMakeLists.txt
+++ b/src/egl/opengl/CMakeLists.txt
@@ -6,10 +6,10 @@ add_executable(eglinfo eglinfo.c)
target_link_libraries(eglinfo ${EGL_egl_LIBRARY})
add_executable(eglgears_screen eglgears.c)
-target_link_libraries(eglgears_screen ${EGL_egl_LIBRARY} eglut_screen)
+target_link_libraries(eglgears_screen ${EGL_egl_LIBRARY} eglut_screen m)
if(X11_FOUND)
add_executable(eglgears_x11 eglgears.c)
- target_link_libraries(eglgears_x11 ${EGL_egl_LIBRARY} eglut_x11)
+ target_link_libraries(eglgears_x11 ${EGL_egl_LIBRARY} eglut_x11 m)
endif(X11_FOUND)
--
1.7.1
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] Fwd: [PATCH] fix missing files in mesa tarballs (HEAD)
Hi, I have received the patch below privately and I don't know the GLSL compiler so well to be able to ack it. GLSL people, please review/apply. Marek -- Forwarded message -- From: Thierry Vignaud thierry.vign...@gmail.com Date: Fri, Jan 28, 2011 at 2:07 AM Subject: [PATCH] fix missing files in mesa tarballs (HEAD) To: Marek Olšák mar...@gmail.com The following patch fix missing files in mesa tarballs (HEAD): diff --git a/Makefile b/Makefile index 1bab521..d22e384 100644 --- a/Makefile +++ b/Makefile @@ -232,6 +232,7 @@ MAIN_FILES = \ $(DIRECTORY)/src/glsl/README\ $(DIRECTORY)/src/glsl/glcpp/*.[chly]\ $(DIRECTORY)/src/glsl/glcpp/README \ + $(DIRECTORY)/src/glsl/builtins \ $(DIRECTORY)/src/Makefile \ $(DIRECTORY)/src/mesa/Makefile* \ $(DIRECTORY)/src/mesa/sources.mak \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Fwd: [PATCH] fix missing files in mesa tarballs (HEAD)
On Friday, January 28, 2011 12:22:37 pm Marek Olšák wrote: Hi, I have received the patch below privately and I don't know the GLSL compiler so well to be able to ack it. GLSL people, please review/apply. Marek Thanks, I've applied this. Now that builtin_function.cpp is generated at build-time rather than living in the repo, we do need to ship src/glsl/builtins. --Kenneth -- Forwarded message -- From: Thierry Vignaud thierry.vign...@gmail.com Date: Fri, Jan 28, 2011 at 2:07 AM Subject: [PATCH] fix missing files in mesa tarballs (HEAD) To: Marek Olšák mar...@gmail.com The following patch fix missing files in mesa tarballs (HEAD): diff --git a/Makefile b/Makefile index 1bab521..d22e384 100644 --- a/Makefile +++ b/Makefile @@ -232,6 +232,7 @@ MAIN_FILES = \ $(DIRECTORY)/src/glsl/README\ $(DIRECTORY)/src/glsl/glcpp/*.[chly]\ $(DIRECTORY)/src/glsl/glcpp/README \ + $(DIRECTORY)/src/glsl/builtins \ $(DIRECTORY)/src/Makefile \ $(DIRECTORY)/src/mesa/Makefile* \ $(DIRECTORY)/src/mesa/sources.mak \ ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [PATCH] mesa: Set -Werror=declaration-after-statement in mesa/Makefile
MSVC does not support C99. To prevent GCC users from breaking the MSVC build, explicit errors must be set. --- src/mesa/Makefile |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/mesa/Makefile b/src/mesa/Makefile index 25e7cce..bb4d04d 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -21,8 +21,12 @@ MESA_CPPFLAGS := $(API_DEFINES) $(DEFINES) # append include dirs MESA_CPPFLAGS += $(INCLUDE_DIRS) $(TALLOC_CFLAGS) +# MSVC does not support C99. To prevent GCC users from breaking the MSVC +# build, explicit errors must be set. +C_ERROR_FLAGS := -Werror=declaration-after-statement + # tidy compiler flags -CFLAGS := $(filter-out $(DEFINES), $(CFLAGS)) +CFLAGS := $(filter-out $(DEFINES), $(CFLAGS)) $(C_ERROR_FLAGS) CXXFLAGS := $(filter-out $(DEFINES), $(CXXFLAGS)) # LLVM is needed for the state tracker -- 1.7.3.5 ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Set -Werror=declaration-after-statement in mesa/Makefile
On 01/28/2011 12:53 PM, Chad Versace wrote: MSVC does not support C99. To prevent GCC users from breaking the MSVC build, explicit errors must be set. --- src/mesa/Makefile |6 +- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/src/mesa/Makefile b/src/mesa/Makefile index 25e7cce..bb4d04d 100644 --- a/src/mesa/Makefile +++ b/src/mesa/Makefile @@ -21,8 +21,12 @@ MESA_CPPFLAGS := $(API_DEFINES) $(DEFINES) # append include dirs MESA_CPPFLAGS += $(INCLUDE_DIRS) $(TALLOC_CFLAGS) +# MSVC does not support C99. To prevent GCC users from breaking the MSVC +# build, explicit errors must be set. +C_ERROR_FLAGS := -Werror=declaration-after-statement + # tidy compiler flags -CFLAGS := $(filter-out $(DEFINES), $(CFLAGS)) +CFLAGS := $(filter-out $(DEFINES), $(CFLAGS)) $(C_ERROR_FLAGS) CXXFLAGS := $(filter-out $(DEFINES), $(CXXFLAGS)) # LLVM is needed for the state tracker I think this should be done up in the configure.ac file. Otherwise we're assuming gcc in the Makefile. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Set -Werror=declaration-after-statement in mesa/Makefile
On 01/28/2011 01:03 PM, Brian Paul wrote: I think this should be done up in the configure.ac file. Otherwise we're assuming gcc in the Makefile. I was attempting to limit this change to files within core mesa. Setting this option globally breaks the Intel driver build, because those drivers use C99. For GCC builds, configure.ac explicitly sets --std=c99. See thread: Mesa (master): mesa: fix compilation. I am no Makefile or autoconf expert, so I see no other way to do this. -- Chad Versace c...@chad-versace.us ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] Mesa (master): glcpp: Demote macro redefined from an error to a warning
On Fri, 28 Jan 2011 08:42:23 -0800, Ian Romanick i...@freedesktop.org wrote: Given the date on this commit, I'm going to assume that you pushed this by mistake. We decided months ago that this test case was just plain wrong, and we removed it from the test list. Could you please revert this commit? Ah, that's right! When I found the commit recently I thought I had simply neglected to push it, (and had totally forgotten that we had decided we didn't want it). All reverted now. -Carl -- carl.d.wo...@intel.com pgpHaevnrfDl4.pgp Description: PGP signature ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] [PATCH] mesa: Set -Werror=declaration-after-statement in mesa/Makefile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/28/2011 02:15 PM, Chad Versace wrote: On 01/28/2011 01:03 PM, Brian Paul wrote: I think this should be done up in the configure.ac file. Otherwise we're assuming gcc in the Makefile. I was attempting to limit this change to files within core mesa. Setting this option globally breaks the Intel driver build, because those drivers use C99. For GCC builds, configure.ac explicitly sets --std=c99. See thread: Mesa (master): mesa: fix compilation. I am no Makefile or autoconf expert, so I see no other way to do this. There are a couple ways to work around this, but neither is particularly pleasant. 1. Assume gmake and put some conditional code in the Makefile. Since the makefiles already use the gmake 'include' extension, this is probably reasonable: if $(eq gcc,$(findstring gcc, $(CC))) C_ERROR_FLAGS := -Werror=declaration-after-statement endif 2. Create two sets of flags in configure.ac: one for core Mesa and another for DRI drivers. This will require touching pretty much all the makefiles. 3. Set a flag in configure.ac when CC is GCC. Use this flag to do the conditional error flags trick from #1. if $(eq y,$(CC_IS_GCC)) C_ERROR_FLAGS := -Werror=declaration-after-statement endif plus the required bits in configure.ac. Option #3 is probably the best bet, but, like I mentioned above, I'm not really fond of any of them. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk1DQ4sACgkQX1gOwKyEAw++1QCfWFaOLV7ggSherVUr8t6/YqS5 PNwAnjOET43yT0rc7REq80lYSRGF/tIO =/9zz -END PGP SIGNATURE- ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
Re: [Mesa-dev] st/mesa: support for 1D/2D texture arrays
On 01/28/2011 08:08 AM, Brian Paul wrote: On 01/27/2011 01:57 PM, Christoph Bumiller wrote: This doesn't work, you use pipe_resource.depth0 for the array size but the gallium interface wants you to use pipe_resource.array_size. Do we fix the state tracker or the interface ? Yeah, I messed up there. I started fixing this last night but it's quite a bit of work, actually. OpenGL stores the array size as the texture height or depth but gallium has a separate array_size field. There's a lot of places where we do comparisons like st_width == pipe_width that need to be fixed. I got most of it worked out but I ran out of time yesterday. OK, I finished the changes and pushed them. I haven't seen any regressions with piglit, etc. but I may have missed something. I'll be off line all weekend so feel free to revert if I've broken anything. -Brian ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33446] make distclean leaves some files
https://bugs.freedesktop.org/show_bug.cgi?id=33446 --- Comment #2 from Bryan Henderson bry...@giraffe-data.com 2011-01-28 19:40:36 PST --- Created an attachment (id=42681) View: https://bugs.freedesktop.org/attachment.cgi?id=42681 Review: https://bugs.freedesktop.org/review?bug=33446attachment=42681 This make 'make distclean' remove all non-distributed files -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33374] [bisect] FTBFS on commit 9767d3b5 (glapi: Fix OpenGL ES 1.1 and 2.0 interop)
https://bugs.freedesktop.org/show_bug.cgi?id=33374 --- Comment #5 from Dave Witbrodt dawit...@sbcglobal.net 2011-01-28 21:14:21 PST --- (In reply to comment #1) Some further information. The 'depend' file generated by 'makedepend' ends up with this as its contents: $ cat src/mapi/shared-glapi/depend # DO NOT DELETE entry.o: ../../../src/mapi/mapi/entry.h entry.o: ../../../src/mapi/mapi/u_compiler.h entry.o: ../../../src/mapi/mapi/u_current.h entry.o: ../../../src/mapi/glapi/glapi.h entry.o: ../../../src/mapi/glapi/glthread.h entry.o: ../../../src/mapi/mapi/u_thread.h entry.o: /usr/include/pthread.h entry.o: /usr/include/features.h entry.o: /usr/include/bits/predefs.h entry.o: /usr/include/sys/cdefs.h entry.o: /usr/include/bits/wordsize.h entry.o: /usr/include/gnu/stubs.h entry.o: /usr/include/gnu/stubs-64.h entry.o: /usr/include/endian.h entry.o: /usr/include/bits/endian.h entry.o: /usr/include/bits/byteswap.h entry.o: /usr/include/sched.h entry.o: /usr/include/bits/types.h entry.o: /usr/include/bits/typesizes.h entry.o: /usr/lib/gcc/x86_64-linux-gnu/4.4.5/include/stddef.h entry.o: /usr/include/time.h /usr/include/bits/sched.h entry.o: /usr/include/signal.h entry.o: /usr/include/bits/sigset.h entry.o: /usr/include/bits/pthreadtypes.h entry.o: /usr/include/bits/setjmp.h entry.o: ../../../src/mapi/mapi/u_macros.h entry.o: /usr/include/stdlib.h entry.o: /usr/include/bits/waitflags.h entry.o: /usr/include/bits/waitstatus.h entry.o: /usr/include/xlocale.h /usr/inc) entry.o: /usr/include/sys/select.h entry.o: /usr/include/bits/select.h entry.o: /usr/include/bits/time.h entry.o: /usr/include/sys/sysmacros.h entry.o: /usr/include/alloca.h entry.o: ../../../src/mapi/mapi/mapi_tmp.h entry.o: ../../../src/mapi/shared-glapi/glapi_mapi_tmp.h entry.o: ../../../include/GL/gl.h entry.o: ../../../include/GL/glext.h entry.o: /usr/include/inttypes.h /usr/include/stdint.h entry.o: /usr/include/bits/wchar.h The 11th line before the last line looks bad: entry.o: /usr/include/xlocale.h /usr/inc) There is also no newline at the end of the file, but all the 'depend' files generated by the last working version of Mesa seem to have one. I doubt this is relevant: it is obviously a result of the crash, not the cause. But I thought I would mention it in case it is a clue to a developer here. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33676] New: cmake build fail
https://bugs.freedesktop.org/show_bug.cgi?id=33676 Summary: cmake build fail Product: Mesa Version: git Platform: x86 (IA32) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Demos AssignedTo: mesa-dev@lists.freedesktop.org ReportedBy: rand...@mail.ru Using git checkout commit c1be1ce356e9cdedec558c503d6c74e6e1913d9f (tri-clear: fix redrawing) and gcc (GCC) 4.4.4 (as in Slackware-13.1) / cmake version 2.8.1 i see this compilation failure: guest@slax:/mnt/sda3/src/demos$ LANG=C make [ 0%] Building C object src/util/CMakeFiles/util.dir/shaderutil.c.o /mnt/sda3/src/demos/src/util/shaderutil.c:45: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'fake_ValidateProgram' /mnt/sda3/src/demos/src/util/shaderutil.c: In function 'ShadersSupported': /mnt/sda3/src/demos/src/util/shaderutil.c:67: error: 'fake_ValidateProgram' undeclared (first use in this function) /mnt/sda3/src/demos/src/util/shaderutil.c:67: error: (Each undeclared identifier is reported only once /mnt/sda3/src/demos/src/util/shaderutil.c:67: error: for each function it appears in.) make[2]: *** [src/util/CMakeFiles/util.dir/shaderutil.c.o] Error 1 make[1]: *** [src/util/CMakeFiles/util.dir/all] Error 2 make: *** [all] Error 2 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
[Mesa-dev] [Bug 33676] cmake build fail
https://bugs.freedesktop.org/show_bug.cgi?id=33676 --- Comment #1 from Andrew Randrianasulu rand...@mail.ru 2011-01-28 23:57:54 PST --- and i have glew-1.5.1-i486-1.txz installed Initially i tried to just use ./configure (and it complained about missing glew). Then it run OK and build few demos, but far from all. Then I run ccmake . in demos top dir , pressed c and g there, exit and run make. Error appear. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
