From mint-bounce@lists.fishpool.fi Mon Jan 28 14:03:57 2008 Message-ID: <479E2587.3060105@atari-source.com> Date: Mon, 28 Jan 2008 13:57:11 -0500 From: Mark Duckworth User-Agent: Thunderbird 2.0.0.9 (Macintosh/20071031) MIME-Version: 1.0 To: Keith Scroggins CC: =?ISO-8859-1?Q?Vincent_Rivi=E8re?= , mint Subject: Re: [MiNT] gcc-4.2.2-mint-20080127 References: <479C9FDB.7020803@freesbee.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: mduckworth@atari-source.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Keith Scroggins wrote: >> Finally, I added the patches provided by MiKRO for compiling GCC >> 4.2.2 natively with GCC 2.95.3. I didn't include the patch for >> libstdc++-v3 about strtof() and strtold(), because it works well with >> the cross-compiler, and I wasn't able to reproduce the problem >> natively because of big memory problems. Of course, I will include it >> if it is really necessary. > > I think the patch is needed when bootstrapping from native GCC 2.95.3, > and thats the only time. > >> Keith, you said recently that the "thunk" problem was still here. >> Could you tell me how to reproduce it ? > > Other than building pieces of the ScummVM source tree, I lack the C++ > knowledge to really know how to reproduce this problem. In my own > version of GCC 4.1.2, I fixed the problem in mint.h with: > > /* This is the assembler directive to equate two values. */ > /* Fix for setlTHUNK ? > #undef SET_ASM_OP > #define SET_ASM_OP ".set" > */ > > The assembly that was being created was incorrect, and that solved the > problem. It was a basic hack. From a very quick test, that does not > solve the problem this time. > > Here is a sample of an error: > > sound/libsound.a(ym2612.o): In function > `MidiDriver_Emulated::MidiDriver_Emulated(Audio::Mixer*)': > /home/Keith/scummvm-build/../scummvm/sound/softsynth/emumidi.h:60: > multiple definition of `non-virtual thunk to MidiDriver_Emulated::open()' > sound/libsound.a(adlib.o): > /home/Keith/scummvm-build/../scummvm/sound/softsynth/emumidi.h:60: > first defined here > >> From that it looks like there is unhappiness with the fact that both > 'Adlib' and 'YM2612' (both ScummVM sound drivers) are using the > include emumidi.h to define a common open for the class? (method?) > MidiDriver_emulated::open(). My limited understanding of C++is that > this is fine because in both instances MidiDriver_emulated::open() > would be created as a subclass under Adlib and also under YM2612. > > I can see if I can deconstruct the code enough (and get enough > understanding) to create a test case. Now, this code does compile > with GCC 3.3.6, my 4.1.2, and is happy with 2.95.3 (but ScummVM > overall is no longer buildable with the older GCC). Does any of this > make sense? > > On a side note, I have gotten Maelstrom (another game written in C++ > and using SDL) to work with the new (previous patch) utilities. It > runs in MiNT, and crashes (with error message) in TOS, but its a > porting problem (can't locate files correctly, still working on that), > so the binary is executing! Previously it just always crashed in TOS > with error 35, or froze the machine. > > Keith > > Got this trying to patch: root@arawork:/h/newgccbu/gcc-4.2.2>bzcat ../gcc-4.2.2-mint-20080127.patch.bz2 | patch -p1 patching file config.guess patching file configure patching file configure.in patching file gcc/BASE-VER patching file gcc/config/m68k/lb1sf68.asm patching file gcc/config/m68k/mint.h patching file gcc/config/m68k/t-mint patching file gcc/config/m68k/xm-mint.h patching file gcc/config.gcc patching file libdecnumber/decNumberLocal.h patching file libiberty/hex.c patching file libiberty/safe-ctype.c The next patch would create the file libstdc++-v3/config/os/mint/ctype_base.h, which already exists! Assume -R? [n] Apply anyway? [n] y patching file libstdc++-v3/config/os/mint/ctype_base.h Patch attempted to create file libstdc++-v3/config/os/mint/ctype_base.h, which already exists. Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to file libstdc++-v3/config/os/mint/ctype_base.h.rej The next patch would create the file libstdc++-v3/config/os/mint/ctype_inline.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file libstdc++-v3/config/os/mint/ctype_inline.h.rej The next patch would create the file libstdc++-v3/config/os/mint/ctype_noninline.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file libstdc++-v3/config/os/mint/ctype_noninline.h.rej The next patch would create the file libstdc++-v3/config/os/mint/os_defines.h, which already exists! Assume -R? [n] Apply anyway? [n] Skipping patch. 1 out of 1 hunk ignored -- saving rejects to file libstdc++-v3/config/os/mint/os_defines.h.rej patching file libstdc++-v3/configure patching file libstdc++-v3/configure.host patching file libstdc++-v3/crossconfig.m4 root@arawork:/h/newgccbu/gcc-4.2.2> Thanks, Mark