Mingw configuration for compiling b-em?

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Mingw configuration for compiling b-em?

Postby pstnotpd » Wed Mar 01, 2017 5:59 pm

Having accomplished a buildable version of BeebEm 4.14 with the Sprow Arm emulation with 64MB in place I'd like to setup for B-em as well. I want to have a look at Panos and the M5000 emulation :)

I've installed the latest mingw on W10 and managed to configure all dependencies except for allegro4. I found a binary distribution and tried putting it in /usr/local amongst other places but the build keeps complaining about not finding the allegro.h file.

Any tips?

P.S. I used the same mingw to successfully compile a windows native emacs so it definitely works.

User avatar
hoglet
Posts: 6393
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Mingw configuration for compiling b-em?

Postby hoglet » Wed Mar 01, 2017 6:42 pm

All I can suggest is comparing it with the existing MinGW configuration referenced in this post:
http://www.stardot.org.uk/forums/viewto ... 93#p161993

That one currently has everything needed to build the latest B-Em from the stardot github:
https://github.com/stardot/b-em/commits/master

There are cleanbem.bat and makebem.bat scripts checked in, and I can confirm that they work, as of today.

Dave

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Mingw configuration for compiling b-em?

Postby pstnotpd » Thu Mar 02, 2017 6:36 am

Thanks, I'll give it a go today.

User avatar
fordp
Posts: 877
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: Mingw configuration for compiling b-em?

Postby fordp » Fri Mar 03, 2017 2:47 pm

Please if possible document building on a new wiki page on github.

Thanks.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Mingw configuration for compiling b-em?

Postby pstnotpd » Fri Mar 03, 2017 4:21 pm

I will if I have a working installation. For now I still have issues with Allegro 4 so I decided to try and build Allegro 4 from the sources. It uses cmake which I'm not familiar with and fails with missing references.

I'll have another go this weekend (if that nasty flu gets better that is....)

User avatar
hoglet
Posts: 6393
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Mingw configuration for compiling b-em?

Postby hoglet » Fri Mar 03, 2017 6:32 pm

fordp wrote:Please if possible document building on a new wiki page on github.

I put some notes on how I currently do it here:
https://github.com/stardot/b-em/wiki/Bu ... sing-MinGW

If someone finds a way to re-create a working MinGW environment from scratch, please please take the time to document that!

Dave

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Mingw configuration for compiling b-em?

Postby pstnotpd » Fri Mar 03, 2017 8:55 pm

hoglet wrote:If someone finds a way to re-create a working MinGW environment from scratch, please please take the time to document that!


That's what I'm trying to do here, latest MinGW64 environment on W10. I think the allegro source build that I'm attempting is actually a better route as that would be more platform independent.

I think the problem is due to the deprecation of directX which I encountered before with the (now working) BeebEm build on the latest VS distribution.

Anyway. When successful ( :? ) I'll definitely document and upload to github.

P.S. the trigger was ReCo6502 and M5000 emulation on B-em. Good work! I'd like to add the Sprow emulation to B-em if possible to run UMB scheme, PForth and jgharton's module patch to be included and possibly be merged to PiTubeDirect (As the Sprow boards seem out of stock now)

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Mingw configuration for compiling b-em?

Postby pstnotpd » Sun Mar 05, 2017 10:10 am

Right, I did get a bit further now. I was trying the autogen/configure/make route but that doesn't work because allegro-config doesn't exist. After investigating the Makebem.bat file I figured I could also directly use the commands in there. This batch file doesn't work "as is" as my mingw directories are included in C:/msys64.

"Make"ing this way started the build process allright, but first I got an error that max_allign_t was already declared differently in the gcc standard header files. I commnented out the typedef and could continue.

After that it couldn't find the z80.c file which was actually called Z80 in the git clone so I renamed that one. It got to the linking phase where it started complaining about openal and alut not being there. I managed to build and install freealut which resolved that and tried the same with openal but that failed during cmake, probably because it's missing the ole32.lib file.

I found a binary distribution of openal which seems to have resolved the error.

Unfortunately I'm now stuck with loads of "multiple definition" errors.

Code: Select all

gcc.exe 6502.o 6502tube.o 65816.o acia.o adc.o adf.o arm.o cmos.o compact_joystick.o compactcmos.o compat_wrappers.o config.o csw.o ddnoise.o debugger.o disc.o fdi2raw.o fdi.o i8271.o ide.o keyboard.o logging.o main.o mem.o model.o mouse.o pal.o savestate.o scsi.o serial.o sn76489.o sound.o soundopenal.o ssd.o sysvia.o tape.o tapenoise.o tsearch.o tube.o uef.o uservia.o vdfs.o via.o vidalleg.o video.o wd1770.o win.o win-catalogue.o win-keydefine.o x86.o z80.o resid.o b-em.res convolve.o envelope.o extfilt.o filter.o pot.o sid.o voice.o wave6581__ST.o wave6581_P_T.o wave6581_PS_.o wave6581_PST.o wave8580__ST.o wave8580_P_T.o wave8580_PS_.o wave8580_PST.o wave.o 32016.o Decode.o mem32016.o Trap.o Profile.o NSDis.o -o "b-em.exe" -mwindows -lalleg -lz -lalut -lopenal32 -lgdi32 -lwinmm -lstdc++
65816.o:65816.c:(.text+0x40): multiple definition of `bmp_read24'
6502tube.o:6502tube.c:(.text+0xd0): first defined here
65816.o:65816.c:(.text+0x60): multiple definition of `bmp_write24'
6502tube.o:6502tube.c:(.text+0xf0): first defined here
65816.o:65816.c:(.text+0x80): multiple definition of `install_allegro'
6502tube.o:6502tube.c:(.text+0x110): first defined here
65816.o:65816.c:(.text+0xb0): multiple definition of `set_window_title'
6


Any help would be welcome...... :? :? :? :?

User avatar
hoglet
Posts: 6393
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Mingw configuration for compiling b-em?

Postby hoglet » Sun Mar 05, 2017 10:39 am

pstnotpd wrote:Any help would be welcome...... :? :? :? :?

Can you post a complete build log, after doing a cleanbem.bat (or manually removing all the .o files)?

Which gcc version are you using?

I think this is something to do with the way that extern inline functions in header files are dealt with, which changed in GCC 4.1.x

Try adding -fgnu89-inline to CFLAGS in Makefile.win, or the equivalent in your build process.

Dave

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Mingw configuration for compiling b-em?

Postby pstnotpd » Sun Mar 05, 2017 11:07 am

hoglet wrote:Try adding -fgnu89-inline to CFLAGS in Makefile.win, or the equivalent in your build process.

Dave


Right that indeed fixed the problem and it produced an executable. I realize now however that the M5000 build you posted uses allegro4.4 and I now compiled to 4.2 #-o

Also the alut dll name is different so I tried to copy and rename the alut.dll, which I think will not work, but hey ;)

It now fails with the message "The application was unable to start correctly (0xc000007b).....

Anyway. My msys64 setup is now a big mess and I didn't yet note the steps to get here. I think I'm going to start from fresh with the correct allegro version etc... but I'm a bit done for today.

B.t.w. is your repository a good one to start with? Or should I go with the stardot one?

P.S. I'm getting warning messages that the flag is not valid for the .cc files in the resid-fp but the compiler seems to resolve that by itself.

User avatar
hoglet
Posts: 6393
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Mingw configuration for compiling b-em?

Postby hoglet » Sun Mar 05, 2017 11:27 am

pstnotpd wrote:B.t.w. is your repository a good one to start with? Or should I go with the stardot one?

I would use the startdot one.

The Music5000 pull request should be included there in the next few days.
pstnotpd wrote:P.S. I'm getting warning messages that the flag is not valid for the .cc files in the resid-fp but the compiler seems to resolve that by itself.

You might find this "multiple definitions" issue doesn't exist with Allegro 4.4.2

The allegro header files I'm using contain the following in include/allegro/internal/alconfig.h:

Code: Select all

/* special definitions for the GCC compiler */
#ifdef __GNUC__
   #define ALLEGRO_GCC

   #ifndef AL_INLINE
      #ifdef __cplusplus
         #define AL_INLINE(type, name, args, code)    \
            static inline type name args;             \
            static inline type name args code
      /* Needed if this header is included by C99 user code, as
       * "extern __inline__" is defined differently in C99 (it exports
       * a new global function symbol).
       */
      #elif __GNUC_STDC_INLINE__
         #define AL_INLINE(type, name, args, code)    \
            extern __inline__ __attribute__((__gnu_inline__)) type name args;         \
            extern __inline__ __attribute__((__gnu_inline__)) type name args code
      #else
         #define AL_INLINE(type, name, args, code)    \
            extern __inline__ type name args;         \
            extern __inline__ type name args code
      #endif
   #endif

This deals with the problem locally in Allegro, and in a way that should not cause warnings with C++ sources.

The last Windows release of B-Em in 2012 did use Allegro 4.4.2, so I would recommend we all try to use that version.

Dave

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Mingw configuration for compiling b-em?

Postby pstnotpd » Sun Mar 05, 2017 11:59 am

I found the "correctly" named alut ddl in the freealut build I did and dropped it in the runtime version. Same error on startup

As I think it's more useful to have an up to date version with the correct allegro I'll leave this for now and start anew so that I can also properly document the setup.

Now I'm going to do Sunday things :)

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Mingw configuration for compiling b-em?

Postby pstnotpd » Fri Mar 10, 2017 6:27 pm

SUCCESS!! I managed to build op a B-em build environment on W10 with the latest MINGW64 which, after some small tweaks, produced a working b-em.exe which just now was happily churning away on the M5000 ppach program :)

It's actually quite straightforward so I'll do a small writeup on how to do this so that anyone can set this up. Where's a good place to post this? Over here or on Github itself?


The only drawback is that the executable produced is not a "dropin" to an existing installation anymore as it builds up dependencies to different libraries. So to create a runtime I'll have to figure out which dll's are actually needed in the distribution.

User avatar
hoglet
Posts: 6393
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: Mingw configuration for compiling b-em?

Postby hoglet » Fri Mar 10, 2017 6:31 pm

pstnotpd wrote:It's actually quite straightforward so I'll do a small writeup on how to do this so that anyone can set this up. Where's a good place to post this? Over here or on Github itself?

I'd use the githuib wiki:
https://github.com/stardot/b-em/wiki

Dave

User avatar
pstnotpd
Posts: 392
Joined: Wed Jan 20, 2010 11:05 am

Re: Mingw configuration for compiling b-em?

Postby pstnotpd » Fri Mar 10, 2017 7:05 pm

There were some small code adjustments I had to do.

The Makefile.win searches for z80.c where the actual file is called Z80.c (i.e. capital Z) I changed the filename to z80.c and everything went ok.

There a "max_allign_t" typedef in tsearch.c that now is already defined in the standard header files. I had to comment out this typedef, but it looks like it already had the #ifdef enclosed to check if this is already provided by the compiler. Apparently this version of msys/mingw has it available now. It would be nicer to have a proper #ifdef check for this as well.

I understand that on linux/mac you do the standard configure/make/make install. It would be nice to get this generalized to be the Mingw build as well, but I have to look into that.

And lastly, I had some mild success in actually building the required libraries from the sources as well. freealut produced a linkable result using a package (pacman) install of OpenAL. But somehow the cmake builds for allegro and OpenAL-soft seem to fail on linking to oledb32 (ie the windows sdk) and I don't know how to drop that in. Is it worth spending time on trying to get this to work and fork those to the stardot github as well?

EDIT: I'm raising the above points as 1 issues and on the stardot repository will create a fork to myself with my current fixes. I'll also create the draft version of the setup procedure for Msys64 in the wiki.


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 4 guests