| Age | Commit message (Collapse) | Author |
|---|
|
It is impossible to have gcc generate SSE code without it, as thirdparty
applications often call us with an unaligned stack pointer.
|
|
|
|
Conflicts:
Makefile
progs/glsl/multitex.c
src/mesa/main/enums.c
src/mesa/main/state.c
src/mesa/main/texenvprogram.c
src/mesa/main/version.h
|
|
See also:
- http://bugs.python.org/issue6476
- http://scons.tigris.org/issues/show_bug.cgi?id=2449
|
|
gcc-4.2's optimizer has a strange bug where it looses code from inner
loops in certain situations. For example, if the appearently innocent
looking code below is compiled with gcc-4.2 -S -O1, the inner loop's
code is missing from the outputed assembly.
struct Size {
unsigned width;
};
struct Command {
unsigned length;
struct Size sizes[32];
};
extern void emit_command(void *command, unsigned length);
void
create_surface( struct Size size, unsigned faces, unsigned levels)
{
struct Command cmd;
unsigned face;
unsigned level;
cmd.length = faces*levels*sizeof(cmd.sizes[0]);
for(face = 0; face < faces; ++face) {
for(level = 0; level < levels; ++level) {
cmd.sizes[face*levels + level] = size;
// This should generate a shrl statement, but the whole for body
// disappears in gcc-4.2 -O1/-O2/-O3!
size.width >>= 1;
}
}
emit(&cmd, sizeof cmd.length + cmd.length);
}
Note that this is not specific to MinGW's gcc-4.2 crosscompiler (the
version typically found in debian/ubuntu's mingw32 packages). gcc-4.2 on
Linux also displays the same error. gcc-4.3 and above gets this
correctly though.
Updated MinGW debian packages with gcc-4.3 are available from
http://people.freedesktop.org/~jrfonseca/debian/pool/main/m/
|
|
This prevents the error
relocation R_X86_64_PC32 against symbol `_gl_DispatchTSD' can not be used when making a shared object; recompile with -fPIC
when building on x86_64 architecture.
|
|
|
|
|
|
Conflicts:
Makefile
src/gallium/drivers/softpipe/sp_screen.c
src/mesa/main/version.h
|
|
Also add ASPPCOMSTR.
|
|
This reverts commit fc7f92478286041a018ac4e72d2ccedeea7c0eca.
|
|
MSVC 64bit compiler takes forever on some of the files.
Might want to revisit this again later.
|
|
You can still get the old behavior by passing the option quiet=no to scons.
|
|
|
|
|
|
|
|
x86_64 is also supported.
|
|
|
|
|
|
Conflicts:
src/gallium/auxiliary/pipebuffer/pb_bufmgr_mm.c
src/gallium/auxiliary/util/u_tile.c
|
|
|
|
|
|
|
|
|
|
|
|
DRI drivers can be build side by side with other non-DRI drivers, therefore
there is no need to build gallium twice.
|
|
Like ccache, but works on all OSes.
|
|
It creates problems in many libraries (glut, glew) which are not unicode
aware.
|
|
It a scary world out there: people use all sort of non standard C stuff,
and we must enable support for that in here in order to build.
-pedantic still warn us when we use that nonstandard though.
|
|
|
|
|
|
MSVC may not support full C99, but supports more than plain C90. And
-pedantic without -std=c99 generates too many spurious warnings
(specially C++ style comments) to be of any use.
Note that using certain C99 features in the cross-platform parts of Gallium
is still not possible; namely mid-of-scope variable declarations and named
structure initializers will break MSVC builds.
|
|
MSVC may not support full C99, but supports more than plain C90. And
-pedantic without -std=c99 generates too many spurious warnings
(specially C++ style comments) to be of any use.
Note that using certain C99 features in the cross-platform parts of Gallium
is still not possible; namely mid-of-scope variable declarations and named
structure initializers will break MSVC builds.
|
|
|
|
|
|
|
|
To build an alternative opengl32.dll with Gallium's software-rasterizer from a
debian-based distribution run:
sudo apt-get install mingw32
scons platform=windows toolchain=crossmingw machine=x86 winsys=gdi dri=no
|
|
|
|
To build an alternative opengl32.dll with Gallium's software-rasterizer from a
debian-based distribution run:
sudo apt-get install mingw32
scons platform=windows toolchain=crossmingw machine=x86 winsys=gdi dri=no
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
scripts.
env.CodeGenerate(
target = 'my_source.c',
script = 'my_generator.py',
source = ['input.txt', 'another.txt'],
command = 'python $SCRIPT $SOURCE > $TARGET'
)
It will take care generating all appropriate dependencies, including any
module imported by the generator script, and the respective .pyc file
side effects.
|
|
|
