Bug#538752: asc: fails to start on 1024x600 display
Can you please test if the new 2.4 version of ASC fixes this bug? We have updated the resolution detection code. It works on a Netbook having a 1024*600 display running windows, and I hope it works on X too. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#534171: asc_mapedit fails with Unable to initialize PhysicsFS error
This bug has been fixed in the ASC 2.4 release -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#387765: Error: unknown pseudo-op: `.weakref' for every program
Package: g++-4.1
Version: 4.1.1-13
Severity: normal
I can't compile *any* C++ program with gcc-4.1.1. Even a trivial program like
#include iostream
int main()
{
std::cout Hello World;
return 0;
}
results, when called with 'g++ hello.cpp', in
/tmp/ccHGtEjK.s: Assembler messages:
/tmp/ccHGtEjK.s:89: Error: unknown pseudo-op: `.weakref'
/tmp/ccHGtEjK.s:90: Error: unknown pseudo-op: `.weakref'
[and many more].
This looks very much like bug #342484 - but I'm using the latest version
of binutils available in unstable: 2.17-2
gcc-4.0 works fine.
I have this problem for several weeks now, perhaps since the introduction
of gcc-4.1.
-- System Information:
Debian Release: testing/unstable
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: amd64 (x86_64)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.14.2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages g++-4.1 depends on:
ii gcc-4.1 4.1.1-13The GNU C compiler
ii gcc-4.1-base 4.1.1-13The GNU Compiler Collection (base
ii libc62.3.6.ds1-4 GNU C Library: Shared libraries
ii libstdc++6-4.1-dev 4.1.1-13The GNU Standard C++ Library v3 (d
g++-4.1 recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377872: libsdl-sound1.2-dev: missing dependencies to devel packages
On Tue, 11 Jul 2006 21:38:50 -0400 (EDT), Ari Pollak wrote: Are you sure about this? gltron builds fine with SDL_sound without depending on the extra libraries. But ASC does not. I think the difference is if you link a library against SDL_sound, then it's necessary; but if you link an application against SDL_sound then it's not necessary. Take a look at the dependencies of the libSDL-dev package: there are all the development packages of the librarires that the libSDL package depends on. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#377872: libsdl-sound1.2-dev: missing dependencies to devel packages
Package: libsdl-sound1.2-dev Version: 1.0.1-5 Severity: normal libsdl-sound depends on several other libraries. libsdl-sound-dev should depend on the -dev versions of these libraries, as it can't be linked against without their .la files being present. Dependencies from libsdl-sound.la: /usr/lib/libFLAC.la /usr/lib/libsmpeg.la /usr/lib/libSDL.la /usr/lib/libasound.la /usr/lib/libaa.la /usr/lib/libmikmod.la /usr/lib/libvorbisfile.la /usr/lib/libvorbisenc.la /usr/lib/libvorbis.la /usr/lib/libogg.la -- System Information: Debian Release: 3.1 Architecture: i386 (i686) Kernel: Linux 2.6.8-022stab078.9-enterprise Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968) Versions of packages libsdl-sound1.2-dev depends on: ii libsdl-sound1 1.0.1-5Decoder of several sound file form ii libsdl1.2-dev 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer developme -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309677: crash on alpha
On Mon, 23 May 2005 18:07:25 +0200, Bartosz Fenski aka fEnIo wrote: Do you have any clue what could cause this crash on alpha architecture? Sorry, I don't know what's going wrong. But to be honest, I would have been surprised if ASC did run on Alpha out of the box... I don't expect the changes to get ASC to run on other platforms to be big, but without such machines I can't find the problems myself. The delete void* and char array subscripts should not be the source of any portability problems, that should work in those circumstances, however ugly it is. Instead I suspect some structure alignment issues because ints are 64 Bit on Alpha - unlike AMD64, where an int is still 32 bit. Currently only i386 and AMD64 are known to work, PowerPC support is on the way. I'm very aware that there are foul things under the hood of ASC (using valgrind myself) : primarily the graphics engine with its MS-DOS legacy. I'm working on a complete replacement which will result in ASC 2.0, but that's still several month off. Regards, Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
