basilisk-devel — Basilisk II development-related discussion

Re: [B2-devel] problems caused(?) by recent patches

[Ronald P. R. <ron...@xs...>]

Will it help when I can get you the crash reports of the reported  
crashes?

Ronald.


Op 16 jan 2010, om 02:53 heeft Charles Srstka het volgende geschreven:

> Unfortunately, I can’t get it to reproduce on my MacBook Pro, no  
> matter how I change the settings, so it’s a little hard to diagnose  
> at this point. But if it’s crashing even on Intel machines, I guess  
> the best thing to do would be to disable it for the time being until  
> it is possible to figure out what is going on.
>
> <sysdeps.h.diff>
>
>
> Charles
>
> On Jan 14, 2010, at 8:00 PM, Alexei Svitkine wrote:
>
>> Charles,
>>
>> Can you investigate the crashes with your precise timer patch?
>>
>> -Alexei
>>
>> On Thu, Jan 14, 2010 at 8:58 PM, Alexei Svitkine
>> <ale...@gm...> wrote:
>>> I've reverted the SDL audio patch.
>>>
>>> On Thu, Jan 14, 2010 at 3:06 PM, Ronald P. Regensburg
>>> <ron...@xs...> wrote:
>>>> In answer to the comments by Charles Srstka:
>>>>
>>>> About the precise timer patch:
>>>> The crash with the precise timer crash was not limited to PPC
>>>> machines. I noticed it myself on a PPC machine first while it did  
>>>> not
>>>> happen on my Intel machine. However, within 6 days after posting my
>>>> 18-10-2009 build I got in the SheepShaver forum four reports of the
>>>> crash, each at the very same moment in the startup process, one  
>>>> on a
>>>> PPC machine and three on a Intel machine. The 25-10-2009 build
>>>> (without the precise timer patch) solved the crash for myself on my
>>>> PPC machine as well as for the other reported PPC machine and for  
>>>> two
>>>> out of the three reported Intel machines. On the third reported  
>>>> Intel
>>>> machine the 25-10-2009 crashed with a SIGSEGV. That crash was  
>>>> resolved
>>>> by enabling "Ignore Illegal Memory Accesses" (ignoresegv true).  
>>>> Later,
>>>> there were a few more reports of SIGSEGV crashes on Intel machines
>>>> with the 25-10-2009 build that could be solved this way. So far,  
>>>> I got
>>>> one report of the 25-10-2009 build crashing with a SIGSEGV in  
>>>> Leopard
>>>> on a PPC machine, not yet solved nor understood.
>>>>
>>>> About the sdl-audio patch:
>>>> Probably best to simply remove the patch. In the original
>>>> pre-19-02-2009 BasiliskII/src/SDL/audio_sdl.cpp file the value for
>>>> audio_spec.samples is set to 4096, well within the recommended  
>>>> range.
>>>>
>>>> Ronald.
>>>>
>>>>
>>>> Op 14 jan 2010, om 17:11 heeft Charles Srstka het volgende  
>>>> geschreven:
>>>>
>>>>> On Jan 14, 2010, at 7:18 AM, Ronald P. Regensburg wrote:
>>>>>
>>>>>>
>>>>>> In Emaculation.com forums, Alexei Svitkine asked me to mail to  
>>>>>> this
>>>>>> list about patches I needed to revert before building SheepShaver
>>>>>> (and
>>>>>> BasiliskII) for Mac OS X in order to avoid problems.
>>>>>>
>>>>>>
>>>>>> The problems with the "precise timer patch" were discussed in the
>>>>>> basilisk-devel list between October 23 and October 28. Those  
>>>>>> problems
>>>>>> were the reason for me to make the 25-10-2009 build for
>>>>>> Emaculation.com within days after the 18-10-2009 build.
>>>>>>
>>>>>> In my last October 25 message to the basilisk-devel list I told  
>>>>>> which
>>>>>> files I used for the 25-10-2009 build to omit the "precise timer
>>>>>> patch" and the "sdl-audio patch".
>>>>>>
>>>>>> The "sdl-audio patch" apparently made sound for most users worse
>>>>>> rather than better. Users of both BasiliskII and SheepShaver  
>>>>>> builds
>>>>>> created after that patch was added, complained about the  
>>>>>> problems for
>>>>>> months and reported considerable improvement when I posted  
>>>>>> builds of
>>>>>> both without the patch. That happened before I joined this  
>>>>>> mailing
>>>>>> list. The problems were sound delays, stuttering, even skipping  
>>>>>> of
>>>>>> sounds. The problem was more serious in BasiliskII than in
>>>>>> SheepShaver.
>>>>>>
>>>>>> I do not know whether these patches actually cause the problems  
>>>>>> or
>>>>>> just make bugs in other parts of the code apparent.
>>>>>
>>>>> The crash with the precise timer patch was mostly limited to  
>>>>> running
>>>>> the app on PPC machines if I remember correctly, wasn’t it? Since
>>>>> SheepShaver runs completely different code paths on PPC and Intel,
>>>>> with the PPC version running native code and the Intel using
>>>>> emulation, I can see how the change could have caused problems  
>>>>> with
>>>>> one that would not have come up on the other. The best solution in
>>>>> this case may be to enable the precise timer patch only when
>>>>> building for Intel.
>>>>>
>>>>> The SDL audio patch, on the other hand, is simply ill-advised in  
>>>>> my
>>>>> opinion. The docs for SDL recommend using a value between 512 and
>>>>> 8192 for the ‘samples’ field of an SDL_AudioSpec. The patch in the
>>>>> SheepShaver source sets it to 16384. The result is laggy audio. I
>>>>> think the patch was made to reduce the demands on processing power
>>>>> for older machines, but for those with modern hardware it seems to
>>>>> cause more problems than it solves.
>>>>>
>>>>> Charles
>>>>> ------------------------------------------------------------------------------
>>>>> Throughout its 18-year history, RSA Conference consistently  
>>>>> attracts
>>>>> the
>>>>> world's best and brightest in the field, creating opportunities  
>>>>> for
>>>>> Conference
>>>>> attendees to learn about information security's most important
>>>>> issues through
>>>>> interactions with peers, luminaries and emerging and established
>>>>> companies.
>>>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>>>> _______________________________________________
>>>>> basilisk-devel mailing list
>>>>> bas...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Throughout its 18-year history, RSA Conference consistently  
>>>> attracts the
>>>> world's best and brightest in the field, creating opportunities  
>>>> for Conference
>>>> attendees to learn about information security's most important  
>>>> issues through
>>>> interactions with peers, luminaries and emerging and established  
>>>> companies.
>>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>>> _______________________________________________
>>>> basilisk-devel mailing list
>>>> bas...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>>>
>>>
>>
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently  
>> attracts the
>> world's best and brightest in the field, creating opportunities for  
>> Conference
>> attendees to learn about information security's most important  
>> issues through
>> interactions with peers, luminaries and emerging and established  
>> companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev_______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] problems caused(?) by recent patches

[Charles S. <bas...@ch...>]

Unfortunately, I can’t get it to reproduce on my MacBook Pro, no matter how I change the settings, so it’s a little hard to diagnose at this point. But if it’s crashing even on Intel machines, I guess the best thing to do would be to disable it for the time being until it is possible to figure out what is going on.



Charles

On Jan 14, 2010, at 8:00 PM, Alexei Svitkine wrote:

> Charles,
> 
> Can you investigate the crashes with your precise timer patch?
> 
> -Alexei
> 
> On Thu, Jan 14, 2010 at 8:58 PM, Alexei Svitkine
> <ale...@gm...> wrote:
>> I've reverted the SDL audio patch.
>> 
>> On Thu, Jan 14, 2010 at 3:06 PM, Ronald P. Regensburg
>> <ron...@xs...> wrote:
>>> In answer to the comments by Charles Srstka:
>>> 
>>> About the precise timer patch:
>>> The crash with the precise timer crash was not limited to PPC
>>> machines. I noticed it myself on a PPC machine first while it did not
>>> happen on my Intel machine. However, within 6 days after posting my
>>> 18-10-2009 build I got in the SheepShaver forum four reports of the
>>> crash, each at the very same moment in the startup process, one on a
>>> PPC machine and three on a Intel machine. The 25-10-2009 build
>>> (without the precise timer patch) solved the crash for myself on my
>>> PPC machine as well as for the other reported PPC machine and for two
>>> out of the three reported Intel machines. On the third reported Intel
>>> machine the 25-10-2009 crashed with a SIGSEGV. That crash was resolved
>>> by enabling "Ignore Illegal Memory Accesses" (ignoresegv true). Later,
>>> there were a few more reports of SIGSEGV crashes on Intel machines
>>> with the 25-10-2009 build that could be solved this way. So far, I got
>>> one report of the 25-10-2009 build crashing with a SIGSEGV in Leopard
>>> on a PPC machine, not yet solved nor understood.
>>> 
>>> About the sdl-audio patch:
>>> Probably best to simply remove the patch. In the original
>>> pre-19-02-2009 BasiliskII/src/SDL/audio_sdl.cpp file the value for
>>> audio_spec.samples is set to 4096, well within the recommended range.
>>> 
>>> Ronald.
>>> 
>>> 
>>> Op 14 jan 2010, om 17:11 heeft Charles Srstka het volgende geschreven:
>>> 
>>>> On Jan 14, 2010, at 7:18 AM, Ronald P. Regensburg wrote:
>>>> 
>>>>> 
>>>>> In Emaculation.com forums, Alexei Svitkine asked me to mail to this
>>>>> list about patches I needed to revert before building SheepShaver
>>>>> (and
>>>>> BasiliskII) for Mac OS X in order to avoid problems.
>>>>> 
>>>>> 
>>>>> The problems with the "precise timer patch" were discussed in the
>>>>> basilisk-devel list between October 23 and October 28. Those problems
>>>>> were the reason for me to make the 25-10-2009 build for
>>>>> Emaculation.com within days after the 18-10-2009 build.
>>>>> 
>>>>> In my last October 25 message to the basilisk-devel list I told which
>>>>> files I used for the 25-10-2009 build to omit the "precise timer
>>>>> patch" and the "sdl-audio patch".
>>>>> 
>>>>> The "sdl-audio patch" apparently made sound for most users worse
>>>>> rather than better. Users of both BasiliskII and SheepShaver builds
>>>>> created after that patch was added, complained about the problems for
>>>>> months and reported considerable improvement when I posted builds of
>>>>> both without the patch. That happened before I joined this mailing
>>>>> list. The problems were sound delays, stuttering, even skipping of
>>>>> sounds. The problem was more serious in BasiliskII than in
>>>>> SheepShaver.
>>>>> 
>>>>> I do not know whether these patches actually cause the problems or
>>>>> just make bugs in other parts of the code apparent.
>>>> 
>>>> The crash with the precise timer patch was mostly limited to running
>>>> the app on PPC machines if I remember correctly, wasn’t it? Since
>>>> SheepShaver runs completely different code paths on PPC and Intel,
>>>> with the PPC version running native code and the Intel using
>>>> emulation, I can see how the change could have caused problems with
>>>> one that would not have come up on the other. The best solution in
>>>> this case may be to enable the precise timer patch only when
>>>> building for Intel.
>>>> 
>>>> The SDL audio patch, on the other hand, is simply ill-advised in my
>>>> opinion. The docs for SDL recommend using a value between 512 and
>>>> 8192 for the ‘samples’ field of an SDL_AudioSpec. The patch in the
>>>> SheepShaver source sets it to 16384. The result is laggy audio. I
>>>> think the patch was made to reduce the demands on processing power
>>>> for older machines, but for those with modern hardware it seems to
>>>> cause more problems than it solves.
>>>> 
>>>> Charles
>>>> ------------------------------------------------------------------------------
>>>> Throughout its 18-year history, RSA Conference consistently attracts
>>>> the
>>>> world's best and brightest in the field, creating opportunities for
>>>> Conference
>>>> attendees to learn about information security's most important
>>>> issues through
>>>> interactions with peers, luminaries and emerging and established
>>>> companies.
>>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>>> _______________________________________________
>>>> basilisk-devel mailing list
>>>> bas...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>>> 
>>> 
>>> 
>>> ------------------------------------------------------------------------------
>>> Throughout its 18-year history, RSA Conference consistently attracts the
>>> world's best and brightest in the field, creating opportunities for Conference
>>> attendees to learn about information security's most important issues through
>>> interactions with peers, luminaries and emerging and established companies.
>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>> 
>> 
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel

Re: [B2-devel] problems caused(?) by recent patches

[Charles S. <bu...@ch...>]

Unfortunately, I can’t get it to reproduce on my MacBook Pro, no matter how I change the settings, so it’s a little hard to diagnose at this point. But if it’s crashing even on Intel machines, I guess the best thing to do would be to disable it for the time being until it is possible to figure out what is going on.

Re: [B2-devel] Errors building SheepShaver and BasiliskII for Windows using Cygwin

[howard s. <how...@ho...>]

Hi Alexei,

As for SheepShaver: SheepShaver.exe also builds OK. It's only SheepShaverGUI.exe that doesn't.

Best,
Howard 

> From: ale...@gm...
> Date: Thu, 14 Jan 2010 20:54:56 -0500
> To: bas...@li...
> Subject: Re: [B2-devel] Errors building SheepShaver and BasiliskII for	Windows using Cygwin
> 
> I've committed changes that should fix your issues with compiling
> dyngen.c. Can you verify that it now compiles properly?
> 
> As for the prefs_init()/prefs_exit() issue, I'll have to figure out
> why src/dummy/prefs_dummy.cpp isn't being built/linked for your
> config.
> 
> I've also committed a fix for the first Basilisk compile error you
> got. Please try again and let me know the results.
> 
> Thanks!
> 
> -Alexei
> 
> On Thu, Jan 14, 2010 at 11:03 AM, howard spoelstra
> <how...@ho...> wrote:
> > Hi,
> >
> > Using SDL-1.2.14, Cygwin 1.7.1 errors occur while building both SheepShaver
> > and BasiliskII. I have described the steps I take to build both executables
> > and (for SheepShaver) how to work around these errors.
> > Maybe someone can look into it and adjust the code?
> >
> > Thanks, best,
> > Howard
> >
> > SheepShaver:
> >
> > cd SheepShaver
> > make links
> > cd src/Windows
> > NO_CONFIGURE=1 ../Unix/autogen.sh
> >
> > ./configure leads to:
> >
> > (part of configure log....
> > checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config)
> >
> > Summary:
> > Enable JIT compiler .............. : yes
> > GTK user interface ............... : no
> >
> > ./configure --disable-gtktest leads to:
> >
> > (part of configure log...
> > checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config
> > checking for GTK+ - version >= 1.3.15... yes (version 2.6.8))
> >
> > Summary:
> > Enable JIT compiler .............. : yes
> > GTK user interface ............... : yes
> >
> >
> > $ make
> > gcc -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
> > -I../slirp -DHAVE_CONFIG_H -O2 -c ../kpx_cpu/src/cpu/jit/dyngen.c -o
> > obj/dyngen.ho
> > ../kpx_cpu/src/cpu/jit/dyngen.c: In function `patch_relocations'
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: `i' undeclared (first use in
> > this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: (Each undeclared identifier is
> > reported only once
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: for each function it appears
> > in.)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: `rel' undeclared (first use in
> > this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2178: error: `copy_size' undeclared (first
> > use in this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2179: error: `sym_name' undeclared (first
> > use in this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2180: error: `p' undeclared (first use in
> > this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c: In function `gen_file':
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2891: error: `data_sec_hdr' undeclared
> > (first use in this function)
> > make: *** [obj/dyngen.ho] Error 1
> >
> > I can solve this by using the revision 1.19 version of dyngen.c
> > Next, make stumbles over:
> >
> > g++ -o SheepShaverGUI.exe       obj/prefs.o obj/prefs_windows.o
> > obj/prefs_editor_gtk.o obj/xpram_windows.o obj/prefs_ite
> > ms.o obj/user_strings.o obj/user_strings_windows.o obj/util_windows.o
> > obj/packet32.o obj/SheepShaverGUI.o -lwsock32 -lip
> > hlpapi -LD:/GTK/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0
> > -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgo
> > bject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv   -mwindows -mno-cygwin
> > obj/prefs.o:prefs.cpp:(.text+0x9): undefined reference to `prefs_exit()'
> > obj/prefs.o:prefs.cpp:(.text+0x624): undefined reference to `prefs_init()'
> >
> > This can be solved by editing BasliskII\src\prefs.cpp and removing:
> > #ifdef SHEEPSHAVER
> >     // System specific initialization
> >     prefs_init();
> > #endif
> >
> > and
> > #ifdef SHEEPSHAVER
> >     // System specific deinitialization
> >     prefs_exit();
> > #endif
> >
> > This ultimately leads to succesfull builds of both SheepShaver.exe and
> > SheepShaverGUI.exe
> >
> >
> >
> > For Basilisk, using clean code from CVS again:
> >
> > ./configure leads to:
> >
> > (part of configure log...
> > checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config
> > checking for GTK+ - version >= 1.3.15... no)
> >
> > Summary:
> > Use JIT compiler ....................... : yes
> > JIT debug mode ......................... : no
> > Floating-Point emulation core .......... : IEEE fpu core
> > Assembly optimizations ................. : i386
> > Addressing mode ........................ : direct
> > GTK user interface ..................... : no
> >
> > ./configure --disable-gtktest leads to:
> >
> > Summary:
> > Use JIT compiler ....................... : yes
> > JIT debug mode ......................... : no
> > Floating-Point emulation core .......... : IEEE fpu core
> > Assembly optimizations ................. : i386
> > Addressing mode ........................ : direct
> > GTK user interface ..................... : yes
> >
> > make then reports (related to the recent SheepVM changes?):
> > g++ -I../include -I. -I../uae_cpu -I../slirp -DHAVE_CONFIG_H
> > -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE
> > -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS
> > -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2
> > -I/home/hsp/cvs/SDL/release_1.2.14/include/SDL -I/usr/include/mingw
> > -mno-cygwin -Dmain=SDL_main -c ../main.cpp -o obj/main.o
> > g++ -I../include -I. -I../uae_cpu -I../slirp -DHAVE_CONFIG_H
> > -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE
> > -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS
> > -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2
> > -I/home/hsp/cvs/SDL/release_1.2.14/include/SDL -I/usr/include/mingw
> > -mno-cygwin -Dmain=SDL_main -c main_windows.cpp -o obj/main_windows.o
> > main_windows.cpp: In function `int SDL_main(int, char**)':
> > main_windows.cpp:270: error: invalid conversion from `int' to `const char*'
> > main_windows.cpp:270: error: invalid initialization of reference of type
> > 'int&' from expression of type 'char**'
> > ../include/prefs.h:26: error: in passing argument 2 of `void PrefsInit(const
> > char*, int&, char**&)'
> > make: *** [obj/main_windows.o] Error 1
> >
> > There will be more errors building BasiliskII, but as I'm not able to solve
> > the first one, the next can't appear yet ;-)
> >
> >
> > ________________________________
> > Ontdek nu Windows phone. De smartphone van dit moment
> > ------------------------------------------------------------------------------
> > Throughout its 18-year history, RSA Conference consistently attracts the
> > world's best and brightest in the field, creating opportunities for
> > Conference
> > attendees to learn about information security's most important issues
> > through
> > interactions with peers, luminaries and emerging and established companies.
> > http://p.sf.net/sfu/rsaconf-dev2dev
> > _______________________________________________
> > basilisk-devel mailing list
> > bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> >
> >
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
 		 	   		  
_________________________________________________________________
25GB gratis online harde schijf
http://skydrive.live.com

Re: [B2-devel] Errors building SheepShaver and BasiliskII for Windows using Cygwin

[howard s. <how...@ho...>]

Hi Alexei,

BasiliskII and the GUI now compile successfully on Windows using Cygwin.
We windows users still suffer from some SDL related problem causing a black screen though...

Thanks,
Howard

> From: ale...@gm...
> Date: Thu, 14 Jan 2010 20:54:56 -0500
> To: bas...@li...
> Subject: Re: [B2-devel] Errors building SheepShaver and BasiliskII for	Windows using Cygwin
> 
> I've committed changes that should fix your issues with compiling
> dyngen.c. Can you verify that it now compiles properly?
> 
> As for the prefs_init()/prefs_exit() issue, I'll have to figure out
> why src/dummy/prefs_dummy.cpp isn't being built/linked for your
> config.
> 
> I've also committed a fix for the first Basilisk compile error you
> got. Please try again and let me know the results.
> 
> Thanks!
> 
> -Alexei
> 
> On Thu, Jan 14, 2010 at 11:03 AM, howard spoelstra
> <how...@ho...> wrote:
> > Hi,
> >
> > Using SDL-1.2.14, Cygwin 1.7.1 errors occur while building both SheepShaver
> > and BasiliskII. I have described the steps I take to build both executables
> > and (for SheepShaver) how to work around these errors.
> > Maybe someone can look into it and adjust the code?
> >
> > Thanks, best,
> > Howard
> >
> > SheepShaver:
> >
> > cd SheepShaver
> > make links
> > cd src/Windows
> > NO_CONFIGURE=1 ../Unix/autogen.sh
> >
> > ./configure leads to:
> >
> > (part of configure log....
> > checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config)
> >
> > Summary:
> > Enable JIT compiler .............. : yes
> > GTK user interface ............... : no
> >
> > ./configure --disable-gtktest leads to:
> >
> > (part of configure log...
> > checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config
> > checking for GTK+ - version >= 1.3.15... yes (version 2.6.8))
> >
> > Summary:
> > Enable JIT compiler .............. : yes
> > GTK user interface ............... : yes
> >
> >
> > $ make
> > gcc -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
> > -I../slirp -DHAVE_CONFIG_H -O2 -c ../kpx_cpu/src/cpu/jit/dyngen.c -o
> > obj/dyngen.ho
> > ../kpx_cpu/src/cpu/jit/dyngen.c: In function `patch_relocations'
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: `i' undeclared (first use in
> > this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: (Each undeclared identifier is
> > reported only once
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: for each function it appears
> > in.)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: `rel' undeclared (first use in
> > this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2178: error: `copy_size' undeclared (first
> > use in this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2179: error: `sym_name' undeclared (first
> > use in this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2180: error: `p' undeclared (first use in
> > this function)
> > ../kpx_cpu/src/cpu/jit/dyngen.c: In function `gen_file':
> > ../kpx_cpu/src/cpu/jit/dyngen.c:2891: error: `data_sec_hdr' undeclared
> > (first use in this function)
> > make: *** [obj/dyngen.ho] Error 1
> >
> > I can solve this by using the revision 1.19 version of dyngen.c
> > Next, make stumbles over:
> >
> > g++ -o SheepShaverGUI.exe       obj/prefs.o obj/prefs_windows.o
> > obj/prefs_editor_gtk.o obj/xpram_windows.o obj/prefs_ite
> > ms.o obj/user_strings.o obj/user_strings_windows.o obj/util_windows.o
> > obj/packet32.o obj/SheepShaverGUI.o -lwsock32 -lip
> > hlpapi -LD:/GTK/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0
> > -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgo
> > bject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv   -mwindows -mno-cygwin
> > obj/prefs.o:prefs.cpp:(.text+0x9): undefined reference to `prefs_exit()'
> > obj/prefs.o:prefs.cpp:(.text+0x624): undefined reference to `prefs_init()'
> >
> > This can be solved by editing BasliskII\src\prefs.cpp and removing:
> > #ifdef SHEEPSHAVER
> >     // System specific initialization
> >     prefs_init();
> > #endif
> >
> > and
> > #ifdef SHEEPSHAVER
> >     // System specific deinitialization
> >     prefs_exit();
> > #endif
> >
> > This ultimately leads to succesfull builds of both SheepShaver.exe and
> > SheepShaverGUI.exe
> >
> >
> >
> > For Basilisk, using clean code from CVS again:
> >
> > ./configure leads to:
> >
> > (part of configure log...
> > checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config
> > checking for GTK+ - version >= 1.3.15... no)
> >
> > Summary:
> > Use JIT compiler ....................... : yes
> > JIT debug mode ......................... : no
> > Floating-Point emulation core .......... : IEEE fpu core
> > Assembly optimizations ................. : i386
> > Addressing mode ........................ : direct
> > GTK user interface ..................... : no
> >
> > ./configure --disable-gtktest leads to:
> >
> > Summary:
> > Use JIT compiler ....................... : yes
> > JIT debug mode ......................... : no
> > Floating-Point emulation core .......... : IEEE fpu core
> > Assembly optimizations ................. : i386
> > Addressing mode ........................ : direct
> > GTK user interface ..................... : yes
> >
> > make then reports (related to the recent SheepVM changes?):
> > g++ -I../include -I. -I../uae_cpu -I../slirp -DHAVE_CONFIG_H
> > -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE
> > -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS
> > -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2
> > -I/home/hsp/cvs/SDL/release_1.2.14/include/SDL -I/usr/include/mingw
> > -mno-cygwin -Dmain=SDL_main -c ../main.cpp -o obj/main.o
> > g++ -I../include -I. -I../uae_cpu -I../slirp -DHAVE_CONFIG_H
> > -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE
> > -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS
> > -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2
> > -I/home/hsp/cvs/SDL/release_1.2.14/include/SDL -I/usr/include/mingw
> > -mno-cygwin -Dmain=SDL_main -c main_windows.cpp -o obj/main_windows.o
> > main_windows.cpp: In function `int SDL_main(int, char**)':
> > main_windows.cpp:270: error: invalid conversion from `int' to `const char*'
> > main_windows.cpp:270: error: invalid initialization of reference of type
> > 'int&' from expression of type 'char**'
> > ../include/prefs.h:26: error: in passing argument 2 of `void PrefsInit(const
> > char*, int&, char**&)'
> > make: *** [obj/main_windows.o] Error 1
> >
> > There will be more errors building BasiliskII, but as I'm not able to solve
> > the first one, the next can't appear yet ;-)
> >
> >
> > ________________________________
> > Ontdek nu Windows phone. De smartphone van dit moment
> > ------------------------------------------------------------------------------
> > Throughout its 18-year history, RSA Conference consistently attracts the
> > world's best and brightest in the field, creating opportunities for
> > Conference
> > attendees to learn about information security's most important issues
> > through
> > interactions with peers, luminaries and emerging and established companies.
> > http://p.sf.net/sfu/rsaconf-dev2dev
> > _______________________________________________
> > basilisk-devel mailing list
> > bas...@li...
> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
> >
> >
> 
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
 		 	   		  
_________________________________________________________________
25GB gratis online harde schijf
http://skydrive.live.com

Re: [B2-devel] problems caused(?) by recent patches

[Alexei S. <ale...@gm...>]

Charles,

Can you investigate the crashes with your precise timer patch?

-Alexei

On Thu, Jan 14, 2010 at 8:58 PM, Alexei Svitkine
<ale...@gm...> wrote:
> I've reverted the SDL audio patch.
>
> On Thu, Jan 14, 2010 at 3:06 PM, Ronald P. Regensburg
> <ron...@xs...> wrote:
>> In answer to the comments by Charles Srstka:
>>
>> About the precise timer patch:
>> The crash with the precise timer crash was not limited to PPC
>> machines. I noticed it myself on a PPC machine first while it did not
>> happen on my Intel machine. However, within 6 days after posting my
>> 18-10-2009 build I got in the SheepShaver forum four reports of the
>> crash, each at the very same moment in the startup process, one on a
>> PPC machine and three on a Intel machine. The 25-10-2009 build
>> (without the precise timer patch) solved the crash for myself on my
>> PPC machine as well as for the other reported PPC machine and for two
>> out of the three reported Intel machines. On the third reported Intel
>> machine the 25-10-2009 crashed with a SIGSEGV. That crash was resolved
>> by enabling "Ignore Illegal Memory Accesses" (ignoresegv true). Later,
>> there were a few more reports of SIGSEGV crashes on Intel machines
>> with the 25-10-2009 build that could be solved this way. So far, I got
>> one report of the 25-10-2009 build crashing with a SIGSEGV in Leopard
>> on a PPC machine, not yet solved nor understood.
>>
>> About the sdl-audio patch:
>> Probably best to simply remove the patch. In the original
>> pre-19-02-2009 BasiliskII/src/SDL/audio_sdl.cpp file the value for
>> audio_spec.samples is set to 4096, well within the recommended range.
>>
>> Ronald.
>>
>>
>> Op 14 jan 2010, om 17:11 heeft Charles Srstka het volgende geschreven:
>>
>>> On Jan 14, 2010, at 7:18 AM, Ronald P. Regensburg wrote:
>>>
>>>>
>>>> In Emaculation.com forums, Alexei Svitkine asked me to mail to this
>>>> list about patches I needed to revert before building SheepShaver
>>>> (and
>>>> BasiliskII) for Mac OS X in order to avoid problems.
>>>>
>>>>
>>>> The problems with the "precise timer patch" were discussed in the
>>>> basilisk-devel list between October 23 and October 28. Those problems
>>>> were the reason for me to make the 25-10-2009 build for
>>>> Emaculation.com within days after the 18-10-2009 build.
>>>>
>>>> In my last October 25 message to the basilisk-devel list I told which
>>>> files I used for the 25-10-2009 build to omit the "precise timer
>>>> patch" and the "sdl-audio patch".
>>>>
>>>> The "sdl-audio patch" apparently made sound for most users worse
>>>> rather than better. Users of both BasiliskII and SheepShaver builds
>>>> created after that patch was added, complained about the problems for
>>>> months and reported considerable improvement when I posted builds of
>>>> both without the patch. That happened before I joined this mailing
>>>> list. The problems were sound delays, stuttering, even skipping of
>>>> sounds. The problem was more serious in BasiliskII than in
>>>> SheepShaver.
>>>>
>>>> I do not know whether these patches actually cause the problems or
>>>> just make bugs in other parts of the code apparent.
>>>
>>> The crash with the precise timer patch was mostly limited to running
>>> the app on PPC machines if I remember correctly, wasn’t it? Since
>>> SheepShaver runs completely different code paths on PPC and Intel,
>>> with the PPC version running native code and the Intel using
>>> emulation, I can see how the change could have caused problems with
>>> one that would not have come up on the other. The best solution in
>>> this case may be to enable the precise timer patch only when
>>> building for Intel.
>>>
>>> The SDL audio patch, on the other hand, is simply ill-advised in my
>>> opinion. The docs for SDL recommend using a value between 512 and
>>> 8192 for the ‘samples’ field of an SDL_AudioSpec. The patch in the
>>> SheepShaver source sets it to 16384. The result is laggy audio. I
>>> think the patch was made to reduce the demands on processing power
>>> for older machines, but for those with modern hardware it seems to
>>> cause more problems than it solves.
>>>
>>> Charles
>>> ------------------------------------------------------------------------------
>>> Throughout its 18-year history, RSA Conference consistently attracts
>>> the
>>> world's best and brightest in the field, creating opportunities for
>>> Conference
>>> attendees to learn about information security's most important
>>> issues through
>>> interactions with peers, luminaries and emerging and established
>>> companies.
>>> http://p.sf.net/sfu/rsaconf-dev2dev
>>> _______________________________________________
>>> basilisk-devel mailing list
>>> bas...@li...
>>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>>
>>
>>
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently attracts the
>> world's best and brightest in the field, creating opportunities for Conference
>> attendees to learn about information security's most important issues through
>> interactions with peers, luminaries and emerging and established companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>

Re: [B2-devel] problems caused(?) by recent patches

[Alexei S. <ale...@gm...>]

I've reverted the SDL audio patch.

On Thu, Jan 14, 2010 at 3:06 PM, Ronald P. Regensburg
<ron...@xs...> wrote:
> In answer to the comments by Charles Srstka:
>
> About the precise timer patch:
> The crash with the precise timer crash was not limited to PPC
> machines. I noticed it myself on a PPC machine first while it did not
> happen on my Intel machine. However, within 6 days after posting my
> 18-10-2009 build I got in the SheepShaver forum four reports of the
> crash, each at the very same moment in the startup process, one on a
> PPC machine and three on a Intel machine. The 25-10-2009 build
> (without the precise timer patch) solved the crash for myself on my
> PPC machine as well as for the other reported PPC machine and for two
> out of the three reported Intel machines. On the third reported Intel
> machine the 25-10-2009 crashed with a SIGSEGV. That crash was resolved
> by enabling "Ignore Illegal Memory Accesses" (ignoresegv true). Later,
> there were a few more reports of SIGSEGV crashes on Intel machines
> with the 25-10-2009 build that could be solved this way. So far, I got
> one report of the 25-10-2009 build crashing with a SIGSEGV in Leopard
> on a PPC machine, not yet solved nor understood.
>
> About the sdl-audio patch:
> Probably best to simply remove the patch. In the original
> pre-19-02-2009 BasiliskII/src/SDL/audio_sdl.cpp file the value for
> audio_spec.samples is set to 4096, well within the recommended range.
>
> Ronald.
>
>
> Op 14 jan 2010, om 17:11 heeft Charles Srstka het volgende geschreven:
>
>> On Jan 14, 2010, at 7:18 AM, Ronald P. Regensburg wrote:
>>
>>>
>>> In Emaculation.com forums, Alexei Svitkine asked me to mail to this
>>> list about patches I needed to revert before building SheepShaver
>>> (and
>>> BasiliskII) for Mac OS X in order to avoid problems.
>>>
>>>
>>> The problems with the "precise timer patch" were discussed in the
>>> basilisk-devel list between October 23 and October 28. Those problems
>>> were the reason for me to make the 25-10-2009 build for
>>> Emaculation.com within days after the 18-10-2009 build.
>>>
>>> In my last October 25 message to the basilisk-devel list I told which
>>> files I used for the 25-10-2009 build to omit the "precise timer
>>> patch" and the "sdl-audio patch".
>>>
>>> The "sdl-audio patch" apparently made sound for most users worse
>>> rather than better. Users of both BasiliskII and SheepShaver builds
>>> created after that patch was added, complained about the problems for
>>> months and reported considerable improvement when I posted builds of
>>> both without the patch. That happened before I joined this mailing
>>> list. The problems were sound delays, stuttering, even skipping of
>>> sounds. The problem was more serious in BasiliskII than in
>>> SheepShaver.
>>>
>>> I do not know whether these patches actually cause the problems or
>>> just make bugs in other parts of the code apparent.
>>
>> The crash with the precise timer patch was mostly limited to running
>> the app on PPC machines if I remember correctly, wasn’t it? Since
>> SheepShaver runs completely different code paths on PPC and Intel,
>> with the PPC version running native code and the Intel using
>> emulation, I can see how the change could have caused problems with
>> one that would not have come up on the other. The best solution in
>> this case may be to enable the precise timer patch only when
>> building for Intel.
>>
>> The SDL audio patch, on the other hand, is simply ill-advised in my
>> opinion. The docs for SDL recommend using a value between 512 and
>> 8192 for the ‘samples’ field of an SDL_AudioSpec. The patch in the
>> SheepShaver source sets it to 16384. The result is laggy audio. I
>> think the patch was made to reduce the demands on processing power
>> for older machines, but for those with modern hardware it seems to
>> cause more problems than it solves.
>>
>> Charles
>> ------------------------------------------------------------------------------
>> Throughout its 18-year history, RSA Conference consistently attracts
>> the
>> world's best and brightest in the field, creating opportunities for
>> Conference
>> attendees to learn about information security's most important
>> issues through
>> interactions with peers, luminaries and emerging and established
>> companies.
>> http://p.sf.net/sfu/rsaconf-dev2dev
>> _______________________________________________
>> basilisk-devel mailing list
>> bas...@li...
>> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>>
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] Errors building SheepShaver and BasiliskII for Windows using Cygwin

[Alexei S. <ale...@gm...>]

I've committed changes that should fix your issues with compiling
dyngen.c. Can you verify that it now compiles properly?

As for the prefs_init()/prefs_exit() issue, I'll have to figure out
why src/dummy/prefs_dummy.cpp isn't being built/linked for your
config.

I've also committed a fix for the first Basilisk compile error you
got. Please try again and let me know the results.

Thanks!

-Alexei

On Thu, Jan 14, 2010 at 11:03 AM, howard spoelstra
<how...@ho...> wrote:
> Hi,
>
> Using SDL-1.2.14, Cygwin 1.7.1 errors occur while building both SheepShaver
> and BasiliskII. I have described the steps I take to build both executables
> and (for SheepShaver) how to work around these errors.
> Maybe someone can look into it and adjust the code?
>
> Thanks, best,
> Howard
>
> SheepShaver:
>
> cd SheepShaver
> make links
> cd src/Windows
> NO_CONFIGURE=1 ../Unix/autogen.sh
>
> ./configure leads to:
>
> (part of configure log....
> checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config)
>
> Summary:
> Enable JIT compiler .............. : yes
> GTK user interface ............... : no
>
> ./configure --disable-gtktest leads to:
>
> (part of configure log...
> checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config
> checking for GTK+ - version >= 1.3.15... yes (version 2.6.8))
>
> Summary:
> Enable JIT compiler .............. : yes
> GTK user interface ............... : yes
>
>
> $ make
> gcc -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I.
> -I../slirp -DHAVE_CONFIG_H -O2 -c ../kpx_cpu/src/cpu/jit/dyngen.c -o
> obj/dyngen.ho
> ../kpx_cpu/src/cpu/jit/dyngen.c: In function `patch_relocations'
> ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: `i' undeclared (first use in
> this function)
> ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: (Each undeclared identifier is
> reported only once
> ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: for each function it appears
> in.)
> ../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: `rel' undeclared (first use in
> this function)
> ../kpx_cpu/src/cpu/jit/dyngen.c:2178: error: `copy_size' undeclared (first
> use in this function)
> ../kpx_cpu/src/cpu/jit/dyngen.c:2179: error: `sym_name' undeclared (first
> use in this function)
> ../kpx_cpu/src/cpu/jit/dyngen.c:2180: error: `p' undeclared (first use in
> this function)
> ../kpx_cpu/src/cpu/jit/dyngen.c: In function `gen_file':
> ../kpx_cpu/src/cpu/jit/dyngen.c:2891: error: `data_sec_hdr' undeclared
> (first use in this function)
> make: *** [obj/dyngen.ho] Error 1
>
> I can solve this by using the revision 1.19 version of dyngen.c
> Next, make stumbles over:
>
> g++ -o SheepShaverGUI.exe       obj/prefs.o obj/prefs_windows.o
> obj/prefs_editor_gtk.o obj/xpram_windows.o obj/prefs_ite
> ms.o obj/user_strings.o obj/user_strings_windows.o obj/util_windows.o
> obj/packet32.o obj/SheepShaverGUI.o -lwsock32 -lip
> hlpapi -LD:/GTK/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0
> -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgo
> bject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv   -mwindows -mno-cygwin
> obj/prefs.o:prefs.cpp:(.text+0x9): undefined reference to `prefs_exit()'
> obj/prefs.o:prefs.cpp:(.text+0x624): undefined reference to `prefs_init()'
>
> This can be solved by editing BasliskII\src\prefs.cpp and removing:
> #ifdef SHEEPSHAVER
>     // System specific initialization
>     prefs_init();
> #endif
>
> and
> #ifdef SHEEPSHAVER
>     // System specific deinitialization
>     prefs_exit();
> #endif
>
> This ultimately leads to succesfull builds of both SheepShaver.exe and
> SheepShaverGUI.exe
>
>
>
> For Basilisk, using clean code from CVS again:
>
> ./configure leads to:
>
> (part of configure log...
> checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config
> checking for GTK+ - version >= 1.3.15... no)
>
> Summary:
> Use JIT compiler ....................... : yes
> JIT debug mode ......................... : no
> Floating-Point emulation core .......... : IEEE fpu core
> Assembly optimizations ................. : i386
> Addressing mode ........................ : direct
> GTK user interface ..................... : no
>
> ./configure --disable-gtktest leads to:
>
> Summary:
> Use JIT compiler ....................... : yes
> JIT debug mode ......................... : no
> Floating-Point emulation core .......... : IEEE fpu core
> Assembly optimizations ................. : i386
> Addressing mode ........................ : direct
> GTK user interface ..................... : yes
>
> make then reports (related to the recent SheepVM changes?):
> g++ -I../include -I. -I../uae_cpu -I../slirp -DHAVE_CONFIG_H
> -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE
> -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS
> -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2
> -I/home/hsp/cvs/SDL/release_1.2.14/include/SDL -I/usr/include/mingw
> -mno-cygwin -Dmain=SDL_main -c ../main.cpp -o obj/main.o
> g++ -I../include -I. -I../uae_cpu -I../slirp -DHAVE_CONFIG_H
> -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE
> -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS
> -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2
> -I/home/hsp/cvs/SDL/release_1.2.14/include/SDL -I/usr/include/mingw
> -mno-cygwin -Dmain=SDL_main -c main_windows.cpp -o obj/main_windows.o
> main_windows.cpp: In function `int SDL_main(int, char**)':
> main_windows.cpp:270: error: invalid conversion from `int' to `const char*'
> main_windows.cpp:270: error: invalid initialization of reference of type
> 'int&' from expression of type 'char**'
> ../include/prefs.h:26: error: in passing argument 2 of `void PrefsInit(const
> char*, int&, char**&)'
> make: *** [obj/main_windows.o] Error 1
>
> There will be more errors building BasiliskII, but as I'm not able to solve
> the first one, the next can't appear yet ;-)
>
>
> ________________________________
> Ontdek nu Windows phone. De smartphone van dit moment
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] problems caused(?) by recent patches

[Ronald P. R. <ron...@xs...>]

In answer to the comments by Charles Srstka:

About the precise timer patch:
The crash with the precise timer crash was not limited to PPC  
machines. I noticed it myself on a PPC machine first while it did not  
happen on my Intel machine. However, within 6 days after posting my  
18-10-2009 build I got in the SheepShaver forum four reports of the  
crash, each at the very same moment in the startup process, one on a  
PPC machine and three on a Intel machine. The 25-10-2009 build  
(without the precise timer patch) solved the crash for myself on my  
PPC machine as well as for the other reported PPC machine and for two  
out of the three reported Intel machines. On the third reported Intel  
machine the 25-10-2009 crashed with a SIGSEGV. That crash was resolved  
by enabling "Ignore Illegal Memory Accesses" (ignoresegv true). Later,  
there were a few more reports of SIGSEGV crashes on Intel machines  
with the 25-10-2009 build that could be solved this way. So far, I got  
one report of the 25-10-2009 build crashing with a SIGSEGV in Leopard  
on a PPC machine, not yet solved nor understood.

About the sdl-audio patch:
Probably best to simply remove the patch. In the original  
pre-19-02-2009 BasiliskII/src/SDL/audio_sdl.cpp file the value for  
audio_spec.samples is set to 4096, well within the recommended range.

Ronald.


Op 14 jan 2010, om 17:11 heeft Charles Srstka het volgende geschreven:

> On Jan 14, 2010, at 7:18 AM, Ronald P. Regensburg wrote:
>
>>
>> In Emaculation.com forums, Alexei Svitkine asked me to mail to this
>> list about patches I needed to revert before building SheepShaver  
>> (and
>> BasiliskII) for Mac OS X in order to avoid problems.
>>
>>
>> The problems with the "precise timer patch" were discussed in the
>> basilisk-devel list between October 23 and October 28. Those problems
>> were the reason for me to make the 25-10-2009 build for
>> Emaculation.com within days after the 18-10-2009 build.
>>
>> In my last October 25 message to the basilisk-devel list I told which
>> files I used for the 25-10-2009 build to omit the "precise timer
>> patch" and the "sdl-audio patch".
>>
>> The "sdl-audio patch" apparently made sound for most users worse
>> rather than better. Users of both BasiliskII and SheepShaver builds
>> created after that patch was added, complained about the problems for
>> months and reported considerable improvement when I posted builds of
>> both without the patch. That happened before I joined this mailing
>> list. The problems were sound delays, stuttering, even skipping of
>> sounds. The problem was more serious in BasiliskII than in  
>> SheepShaver.
>>
>> I do not know whether these patches actually cause the problems or
>> just make bugs in other parts of the code apparent.
>
> The crash with the precise timer patch was mostly limited to running  
> the app on PPC machines if I remember correctly, wasn’t it? Since  
> SheepShaver runs completely different code paths on PPC and Intel,  
> with the PPC version running native code and the Intel using  
> emulation, I can see how the change could have caused problems with  
> one that would not have come up on the other. The best solution in  
> this case may be to enable the precise timer patch only when  
> building for Intel.
>
> The SDL audio patch, on the other hand, is simply ill-advised in my  
> opinion. The docs for SDL recommend using a value between 512 and  
> 8192 for the ‘samples’ field of an SDL_AudioSpec. The patch in the  
> SheepShaver source sets it to 16384. The result is laggy audio. I  
> think the patch was made to reduce the demands on processing power  
> for older machines, but for those with modern hardware it seems to  
> cause more problems than it solves.
>
> Charles
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts  
> the
> world's best and brightest in the field, creating opportunities for  
> Conference
> attendees to learn about information security's most important  
> issues through
> interactions with peers, luminaries and emerging and established  
> companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] problems caused(?) by recent patches

[Charles S. <bas...@ch...>]

On Jan 14, 2010, at 7:18 AM, Ronald P. Regensburg wrote:

> 
> In Emaculation.com forums, Alexei Svitkine asked me to mail to this  
> list about patches I needed to revert before building SheepShaver (and  
> BasiliskII) for Mac OS X in order to avoid problems.
> 
> 
> The problems with the "precise timer patch" were discussed in the  
> basilisk-devel list between October 23 and October 28. Those problems  
> were the reason for me to make the 25-10-2009 build for  
> Emaculation.com within days after the 18-10-2009 build.
> 
> In my last October 25 message to the basilisk-devel list I told which  
> files I used for the 25-10-2009 build to omit the "precise timer  
> patch" and the "sdl-audio patch".
> 
> The "sdl-audio patch" apparently made sound for most users worse  
> rather than better. Users of both BasiliskII and SheepShaver builds  
> created after that patch was added, complained about the problems for  
> months and reported considerable improvement when I posted builds of  
> both without the patch. That happened before I joined this mailing  
> list. The problems were sound delays, stuttering, even skipping of  
> sounds. The problem was more serious in BasiliskII than in SheepShaver.
> 
> I do not know whether these patches actually cause the problems or  
> just make bugs in other parts of the code apparent.

The crash with the precise timer patch was mostly limited to running the app on PPC machines if I remember correctly, wasn’t it? Since SheepShaver runs completely different code paths on PPC and Intel, with the PPC version running native code and the Intel using emulation, I can see how the change could have caused problems with one that would not have come up on the other. The best solution in this case may be to enable the precise timer patch only when building for Intel.

The SDL audio patch, on the other hand, is simply ill-advised in my opinion. The docs for SDL recommend using a value between 512 and 8192 for the ‘samples’ field of an SDL_AudioSpec. The patch in the SheepShaver source sets it to 16384. The result is laggy audio. I think the patch was made to reduce the demands on processing power for older machines, but for those with modern hardware it seems to cause more problems than it solves.

Charles

[B2-devel] Errors building SheepShaver and BasiliskII for Windows using Cygwin

[howard s. <how...@ho...>]

Hi,

Using SDL-1.2.14, Cygwin 1.7.1 errors occur while building both SheepShaver and BasiliskII. I have described the steps I take to build both executables and (for SheepShaver) how to work around these errors.
Maybe someone can look into it and adjust the code?

Thanks, best,
Howard

SheepShaver:

cd SheepShaver 
make links
cd src/Windows
NO_CONFIGURE=1 ../Unix/autogen.sh

./configure leads to:

(part of configure log....
checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config)

Summary:
Enable JIT compiler .............. : yes
GTK user interface ............... : no

./configure --disable-gtktest leads to:

(part of configure log...
checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config
checking for GTK+ - version >= 1.3.15... yes (version 2.6.8))

Summary:
Enable JIT compiler .............. : yes
GTK user interface ............... : yes


$ make
gcc -I../kpx_cpu/include -I../kpx_cpu/src -DUSE_JIT -I../include -I. -I../slirp -DHAVE_CONFIG_H -O2 -c ../kpx_cpu/src/cpu/jit/dyngen.c -o obj/dyngen.ho
../kpx_cpu/src/cpu/jit/dyngen.c: In function `patch_relocations'
../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: `i' undeclared (first use in this function)
../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: (Each undeclared identifier is reported only once
../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: for each function it appears in.)
../kpx_cpu/src/cpu/jit/dyngen.c:2176: error: `rel' undeclared (first use in this function)
../kpx_cpu/src/cpu/jit/dyngen.c:2178: error: `copy_size' undeclared (first use in this function)
../kpx_cpu/src/cpu/jit/dyngen.c:2179: error: `sym_name' undeclared (first use in this function)
../kpx_cpu/src/cpu/jit/dyngen.c:2180: error: `p' undeclared (first use in this function)
../kpx_cpu/src/cpu/jit/dyngen.c: In function `gen_file':
../kpx_cpu/src/cpu/jit/dyngen.c:2891: error: `data_sec_hdr' undeclared (first use in this function)
make: *** [obj/dyngen.ho] Error 1

I can solve this by using the revision 1.19 version of dyngen.c
Next, make stumbles over:

g++ -o SheepShaverGUI.exe       obj/prefs.o obj/prefs_windows.o obj/prefs_editor_gtk.o obj/xpram_windows.o obj/prefs_ite
ms.o obj/user_strings.o obj/user_strings_windows.o obj/util_windows.o obj/packet32.o obj/SheepShaverGUI.o -lwsock32 -lip
hlpapi -LD:/GTK/lib -lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgo
bject-2.0 -lgmodule-2.0 -lglib-2.0 -lintl -liconv   -mwindows -mno-cygwin
obj/prefs.o:prefs.cpp:(.text+0x9): undefined reference to `prefs_exit()'
obj/prefs.o:prefs.cpp:(.text+0x624): undefined reference to `prefs_init()'

This can be solved by editing BasliskII\src\prefs.cpp and removing:
#ifdef SHEEPSHAVER
    // System specific initialization
    prefs_init();
#endif

and
#ifdef SHEEPSHAVER
    // System specific deinitialization
    prefs_exit();
#endif

This ultimately leads to succesfull builds of both SheepShaver.exe and SheepShaverGUI.exe



For Basilisk, using clean code from CVS again:

./configure leads to:

(part of configure log...
checking for pkg-config... /cygdrive/d/GTK/bin/pkg-config
checking for GTK+ - version >= 1.3.15... no)

Summary:
Use JIT compiler ....................... : yes
JIT debug mode ......................... : no
Floating-Point emulation core .......... : IEEE fpu core
Assembly optimizations ................. : i386
Addressing mode ........................ : direct
GTK user interface ..................... : no

./configure --disable-gtktest leads to:

Summary:
Use JIT compiler ....................... : yes
JIT debug mode ......................... : no
Floating-Point emulation core .......... : IEEE fpu core
Assembly optimizations ................. : i386
Addressing mode ........................ : direct
GTK user interface ..................... : yes

make then reports (related to the recent SheepVM changes?):
g++ -I../include -I. -I../uae_cpu -I../slirp -DHAVE_CONFIG_H  -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2 -I/home/hsp/cvs/SDL/release_1.2.14/include/SDL -I/usr/include/mingw -mno-cygwin -Dmain=SDL_main -c ../main.cpp -o obj/main.o
g++ -I../include -I. -I../uae_cpu -I../slirp -DHAVE_CONFIG_H  -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DREGPARAM="__attribute__((regparm(3)))" -DX86_ASSEMBLY -DOPTIMIZED_FLAGS -DSAHF_SETO_PROFITABLE -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2 -I/home/hsp/cvs/SDL/release_1.2.14/include/SDL -I/usr/include/mingw -mno-cygwin -Dmain=SDL_main -c main_windows.cpp -o obj/main_windows.o
main_windows.cpp: In function `int SDL_main(int, char**)':
main_windows.cpp:270: error: invalid conversion from `int' to `const char*'
main_windows.cpp:270: error: invalid initialization of reference of type 'int&' from expression of type 'char**'
../include/prefs.h:26: error: in passing argument 2 of `void PrefsInit(const char*, int&, char**&)'
make: *** [obj/main_windows.o] Error 1

There will be more errors building BasiliskII, but as I'm not able to solve the first one, the next can't appear yet ;-)

 		 	   		  
_________________________________________________________________
25GB gratis online harde schijf
http://skydrive.live.com

[B2-devel] problems caused(?) by recent patches

[Ronald P. R. <ron...@xs...>]

In Emaculation.com forums, Alexei Svitkine asked me to mail to this  
list about patches I needed to revert before building SheepShaver (and  
BasiliskII) for Mac OS X in order to avoid problems.


The problems with the "precise timer patch" were discussed in the  
basilisk-devel list between October 23 and October 28. Those problems  
were the reason for me to make the 25-10-2009 build for  
Emaculation.com within days after the 18-10-2009 build.

In my last October 25 message to the basilisk-devel list I told which  
files I used for the 25-10-2009 build to omit the "precise timer  
patch" and the "sdl-audio patch".

The "sdl-audio patch" apparently made sound for most users worse  
rather than better. Users of both BasiliskII and SheepShaver builds  
created after that patch was added, complained about the problems for  
months and reported considerable improvement when I posted builds of  
both without the patch. That happened before I joined this mailing  
list. The problems were sound delays, stuttering, even skipping of  
sounds. The problem was more serious in BasiliskII than in SheepShaver.

I do not know whether these patches actually cause the problems or  
just make bugs in other parts of the code apparent.

I did not yet try to make new builds after the patch for Snow Leopard  
x86_64 compatibility by Jean-Pierre Chombier were added. I do not have  
Snow Leopard installed yet. Jean-Pierre Chombier also posted test  
builds with SDL 1.2.14 that used the "hardware cursor" (before only  
possible with SDL 1.2.10), but again with the sdl-audio patch and thus  
with again the sound problems.

He built with SDL.Framework in the SheepShaver.app package, while my  
builds have so far been with sdl static (makes a smaller application).


Ronald.

Re: [B2-devel] Fwd: [PATCH] SheepShaver, Mac OS X, and NSAutoreleasePool

[Tim D. <ti...@gm...>]

A fresh checkout works perfectly. Thanks again!

-T

On Sat, Jan 2, 2010 at 5:09 PM, Alexei Svitkine
<ale...@gm...>wrote:

> Committed. Thanks.
>
> -Alexei

Re: [B2-devel] Fwd: [PATCH] SheepShaver, Mac OS X, and NSAutoreleasePool

[Alexei S. <ale...@gm...>]

Committed. Thanks.

-Alexei

On Sat, Jan 2, 2010 at 4:18 PM, Tim Douglas <ti...@gm...> wrote:
> Hey Alexei,
> Thanks for the commit, but the error messages appear to come from
> prefs_init(), not openPreferences:
> (gdb) break _NSAutoreleaseNoPool
> Breakpoint 1 at 0xa24af16
> (gdb) run --frameskip 0 --ramsize 268435456 --ignoresegv true
> --ignoreillegal true --ether slirp --idlewait true --keycodes true
> --keycodefile keycodes --frameskip 0 --rom Mac\ OS\ ROM --disk
> harddrive9.img
> Starting program: /Users/timdoug/Desktop/ss/SheepShaver/src/Unix/SheepShaver
> --frameskip 0 --ramsize 268435456 --ignoresegv true --ignoreillegal true
> --ether slirp --idlewait true --keycodes true --keycodefile keycodes
> --frameskip 0 --rom Mac\ OS\ ROM --disk harddrive9.img
> Reading symbols for shared libraries
> +++++++++++++++++..........................................................................
> done
> Breakpoint 1 at 0x92b65f16
> SheepShaver V2.3 by Christian Bauer and Mar"c" Hellwig
> Breakpoint 1, 0x92b65f16 in _NSAutoreleaseNoPool ()
> (gdb) bt
> #0  0x92b65f16 in _NSAutoreleaseNoPool ()
> #1  0x92a73637 in +[NSPathStore2 pathStoreWithCharacters:length:] ()
> #2  0x92a7feb7 in -[NSString(NSPathUtilities) stringByDeletingPathExtension]
> ()
> #3  0x957c7fa3 in +[NSImage imageNamed:] ()
> #4  0x957f2e6d in -[NSMenuItem initWithTitle:action:keyEquivalent:] ()
> #5  0x78072352 in prefs_init () at ../MacOSX/prefs_macosx.mm:105
> #6  0x7804a29f in main (argc=1, argv=0xbffff5c4) at main_unix.cpp:485
> (gdb) ...
> The following seven breakpoints are also triggered in prefs_init(). Moving
> the allocation and deallocation to that function from openPreferences
> appears to fix 'em (see attached).
> Thanks,
> -Tim
> On Sat, Jan 2, 2010 at 2:26 PM, Alexei Svitkine <ale...@gm...>
> wrote:
>>
>> Hi Tim,
>>
>> I've committed a change that creates and releases the pool around the
>> call to the modal prefs dialog only. Can you verify that this gets rid
>> of the messages?
>>
>> -Alexei
>>
>> On Sat, Jan 2, 2010 at 4:27 AM, Christian Bauer <cb...@ce...> wrote:
>> > I'm no Objective C or Cocoa master either... :)
>> >
>> > -------- Original Message --------
>> > Subject: [PATCH] SheepShaver, Mac OS X, and NSAutoreleasePool
>> > Date: Fri, 1 Jan 2010 16:07:45 -0500
>> > From: Tim Douglas <ti...@gm...>
>> > To: cb...@ce...
>> >
>> > Mr. Bauer,
>> >
>> > Thanks so much for the development of SheepShaver. It's wonderful
>> > reliving
>> > memories of Mac OSs past on my shiny Core 2 MacBook Pro. When compiling
>> > the
>> > source from CVS and running it on Mac OS X 10.5.8, I receive these
>> > messages
>> > on stderr:
>> >
>> > 2010-01-01 16:02:08.421 SheepShaver[11638:10b] ***
>> > _NSAutoreleaseNoPool():
>> > Object 0x30d800 of class NSPathStore2 autoreleased with no pool in place
>> > -
>> > just leaking
>> > Stack: (0x92b65f4f 0x92a73637 0x92a7feb7 0x957c7fa3 0x957f2e6d
>> > 0x78072372
>> > 0x7804a29f 0x78049066)
>> > 2010-01-01 16:02:08.423 SheepShaver[11638:10b] ***
>> > _NSAutoreleaseNoPool():
>> > Object 0x314490 of class NSCFData autoreleased with no pool in place -
>> > just
>> > leaking
>> > Stack: (0x92b65f4f 0x92a72432 0x92a86b25 0x92a86701 0x957c8280
>> > 0x957c8161
>> > 0x957c7fdf 0x957f2e6d 0x78072372 0x7804a29f 0x78049066)
>> > 2010-01-01 16:02:08.430 SheepShaver[11638:10b] ***
>> > _NSAutoreleaseNoPool():
>> > Object 0xa08a0fa0 of class NSCFString autoreleased with no pool in place
>> > -
>> > just leaking
>> > Stack: (0x92b65f4f 0x92a72432 0x957c8161 0x957c7fdf 0x957f2e6d
>> > 0x78072372
>> > 0x7804a29f 0x78049066)
>> >
>> > ...and five more similar ones. It appears as if Cocoa APIs are being
>> > used
>> > without an NSAutoreleasePool in place. The attached CVS diff appears to
>> > fix
>> > the issue by establishing the appropriate pool before the calls are
>> > made. I'm no Objective C or Cocoa master, nor do I have that strong of a
>> > grasp of the internal workings of SheepShaver, but presumably something
>> > along these lines is all that's needed.
>> >
>> > Thanks again for the great emulator!
>> > -Tim
>> >
>> > ---------cut here---------
>> >
>> > Index: src/MacOSX/prefs_macosx.mm
>> > ===================================================================
>> > RCS file: /home/cvs/cebix/SheepShaver/src/MacOSX/prefs_macosx.mm,v
>> > retrieving revision 1.2
>> > diff -u -r1.2 prefs_macosx.mm
>> > --- src/MacOSX/prefs_macosx.mm 18 Aug 2009 18:22:01 -0000 1.2
>> > +++ src/MacOSX/prefs_macosx.mm 1 Jan 2010 20:56:08 -0000
>> > @@ -30,6 +30,7 @@
>> >  @interface SheepShaverMain : NSObject
>> >  NSArray *nibObjects;
>> >  NSWindow *prefsWindow;
>> > + NSAutoreleasePool *pool;
>> >  @end
>> >
>> >  @implementation SheepShaverMain
>> > @@ -97,6 +98,7 @@
>> >  NSMenu *appMenu;
>> >  NSMenuItem *menuItem;
>> >
>> > + pool = [[NSAutoreleasePool alloc] init];
>> >  appMenu = [[[NSApp mainMenu] itemAtIndex:0] submenu];
>> >  menuItem = [[NSMenuItem alloc] initWithTitle:@"Preferences..."
>> > action:@selector(openPreferences:) keyEquivalent:@","];
>> >  [appMenu insertItem:menuItem atIndex:2];
>> > @@ -113,4 +115,5 @@
>> >
>> >  void prefs_exit(void)
>> >  {
>> > + [pool release];
>> >  }
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > This SF.Net email is sponsored by the Verizon Developer Community
>> > Take advantage of Verizon's best-in-class app development support
>> > A streamlined, 14 day to market process makes app distribution fast and
>> > easy
>> > Join now and get one step closer to millions of Verizon customers
>> > http://p.sf.net/sfu/verizon-dev2dev
>> > _______________________________________________
>> > basilisk-devel mailing list
>> > bas...@li...
>> > https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>> >
>> >
>
>

Re: [B2-devel] Fwd: [PATCH] SheepShaver, Mac OS X, and NSAutoreleasePool

[Alexei S. <ale...@gm...>]

Hi Tim,

I've committed a change that creates and releases the pool around the
call to the modal prefs dialog only. Can you verify that this gets rid
of the messages?

-Alexei

On Sat, Jan 2, 2010 at 4:27 AM, Christian Bauer <cb...@ce...> wrote:
> I'm no Objective C or Cocoa master either... :)
>
> -------- Original Message --------
> Subject: [PATCH] SheepShaver, Mac OS X, and NSAutoreleasePool
> Date: Fri, 1 Jan 2010 16:07:45 -0500
> From: Tim Douglas <ti...@gm...>
> To: cb...@ce...
>
> Mr. Bauer,
>
> Thanks so much for the development of SheepShaver. It's wonderful reliving
> memories of Mac OSs past on my shiny Core 2 MacBook Pro. When compiling the
> source from CVS and running it on Mac OS X 10.5.8, I receive these messages
> on stderr:
>
> 2010-01-01 16:02:08.421 SheepShaver[11638:10b] *** _NSAutoreleaseNoPool():
> Object 0x30d800 of class NSPathStore2 autoreleased with no pool in place -
> just leaking
> Stack: (0x92b65f4f 0x92a73637 0x92a7feb7 0x957c7fa3 0x957f2e6d 0x78072372
> 0x7804a29f 0x78049066)
> 2010-01-01 16:02:08.423 SheepShaver[11638:10b] *** _NSAutoreleaseNoPool():
> Object 0x314490 of class NSCFData autoreleased with no pool in place - just
> leaking
> Stack: (0x92b65f4f 0x92a72432 0x92a86b25 0x92a86701 0x957c8280 0x957c8161
> 0x957c7fdf 0x957f2e6d 0x78072372 0x7804a29f 0x78049066)
> 2010-01-01 16:02:08.430 SheepShaver[11638:10b] *** _NSAutoreleaseNoPool():
> Object 0xa08a0fa0 of class NSCFString autoreleased with no pool in place -
> just leaking
> Stack: (0x92b65f4f 0x92a72432 0x957c8161 0x957c7fdf 0x957f2e6d 0x78072372
> 0x7804a29f 0x78049066)
>
> ...and five more similar ones. It appears as if Cocoa APIs are being used
> without an NSAutoreleasePool in place. The attached CVS diff appears to fix
> the issue by establishing the appropriate pool before the calls are
> made. I'm no Objective C or Cocoa master, nor do I have that strong of a
> grasp of the internal workings of SheepShaver, but presumably something
> along these lines is all that's needed.
>
> Thanks again for the great emulator!
> -Tim
>
> ---------cut here---------
>
> Index: src/MacOSX/prefs_macosx.mm
> ===================================================================
> RCS file: /home/cvs/cebix/SheepShaver/src/MacOSX/prefs_macosx.mm,v
> retrieving revision 1.2
> diff -u -r1.2 prefs_macosx.mm
> --- src/MacOSX/prefs_macosx.mm 18 Aug 2009 18:22:01 -0000 1.2
> +++ src/MacOSX/prefs_macosx.mm 1 Jan 2010 20:56:08 -0000
> @@ -30,6 +30,7 @@
>  @interface SheepShaverMain : NSObject
>  NSArray *nibObjects;
>  NSWindow *prefsWindow;
> + NSAutoreleasePool *pool;
>  @end
>
>  @implementation SheepShaverMain
> @@ -97,6 +98,7 @@
>  NSMenu *appMenu;
>  NSMenuItem *menuItem;
>
> + pool = [[NSAutoreleasePool alloc] init];
>  appMenu = [[[NSApp mainMenu] itemAtIndex:0] submenu];
>  menuItem = [[NSMenuItem alloc] initWithTitle:@"Preferences..."
> action:@selector(openPreferences:) keyEquivalent:@","];
>  [appMenu insertItem:menuItem atIndex:2];
> @@ -113,4 +115,5 @@
>
>  void prefs_exit(void)
>  {
> + [pool release];
>  }
>
>
> ------------------------------------------------------------------------------
> This SF.Net email is sponsored by the Verizon Developer Community
> Take advantage of Verizon's best-in-class app development support
> A streamlined, 14 day to market process makes app distribution fast and easy
> Join now and get one step closer to millions of Verizon customers
> http://p.sf.net/sfu/verizon-dev2dev
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

[B2-devel] Fwd: [PATCH] SheepShaver, Mac OS X, and NSAutoreleasePool

[Christian B. <cb...@ce...>]

I'm no Objective C or Cocoa master either... :)

-------- Original Message --------
Subject: [PATCH] SheepShaver, Mac OS X, and NSAutoreleasePool
Date: Fri, 1 Jan 2010 16:07:45 -0500
From: Tim Douglas <ti...@gm...>
To: cb...@ce...

Mr. Bauer,

Thanks so much for the development of SheepShaver. It's wonderful reliving
memories of Mac OSs past on my shiny Core 2 MacBook Pro. When compiling the
source from CVS and running it on Mac OS X 10.5.8, I receive these messages
on stderr:

2010-01-01 16:02:08.421 SheepShaver[11638:10b] *** _NSAutoreleaseNoPool():
Object 0x30d800 of class NSPathStore2 autoreleased with no pool in place -
just leaking
Stack: (0x92b65f4f 0x92a73637 0x92a7feb7 0x957c7fa3 0x957f2e6d 0x78072372
0x7804a29f 0x78049066)
2010-01-01 16:02:08.423 SheepShaver[11638:10b] *** _NSAutoreleaseNoPool():
Object 0x314490 of class NSCFData autoreleased with no pool in place - just
leaking
Stack: (0x92b65f4f 0x92a72432 0x92a86b25 0x92a86701 0x957c8280 0x957c8161
0x957c7fdf 0x957f2e6d 0x78072372 0x7804a29f 0x78049066)
2010-01-01 16:02:08.430 SheepShaver[11638:10b] *** _NSAutoreleaseNoPool():
Object 0xa08a0fa0 of class NSCFString autoreleased with no pool in place -
just leaking
Stack: (0x92b65f4f 0x92a72432 0x957c8161 0x957c7fdf 0x957f2e6d 0x78072372
0x7804a29f 0x78049066)

...and five more similar ones. It appears as if Cocoa APIs are being used
without an NSAutoreleasePool in place. The attached CVS diff appears to fix
the issue by establishing the appropriate pool before the calls are
made. I'm no Objective C or Cocoa master, nor do I have that strong of a
grasp of the internal workings of SheepShaver, but presumably something
along these lines is all that's needed.

Thanks again for the great emulator!
-Tim

---------cut here---------

Index: src/MacOSX/prefs_macosx.mm
===================================================================
RCS file: /home/cvs/cebix/SheepShaver/src/MacOSX/prefs_macosx.mm,v
retrieving revision 1.2
diff -u -r1.2 prefs_macosx.mm
--- src/MacOSX/prefs_macosx.mm 18 Aug 2009 18:22:01 -0000 1.2
+++ src/MacOSX/prefs_macosx.mm 1 Jan 2010 20:56:08 -0000
@@ -30,6 +30,7 @@
  @interface SheepShaverMain : NSObject
   NSArray *nibObjects;
   NSWindow *prefsWindow;
+ NSAutoreleasePool *pool;
  @end

  @implementation SheepShaverMain
@@ -97,6 +98,7 @@
   NSMenu *appMenu;
   NSMenuItem *menuItem;

+ pool = [[NSAutoreleasePool alloc] init];
   appMenu = [[[NSApp mainMenu] itemAtIndex:0] submenu];
   menuItem = [[NSMenuItem alloc] initWithTitle:@"Preferences..."
action:@selector(openPreferences:) keyEquivalent:@","];
   [appMenu insertItem:menuItem atIndex:2];
@@ -113,4 +115,5 @@

  void prefs_exit(void)
  {
+ [pool release];
  }

Re: [B2-devel] dyngen.c patch for mach-o x86_64

[Alexei S. <ale...@gm...>]

Committed fix for the variable name mismatch.

-Alexei

On Fri, Nov 13, 2009 at 3:06 AM, Jean-Pierre <cho...@fr...> wrote:
>
> Le 13 nov. 2009 à 02:58, Alexei Svitkine a écrit :
>
>> Committed with the formatting changes. In the future, please try to
>> avoid mixing tabs and spaces.
>
> Well, my editor is set up for Python, for which tabs are not a good idea.
>
> I left a bug in dyngen.c, there's a variable declared "local16", but  "local" is used instead.
>
> Best regards,
>
>  - Jean-Pierre.
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>

Re: [B2-devel] dyngen.c patch for mach-o x86_64

[Jean-Pierre <cho...@fr...>]

Le 13 nov. 2009 à 02:58, Alexei Svitkine a écrit :

> Committed with the formatting changes. In the future, please try to
> avoid mixing tabs and spaces.

Well, my editor is set up for Python, for which tabs are not a good idea.

I left a bug in dyngen.c, there's a variable declared "local16", but  "local" is used instead.

Best regards,

 - Jean-Pierre.

Re: [B2-devel] dyngen.c patch for mach-o x86_64

[Alexei S. <ale...@gm...>]

Committed with the formatting changes. In the future, please try to
avoid mixing tabs and spaces.

Thanks.

-Alexei

On Thu, Nov 12, 2009 at 4:52 AM, Jean-Pierre <cho...@fr...> wrote:
> Hi Alexei,
>
> Here's one more patch for lowmem.c to complete the x86_64 changes, as the previous version couldn't deal with 64-bit binaries.
>
> Best regards,
>
>  - Jean-Pierre.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] dyngen.c patch for mach-o x86_64

[Jean-Pierre <cho...@fr...>]

Hi Alexei,

Here's one more patch for lowmem.c to complete the x86_64 changes, as the previous version couldn't deal with 64-bit binaries.

Best regards,

 - Jean-Pierre.

Re: [B2-devel] dyngen.c patch for mach-o x86_64

[Jean-Pierre <cho...@fr...>]

Hi Alexei,

Le 11 nov. 2009 à 20:52, Alexei Svitkine a écrit :

> Hi Jean-Pierre,
> 
> I've committed a previous version of your patch with some modifications.
> 
> Please patch your latest changes into the current version in CVS and
> re-send the patch.

Here it is.

Best regards,

 - Jean-Pierre.

[B2-devel] clip_macosx.cpp patch for x86_64

[Jean-Pierre <cho...@fr...>]

Hi again Alexei,

Le 11 nov. 2009 à 20:52, Alexei Svitkine a écrit :

> Also, you should send the other patches to this list as separate
> threads and we can discuss them if necessary.

Here's a patch for clip_macosx.cpp to use the new PasteBoard functions instead of the Scrap.
I didn't find a way to convert the 'styl' resource which is lost for now...
It also adds an attempt to convert text to/from utf-16 between hosts using the current text encoding on the Mac  - untested.

Best regards,

- Jean-Pierre.

Re: [B2-devel] dyngen.c patch for mach-o x86_64

[Alexei S. <ale...@gm...>]

Hi Jean-Pierre,

I've committed a previous version of your patch with some modifications.

Please patch your latest changes into the current version in CVS and
re-send the patch.

Also, you should send the other patches to this list as separate
threads and we can discuss them if necessary.

Thanks.

-Alexei

On Tue, Nov 3, 2009 at 6:26 AM, Jean-Pierre <cho...@fr...> wrote:
> Hi,
>
> I continue my monologue...
>
> Here's a more complete patch for dyngen.c.
> This version correctly deals with mach-o 64-bit object files built by
> gcc-4.2.1 as well as gcc-4.0.
>
> Note that there's actually a bug in Apple's gcc 4.2.1 which seems to ignore
> the -fomit-frame-pointer for 64 bit x86_64 code.
> i.e.:
>
> With gcc-4.0, the following tiny source code:
>
>        // tst.cpp
>        register unsigned int *A0 asm("ebx");
>
>        void op_mov_ad_A0_im(void)
>        {
>                asm volatile ("movabsq $___op_A0,%0" : "=r" (A0));
>        }
>
> compiled using:
>
>        gcc-4.0 -arch x86_64 -fomit-frame-pointer -c tst.cpp
>
> produces this otool result:
>
>        tst.o:
>        (__TEXT,__text) section
>        __Z15op_mov_ad_A0_imv:
>        0000000000000000        movq    $0x0000000000000000,%rbx
>        000000000000000a        ret
>
> But when compiled using gcc-4.2.1 from Snow Leopard:
>
>        gcc -arch x86_64 -fomit-frame-pointer -c tst.cpp
>
> produces this otool result:
>
>        tst.o:
>        (__TEXT,__text) section
>        __Z15op_mov_ad_A0_imv:
>        0000000000000000        pushq   %rbx
>        0000000000000001        movq    $0x0000000000000000,%rbx
>        000000000000000b        popq    %rbx
>        000000000000000c        ret
>
> my gcc version: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build
> 5646) (dot 1)
>
> I filed a bug at Apple about this.
>
> I also have a few other patches available:
> One for clip_macosx.cpp to deal with ne new Pasteboard functions since
> GetCurrentScrap/PutScrapFlavor etc.. have disappeared in Snow Leopard's
> APIs.
> One for video_blit.cpp to accept the new GBRA format returned by the latest
> SLD-1.2.14, and a patch for this SDL to remove a memory leak (bug filed at
> libsdl.org).
> Let me know if you want them or if you don't care...
>
> Regards,
>
>  - Jean-Pierre.
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
> trial. Simplify your report design, integration and deployment - and focus
> on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

Re: [B2-devel] x86_64 Mach-O dyngen patch

[Alexei S. <ale...@gm...>]

Committed with a little bit of formatting cleanup.

-Alexei

On Tue, Oct 27, 2009 at 5:33 PM, Jean-Pierre <cho...@fr...> wrote:
> Hi,
> Le 25 oct. 2009 à 23:37, Jean-Pierre a écrit :
>
> Here's a dyngen patch for Snow Leopard x86_64 compatibility. This work is
> mostly based on the unofficial and incomplete x86_64 mach-o patch of qemu.
> The JIT compiler seems to be ok in 64 bit mode, since I have the 'happy mac'
> at boot time, but the application crashes later...
>
> When cleaning the dyngen code, I broke the x86_64 ELF part, It won't compile
> because of the lines 2283-2285:
>                     if (rel->r_offset >= start_offset &&
>                         int slide;
>                         rel->r_offset < start_offset + copy_size) {
> that should be:
>                     if (rel->r_offset >= start_offset &&
>                         rel->r_offset < start_offset + copy_size) {
>                         int slide;
> Sorry about this.
> The JIT compiler still crashes when using the code generated by Apple's gcc
> on ppc-dyngen-ops.cpp.
> I'm not sure why the resulting assembly code is so different from a Linux
> 64-bit gcc install. I used otool on Mac and dumpobj on Linux to compare
> these, and many functions are using different opcodes.
> if I replace the ppc-dyngen-ops.hpp file by one built on a Linux 64-bit
> machine, then SheepShaver runs fine in 64-bit mode with the JIT compiler on
> Snow Leopard.
> Best regards,
>  - Jean-Pierre.
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> basilisk-devel mailing list
> bas...@li...
> https://lists.sourceforge.net/lists/listinfo/basilisk-devel
>
>

[B2-devel] dyngen.c patch for mach-o x86_64

[Jean-Pierre <cho...@fr...>]

Hi,

I continue my monologue...

Here's a more complete patch for dyngen.c.
This version correctly deals with mach-o 64-bit object files built by  
gcc-4.2.1 as well as gcc-4.0.

Note that there's actually a bug in Apple's gcc 4.2.1 which seems to  
ignore the -fomit-frame-pointer for 64 bit x86_64 code.
i.e.:

With gcc-4.0, the following tiny source code:

	// tst.cpp
	register unsigned int *A0 asm("ebx");
	
	void op_mov_ad_A0_im(void)
	{
		asm volatile ("movabsq $___op_A0,%0" : "=r" (A0));
	}

compiled using:

	gcc-4.0 -arch x86_64 -fomit-frame-pointer -c tst.cpp

produces this otool result:

	tst.o:
	(__TEXT,__text) section
	__Z15op_mov_ad_A0_imv:
	0000000000000000	movq	$0x0000000000000000,%rbx
	000000000000000a	ret

But when compiled using gcc-4.2.1 from Snow Leopard:

	gcc -arch x86_64 -fomit-frame-pointer -c tst.cpp

produces this otool result:

	tst.o:
	(__TEXT,__text) section
	__Z15op_mov_ad_A0_imv:
	0000000000000000	pushq	%rbx
	0000000000000001	movq	$0x0000000000000000,%rbx
	000000000000000b	popq	%rbx
	000000000000000c	ret

my gcc version: i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc.  
build 5646) (dot 1)

I filed a bug at Apple about this.

I also have a few other patches available:
One for clip_macosx.cpp to deal with ne new Pasteboard functions since  
GetCurrentScrap/PutScrapFlavor etc.. have disappeared in Snow  
Leopard's APIs.
One for video_blit.cpp to accept the new GBRA format returned by the  
latest SLD-1.2.14, and a patch for this SDL to remove a memory leak  
(bug filed at libsdl.org).
Let me know if you want them or if you don't care...

Regards,

  - Jean-Pierre.