gxemul-users — Mailing list for user questions regarding GXemul

Re: [GXemul-users] problem with command line switches

[Anders G. <ga...@gm...>]

Lör 2010-04-03 klockan 15:20 +0100 skrev Edwin Rhodes:
> Hello just compiled ver 0.6.0 and it does not support the –X command
> line option trying to run ULTRIX with X Windows
> 
> Ultrix is installed ok but does not do x as the graphics –X command
> does not work. Running the emulator under fedora 12 linux
> 
> Is there a compile switch that is wrong?

What was the output of the ./configure script? It should say something
similar to:

...
checking for X11 headers and libs
X11 headers: -I/usr/X11R6/include
X11 libraries: -L/usr/X11R6/lib -lX11
...

or /usr/local/... depending on where your X11 installation is located.


Anders

[GXemul-users] problem with command line switches

[Edwin R. <edw...@ho...>]

Hello just compiled ver 0.6.0 and it does not support the -X command line
option trying to run ULTRIX with X Windows

Ultrix is installed ok but does not do x as the graphics -X command does not
work. Running the emulator under fedora 12 linux

Is there a compile switch that is wrong?

Please advise me

Thanks ed.

 

Re: [GXemul-users] Compilation Error

[Anders G. <ga...@gm...>]

> > If you add the -Winline flag to detect whenever things are inlined
> > beyond the default limits, you should probably also add necessary flags
> > to increase those limits.
> >
> > CXXFLAGS="-Winline --param max-inline-insns-single=XXXXX --param
> > large-function-growth=YYYYY --param
> > inline-unit-growth=ZZZZZ" ./configure
> >   
> Ok - thanks, I'll play around with that.

I added -Wcast-qual and -Wshadow to the configure script, and fixed the
places in the code where GCC complained. (SVN revisions 5724 and 5725.)


Anders

Re: [GXemul-users] NetBSD/Arc

[Anders G. <ga...@gm...>]

Mån 2010-03-22 klockan 21:39 +0000 skrev Nigel Horne:
> Anders,
> 
> Does network emulation work on NetBSD/Arc?  It sees an sn0 interface, 

Sorry, no. dev_sn.cc is a dummy placeholder.


Anders

[GXemul-users] NetBSD/Arc

[Nigel H. <nj...@ba...>]

Anders,

Does network emulation work on NetBSD/Arc?  It sees an sn0 interface, 
but when I try to enable it by setting dhclient=YES in /etc/rc.conf and 
rebooting, the DHCP requests fail, and I see lots of

[ sn: unimplemented read from address 0x0 (regnr 0) ]

messages.

-Nigel

Re: [GXemul-users] Compilation Error

[Nigel H. <nj...@ba...>]

>
> If you add the -Winline flag to detect whenever things are inlined
> beyond the default limits, you should probably also add necessary flags
> to increase those limits.
>
> CXXFLAGS="-Winline --param max-inline-insns-single=XXXXX --param
> large-function-growth=YYYYY --param
> inline-unit-growth=ZZZZZ" ./configure
>   
Ok - thanks, I'll play around with that.
> or similar.
>
>
> Anders
>
>   
-Nigel

Re: [GXemul-users] Compilation Error

[Anders G. <ga...@gm...>]

Lör 2010-03-20 klockan 15:33 +0000 skrev Nigel Horne:
...
> ...
> c++ -Wstrict-aliasing -Wall -Werror -fno-rtti -fstrict-aliasing
...
> -Wfloat-equal -Wformat-nonliteral -Winline -Wpointer-arith -Wundef 
> -D_GLIBCXX_PARALLEL -fopenmp -c -o GXemul.o GXemul.cc
> cc1plus: warnings being treated as errors
> ../include/refcount_ptr.h: In member function ‘void GXemul::InitUI()’:
> ../include/refcount_ptr.h:141: error: inlining failed in call to 
> ‘refcount_ptr<T>::~refcount_ptr() [with T = UI]’: --param 
> inline-unit-growth limit reached
> GXemul.cc:548: error: called from here
> 
> It goes away without the -Werror, but I thought you'd like to know about it.

If you add the -Winline flag to detect whenever things are inlined
beyond the default limits, you should probably also add necessary flags
to increase those limits.

CXXFLAGS="-Winline --param max-inline-insns-single=XXXXX --param
large-function-growth=YYYYY --param
inline-unit-growth=ZZZZZ" ./configure

or similar.


Anders

[GXemul-users] Compilation Error

[Nigel H. <nj...@ba...>]

Anders,

I have the following compilation error using the latest version from SVN:

...
c++ -Wstrict-aliasing -Wall -Werror -fno-rtti -fstrict-aliasing 
-fomit-frame-pointer -fpeephole -O3 -DNDEBUG -D__STDC_FORMAT_MACROS 
-I../include/ -O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings 
-Wuninitialized -Wall -pipe -mtune=core2 -march=core2 
-fomit-frame-pointer -ffast-math -msse2 -msse -mmmx -mfpmath=sse 
-D_FORTIFY_SOURCE=2 -Wpointer-arith -fstack-protector -Wstack-protector 
-Wextra -Wcast-align -Wcast-qual -Wdisabled-optimization -Wendif-labels 
-Wfloat-equal -Wformat-nonliteral -Winline -Wpointer-arith -Wundef 
-D_GLIBCXX_PARALLEL -fopenmp -c -o GXemul.o GXemul.cc
cc1plus: warnings being treated as errors
../include/refcount_ptr.h: In member function ‘void GXemul::InitUI()’:
../include/refcount_ptr.h:141: error: inlining failed in call to 
‘refcount_ptr<T>::~refcount_ptr() [with T = UI]’: --param 
inline-unit-growth limit reached
GXemul.cc:548: error: called from here

It goes away without the -Werror, but I thought you'd like to know about it.

Best,

-Nigel

-- 
Nigel Horne. Arranger, Adjudicator, Band Trainer, Composer, Tutor, Typesetter.
NJH Music, ICQ#20252325
nj...@ba... http://www.bandsman.co.uk

[GXemul-users] Running RTEMS on MVME2100 or MVME5500

[Joel S. <joe...@oa...>]

Hi,

I am the maintainer of RTEMS and would like to
be able to test our MVME2100 and MVME5500 support
on gxemul.  But the current svn trunk aborted
with internal issues.  Is there someone who
wouldn't mind doing the gxemul side of getting
RTEMS to run on this.

Thanks.

-- 
Joel Sherrill, Ph.D.             Director of Research&  Development
joe...@OA...        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985

[GXemul-users] GXemul 0.6.0 has been released

[Anders G. <ga...@gm...>]

GXemul 0.6.0 has been released, 2010-02-14.

The main change between release 0.4.7.2 and 0.6.0 is:

    * Since late 2007, a complete rewrite of the emulator's base
      framework has been going on. GXemul 0.6.0 is a very early
      release of the new framework. So far, only the testm88k machine
      mode has been rewritten to use the new framework, all other
      machine modes run in legacy mode using the old framework (which
      is still included). 
        
      In other words: For most emulation modes, 0.6.0 will be exactly
      like 0.4.7.2. 
        
      The new testm88k mode is much less complete than the old
      testm88k; the reason for concentrating on this mode is to be
      able to make an initial release of the new framework within a
      reasonable time frame. 
        
      Compared to the other emulation modes, there are lots of things
      left to do before the new framework can be considered working:
      There are no lookup tables for fast loads/stores, no fast
      pc-to-pointer lookups, no interrupt/trap/exception handling, no
      timers, no breakpoint support, no general expression parsing, no
      I/O (serial controllers nor graphical output handlers), no disk
      or ethernet support, no MMU/virtual memory translation, and
      snapshotting (for reverse debugging) isn't implemented yet.
      Still, it is probably better to make many smaller releases
      (0.6.x) than to wait until everything is in place. 
        
      There is also a (bogus) testmips machine which will be
      implemented using the new framework. To use the old testmips
      machine, please use the name oldtestmips instead.

In addition to the new framework, a couple of other changes are worth
mentioning:

    * Many unused, rarely used, and bogus emulation modes and features
      were removed, to reduce the maintenance burden. 
        
    * Some operating systems listed on the guest OS page have had new
      releases; the documentation has been updated to reflect this. 
        
    * New source code (but not the legacy part) is documented using
      Doxygen comments, and there is a unit testing framework in
      place. 
        
    * There is now finally an install Makefile target, and the -j make
      option can be used to parallelize builds. 


The idea is to make a quick release now, even though nothing really
works, and make many small releases during development of the new
framework.


Release notes:
http://gxemul.sourceforge.net/gxemul-stable/doc/RELEASE.html

Download:
http://gxemul.sourceforge.net/download.html


Anders

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Anders Gavare wrote:
>
>
> On a closer look, it seems that the configure script ignored LDFLAGS.
> Building a file with just plain make seems to make use of LDFLAGS:
>
> $ make hi
> c++ -O2 -fno-strict-aliasing -pipe  hi.cc  -o hi
> $ rm hi
>
> $ CXXLINK=apa make hi
> c++ -O2 -fno-strict-aliasing -pipe  hi.cc  -o hi
> $ rm hi
>
> $ LDFLAGS=apa make hi
> c++ -O2 -fno-strict-aliasing -pipe apa hi.cc  -o hi
> c++: apa: No such file or directory
> *** Error code 1
>
> (As seen above, I also tried CXXLINK, but that wasn't used.)
>
> So, if you feel like trying SVN revision 5617, then it should work as
> long as your LDFLAGS contains -lgomp.
>
> http://gxemul.svn.sourceforge.net/viewvc/gxemul/gxemul/trunk/configure?r1=5552&r2=5617
>   

I've updated and run configure, but I don't know that it works yet:

njh@packard:~/src/gxemul$ echo $LDFLAGS
-lgomp
njh@packard:~/src/gxemul$ fgrep lgomp Makefile
njh@packard:~/src/gxemul$

-Nigel

Re: [GXemul-users] Errors with SVN

[Anders G. <ga...@gm...>]

Ons 2009-08-19 klockan 20:40 +0200 skrev Anders Gavare:
> > Perhaps you can modify configure to add -lgomp if needed?
>
> That could be one way. However, there must be a reason why
> -D_GLIBCXX_PARALLEL is set in your CXXFLAGS. The place where that flag
> is set should probably also have added -lgomp.
> 
> Is that a default Debian flag, or something which was added some other
> way to your CXXFLAGS? Is there maybe a separate LDFLAGS but for C++? (Is
> -lgomp in your LDFLAGS perhaps, and GXemul's configure ignores it?)

On a closer look, it seems that the configure script ignored LDFLAGS.
Building a file with just plain make seems to make use of LDFLAGS:

$ make hi
c++ -O2 -fno-strict-aliasing -pipe  hi.cc  -o hi
$ rm hi

$ CXXLINK=apa make hi
c++ -O2 -fno-strict-aliasing -pipe  hi.cc  -o hi
$ rm hi

$ LDFLAGS=apa make hi
c++ -O2 -fno-strict-aliasing -pipe apa hi.cc  -o hi
c++: apa: No such file or directory
*** Error code 1

(As seen above, I also tried CXXLINK, but that wasn't used.)

So, if you feel like trying SVN revision 5617, then it should work as
long as your LDFLAGS contains -lgomp.

http://gxemul.svn.sourceforge.net/viewvc/gxemul/gxemul/trunk/configure?r1=5552&r2=5617


Anders

Re: [GXemul-users] Errors with SVN

[Anders G. <ga...@gm...>]

Ons 2009-08-19 klockan 15:46 +0100 skrev Nigel Horne:
> Andreas,
> 
> It's working! My guests are cats, decstation and pmax.  I don't know if 
> there is any impact on performance, but at least all is well.

All those modes are legacy modes, using the old C parts of the code, so
they shouldn't be affected at all. C++ is only used for the new
framework (where testm88k and testmips can be experimented with, but
they don't really run many instructions yet, so they are not useful yet
for end-users).

> Perhaps you can modify configure to add -lgomp if needed?

That could be one way. However, there must be a reason why
-D_GLIBCXX_PARALLEL is set in your CXXFLAGS. The place where that flag
is set should probably also have added -lgomp.

Is that a default Debian flag, or something which was added some other
way to your CXXFLAGS? Is there maybe a separate LDFLAGS but for C++? (Is
-lgomp in your LDFLAGS perhaps, and GXemul's configure ignores it?)


Anders

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Andreas,

It's working! My guests are cats, decstation and pmax.  I don't know if 
there is any impact on performance, but at least all is well.

Perhaps you can modify configure to add -lgomp if needed?

-Nigel

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Nigel Horne wrote:
> Nigel Horne wrote:
>   
>> I wonder if -D_GLIBCXX_PARALLEL is to blame? It would be a pity if it 
>> is...
>>     
>
> I can confirm that your test program links OK without that option. Other 
> than the obvious "don't set that option", is there something else I can try?
>   

I need to add "-lgomp". I'm now going to rebuild gexmul with that 
library. I wonder what will happen??

-Nigel

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Nigel Horne wrote:
>
> I wonder if -D_GLIBCXX_PARALLEL is to blame? It would be a pity if it 
> is...

I can confirm that your test program links OK without that option. Other 
than the obvious "don't set that option", is there something else I can try?

This is gcc version 4.4.1

-Nigel

Re: [GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Andres,

Thanks for your reply.
>> I'm having trouble linking the latest version in SVN on my Debian machine:
>>
>> ...
>> /usr/include/c++/4.4/parallel/find.h:221: undefined reference to 
>> `omp_init_lock'
>>     
>
> Strange. Is this with default compiler options (i.e. CXXFLAGS="")? Or
> have you enabled OpenMP or parallel code generation in some way?
>   
njh@packard:~$ echo $CFLAGS
-O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized 
-Wall -pipe -mtune=core2 -march=core2 -fomit-frame-pointer -ffast-math 
-msse2 -msse -mmmx -mfpmath=sse -pedantic -D_FORTIFY_SOURCE=2 
-Wpointer-arith -Wstrict-prototypes -fstack-protector -Wstack-protector 
-Wextra -Wbad-function-cast -Wcast-align -Wcast-qual 
-Wdisabled-optimization -Wendif-labels -Wfloat-equal -Wformat-nonliteral 
-Winline -Wmissing-declarations -Wmissing-prototypes -Wnested-externs 
-Wpointer-arith -Wundef -Wformat-security
njh@packard:~$ echo $CXXFLAGS
-O2 -W -Wformat=2 -Wswitch -Wshadow -Wwrite-strings -Wuninitialized 
-Wall -pipe -mtune=core2 -march=core2 -fomit-frame-pointer -ffast-math 
-msse2 -msse -mmmx -mfpmath=sse -D_FORTIFY_SOURCE=2 -Wpointer-arith 
-fstack-protector -Wstack-protector -Wextra -Wcast-align -Wcast-qual 
-Wdisabled-optimization -Wendif-labels -Wfloat-equal -Wformat-nonliteral 
-Winline -Wpointer-arith -Wundef -D_GLIBCXX_PARALLEL

> GXemul's M88K_CPUComponent.cc includes <algorithm> for "find", which (as
> far as I know) shouldn't require anything regarding parallel support.
>
> Can you compile something like the following, without linker errors?
>
> #include <algorithm>
> #include <vector>
>
> using std::vector;
>
> int main(int argc, char *argv[])
> {
> 	vector<int> vec;
> 	vec.resize(42);
> 	vec[18] = 123;
>
> 	if (find(vec.begin(), vec.end(), 123) == vec.end())
> 		return 1;
>
> 	return 0;
> }
>
>   
It works if I do "g++ foo.c", but not if I do "g++ $CXXFLAGS foo.c".

I wonder if -D_GLIBCXX_PARALLEL is to blame? It would be a pity if it is...
> Anders
>
> PS. I've put up a page at http://gxemul.sourceforge.net/build.html with
> results from builds on machines that I have access to. DS.
>
>   
Great!

-Nigel

Re: [GXemul-users] Errors with SVN

[Anders G. <ga...@gm...>]

Fre 2009-08-14 klockan 10:49 +0100 skrev Nigel Horne:
> Anders,
> 
> I'm having trouble linking the latest version in SVN on my Debian machine:
> 
> ...
> /usr/include/c++/4.4/parallel/find.h:221: undefined reference to 
> `omp_init_lock'

Strange. Is this with default compiler options (i.e. CXXFLAGS="")? Or
have you enabled OpenMP or parallel code generation in some way?

GXemul's M88K_CPUComponent.cc includes <algorithm> for "find", which (as
far as I know) shouldn't require anything regarding parallel support.

Can you compile something like the following, without linker errors?

#include <algorithm>
#include <vector>

using std::vector;

int main(int argc, char *argv[])
{
	vector<int> vec;
	vec.resize(42);
	vec[18] = 123;

	if (find(vec.begin(), vec.end(), 123) == vec.end())
		return 1;

	return 0;
}


Anders

PS. I've put up a page at http://gxemul.sourceforge.net/build.html with
results from builds on machines that I have access to. DS.

[GXemul-users] Errors with SVN

[Nigel H. <nj...@ba...>]

Anders,

I'm having trouble linking the latest version in SVN on my Debian machine:

...
/usr/include/c++/4.4/parallel/find.h:221: undefined reference to 
`omp_init_lock'
src/components/cpu/M88K_CPUComponent.o: In function `get_max_threads':
/usr/include/c++/4.4/parallel/base.h:87: undefined reference to 
`omp_get_max_threads'
src/components/cpu/M88K_CPUComponent.o: In function 
`std::pair<__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > > > 
__gnu_parallel::find_template<__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
std::binder2nd<__gnu_parallel::equal_to<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, char const (&) [3]> >, 
__gnu_parallel::find_if_selector>(__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
__gnu_cxx::__normal_iterator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > const*, 
std::__cxx1998::vector<std::basic_string<char, std::char_traits<char>, 
std::allocator<char> >, std::allocator<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> > > > >, 
std::binder2nd<__gnu_parallel::equal_to<std::basic_string<char, 
std::char_traits<char>, std::allocator<char> >, char const (&) [3]> >, 
__gnu_parallel::find_if_selector, __gnu_parallel::growing_blocks_tag)':
/usr/include/c++/4.4/parallel/find.h:227: undefined reference to 
`omp_get_num_threads'
/usr/include/c++/4.4/parallel/find.h:230: undefined reference to 
`omp_get_thread_num'
/usr/include/c++/4.4/parallel/find.h:264: undefined reference to 
`omp_unset_lock'
/usr/include/c++/4.4/parallel/find.h:256: undefined reference to 
`omp_set_lock'
/usr/include/c++/4.4/parallel/find.h:279: undefined reference to 
`omp_destroy_lock'
collect2: ld returned 1 exit status
make: *** [build] Error 1

Re: [GXemul-users] python - ctypes - gxemul.so

[Anders G. <ga...@gm...>]

Ons 2009-08-12 klockan 17:44 +0200 skrev Grzegorz Makarewicz:
> Hej,

Hi Grzegorz,

> Is there any chance to split gxemul to smaller pieces - like in giano,
> where each devices is stored as separate .so file ?

That would require two things:

1) A dynamic module loader (maybe this is not too hard to implement, but
someone has to take the time to do it),

and

2) A stable API. This is harder, and not guaranteed at this point.


Anders

[GXemul-users] GXemul 0.4.7.2 has been released -- new homepage URL

[Anders G. <ga...@gm...>]

GXemul 0.4.7.2 has been released, 2009-06-21.

The changes between release 0.4.7.1 and 0.4.7.2 are:

      * NetBSD 5.0, OpenBSD 4.5, and HelenOS 0.4.0 have been released,
        and the guest OS page has been updated to reflect this. (Not all
        versions and architectures work; the versions listed on the
        guest OS page are the latest ones that have been tested.) 
      * A bug has been fixed which prevented configuration files from
        being used. 

The official GXemul homepage has now finally been moved to a SourceForge
URL: http://gxemul.sourceforge.net/

Release notes:  http://gxemul.sourceforge.net/gxemul-stable/RELEASE.html
Download:       http://gxemul.sourceforge.net/download.html


Anders

[GXemul-users] feature request

[Folkert v. H. <fo...@va...>]

Any chance that gxemul will be able to run:
- IRIX
- AIX
in the future?


Folkert van Heusden

-- 
MultiTail è uno flexible tool per seguire di logfiles e effettuazione
di commissioni. Feltrare, provedere da colore, merge, 'diff-view',
etc. http://www.vanheusden.com/multitail/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com

Re: [GXemul-users] endianness when loading raw files

[Anders G. <ga...@gm...>]

Hi ew,

Tor 2009-02-19 klockan 07:35 +0100 skrev ew:
> Is there a way to specify the endianness when loading a raw file ?
> I.e., loading a LE elf file via
> gxemul-0.4.7.x/gxemul -v -V -E testmips -C 4KEc test.elf
>  works, while loading the raw binary (created via objdump -o binary) via
> gxemul-0.4.7.x/gxemul -v -V -E testmips -C 4KEc 0x80400000:test.bin
> does not work because the default mode seems to be big endian.

Sorry, there is no simple way (i.e. using the command line).

However, if you are using configuration files, you can use
byte_order(little) or byte_order(big) to force endianness.

http://gavare.se/gxemul/gxemul-stable/doc/configfiles.html#config

Or, if you rather feel like hacking the source code, the correct place
to change (I think) is 

	MACHINE_SETUP(testmips)
	{
	...
	        cpu->byte_order = EMUL_BIG_ENDIAN;

in src/machines/machine_test.c.


Anders

[GXemul-users] endianness when loading raw files

[ew <la...@tf...>]

Is there a way to specify the endianness when loading a raw file ?
I.e., loading a LE elf file via
gxemul-0.4.7.x/gxemul -v -V -E testmips -C 4KEc test.elf
 works, while loading the raw binary (created via objdump -o binary) via
gxemul-0.4.7.x/gxemul -v -V -E testmips -C 4KEc 0x80400000:test.bin
does not work because the default mode seems to be big endian.

[GXemul-users] GXemul 0.4.7.1 has been released

[Anders G. <ga...@gm...>]

GXemul 0.4.7.1 has been released, 2009-02-07.

The changes between release 0.4.7 and 0.4.7.1 are:
         
      * Applying a man page hypenation patch from Jonathan Wiltshire. 
      * Minor documentation errors fixed. 
      * Some more missing M88K instructions added. 
      * NetBSD/hpcmips can now be installed and run using serial console
        (i.e. without -X), in addition to using the framebuffer.

Release notes:  http://gavare.se/gxemul/gxemul-stable/RELEASE.html
Download:       http://gavare.se/gxemul/download.html

Alternatively, if you have the SVN tree
https://gxemul.svn.sourceforge.net/svnroot/gxemul/gxemul/branches/gxemul-0.4.7 checked out, you may run svn update to update 0.4.7 to 0.4.7.1.


Anders