Building B-em on W10 Msys64 first draft

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

Building B-em on W10 Msys64 first draft

Postby pstnotpd » Sat Mar 11, 2017 9:22 am

Ok, I created a rough guide on how to build b-em on W10 using Msys64. I wanted to add it to the wiki, but don't seem to have push permissions to do that. So here it is for now.

Setup steps to create a working b-em build environment on W10 using Msys64

This is a first, working draft for a setup.
It is only tested on W10 Msys64 but with some adjustments it should work for other Msys configurations.
It will need the unpacked version of the "older" MinGW setup for W7 to gather some libraries.

See: https://github.com/stardot/b-em/wiki/Bu ... sing-MinGW

NOTE: I'd prefer to resolve the libraries in a nicer way by either using native packages like OpenAL or builds from the source for alut and allegro4, but that hasn't been very successful so far.......


1. Get the Windows 7 environment and unpack in a convenient place:
https://www.dropbox.com/s/t7npyinl5aszr ... W.zip?dl=0

2. Download the MSYS2 64 distribution from:
https://sourceforge.net/projects/msys2/ ... se/x86_64/

I used the latest msys2-x86_64-20161025.exe distribution

3. Install this and let it point to de default install directory C:/msys64
After installation you should have the following menu items
MSYS2 64bit
-MSYS2 MinGW 32-bit
-MSYS2 MinGW 64-bit
-MSYS2 MSYS
All of these will open up a command prompt with an environment indication

4. Setup the gcc toolchain for the 32-bit environment
[*] Start MSYS2 MSYS from the menu
[*] on the command prompt execute the following

Code: Select all

$ pacman -S base-devel \
      mingw-w64-i686-toolchain \
      mingw-w64-i686-xpm-nox \
      mingw-w64-i686-libtiff \
      mingw-w64-i686-giflib \
      mingw-w64-i686-libpng \
      mingw-w64-i686-libjpeg-turbo \
      mingw-w64-i686-librsvg \
      mingw-w64-i686-libxml2 \
      mingw-w64-i686-gnutls

$ pacman -S git


5. From the Windows 7 environment retrieve the following libraries and headers and put it in the structure described belo in a temporary directory

Code: Select all

bin (W7 MinGW/bin)
|-alleg44.dll
|-alutdll
|-OpenAL32.dll
include (W7 MinGW/include)
|-AL (complete directory)
|-allegro (complete directory
|-allegrogl (complete directory)
|-alleggl.h
|-allegro.h
|-alut.h
|-winalleg.h
lib (@7 MinGW/lib)
|-alut.lib
|-libballeg.a
|-liballeg44.dll.a
|-liballeggl.a
|-OpenAL32.lib


6. Copy and paste the above structure directly to C:\msys64\mingw32
This should resolve all needed libraries for now, but is quite a nasty hack IMHO

7. Close the MSYS prompt and open "MSYS2 MinGW 32-bit" from the windows menu
This should open up a command prompt in your "own" home directory. Check with pwd

8. Clone the b-em repository from stardot to your home directory (or any work directory you prefer)

Code: Select all

$ git clone git clone https://github.com/stardot/b-em.git


9. go to the b-em source directory and start building!
For now the makebem.bat is not suitable as it refers to the original MinGW environment.
As it's basically only 2 make commands I built like this for now.
```
$ cd b-em/src
$ make -f Makefile.win b-em.res
$ make -f Makefile.win
```

THIS WILL PRODUCE ERRORS!!!!!!!.
TO QUICKLY SOLVE NOW FOLLOW BELOW BUT THIS WILL EVENTUALLY HAVE TO BE SOLVED IN THE MAIN CODEBASE.


10. Rename the file ~/b-em/src/Z80.c to ~/b-em/src/z80.c
11. Comment out the following typedef in the file tsearch.c

Code: Select all

/*
#ifndef __CLANG_MAX_ALIGN_T_DEFINED
typedef long double max_align_t;
#endif
*/


12. Retry the build steps from step 9. This should now produce a b-em.exe

NOTE: This is NOT a drop-in to the existing runtime anymore as it resolves to newer versions of the libraries.
If you try it you will get weird errors.


13. Move b-em.exe to the parent directory

$ cp b-em.exe ..
$ mv ..


14. Start b-em

Code: Select all

$ ./b-em.exe


15 Do stuff..... :D

If anyone can tell me how to push back to the stardot github wiki I'll add it there as well.

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

Re: Building B-em on W10 Msys64 first draft

Postby hoglet » Sat Mar 11, 2017 11:14 am

pstnotpd wrote:If anyone can tell me how to push back to the stardot github wiki I'll add it there as well.

You should be allowed to do that now.

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

Re: Building B-em on W10 Msys64 first draft

Postby hoglet » Sat Mar 11, 2017 12:04 pm

Just testing the instructions on Windows 7, and I thought I would log any inconsistencies.

pstnotpd wrote:5. From the Windows 7 environment retrieve the following libraries and headers and put it in the structure described belo in a temporary directory

Code: Select all

bin (W7 MinGW/bin)
|-alleg44.dll
|-alutdll
|-OpenAL32.dll


These files are not in W7 MinGW/bin, they are in W7 MinGW/b-em-runtime.

There is a typo in alutdll.

pstnotpd wrote:

Code: Select all

include (W7 MinGW/include)
|-AL (complete directory)
|-allegro (complete directory
|-allegrogl (complete directory)
|-alleggl.h
|-allegro.h
|-alut.h
|-winalleg.h


alut.h is not here (it's in AL/)

pstnotpd wrote:

Code: Select all

$ git clone git clone https://github.com/stardot/b-em.git


There is a typo in that command.

After doing the compile, I can run b-em.exe as described from the MinSYS2 MinGW 32-bit Shell.

But if I try running the same executable from Windows explorer I get:
winpthread.png


Is that also what you are seeing?

Did you experiment much with autotools, specifically:

Code: Select all

./autogen.sh
./configure
make

This seems to be close to working; there is just an issue with the allegro libraries.

Code: Select all

$ ./configure
configure: loading site script /mingw32/etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking build system type... i686-w64-mingw32
checking host system type... i686-w64-mingw32
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether to enable debugging... no
checking platform...... checking for allegro-config... no
checking for Allegro - version >= 4.0.0... no
*** The allegro-config script installed by Allegro could not be found
*** If Allegro was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the ALLEGRO_CONFIG environment variable to the
*** full path to allegro-config.
configure: error: building B-em requires Allegro to be installed

Dave

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

Re: Building B-em on W10 Msys64 first draft

Postby hoglet » Sat Mar 11, 2017 12:45 pm

hoglet wrote:After doing the compile, I can run b-em.exe as described from the MinSYS2 MinGW 32-bit Shell.

But if I try running the same executable from Windows explorer I get:
winpthread.png

Is that also what you are seeing?

Adding a -static to the link command in the Makefile fixes that:

Code: Select all

b-em.exe: $(OBJ) $(SIDOBJ) $(NS32KOBJ)
   $(CC) $(OBJ) $(SIDOBJ) $(NS32KOBJ) -static -o "b-em.exe" $(LIBS)

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: Building B-em on W10 Msys64 first draft

Postby Coeus » Sat Mar 11, 2017 1:11 pm

The configure script is not supposed to be checking for Allegro on Windows but immediately before the Allego check is a platform check that seems to be going awry as it doesn't print any platform name before moving on to the next check. It looks the same on Linux but on Linux the allegro-config program should be there. If we can solve why the platform check doesn't work properly we will be further forward.

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

Re: Building B-em on W10 Msys64 first draft

Postby hoglet » Sat Mar 11, 2017 1:41 pm

I've dumped the couple of small changes suggested by pstnotpd into a branch in my fork:
https://github.com/hoglet67/b-em/commits/db-mingw-fixes

We can easily turn this into a pull request when we are happy these are correct.

They work for me on:
- Linux
- the old MinGW environment
- the new MinGW envorinment

Dave

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

Re: Building B-em on W10 Msys64 first draft

Postby pstnotpd » Sat Mar 11, 2017 1:45 pm

hoglet wrote:But if I try running the same executable from Windows explorer I get:
winpthread.png

Is that also what you are seeing?

Yes that's what I got as well. Tracing that dll (and some others) in the mingw32 and overwriting solved that. That's why I assume they are actually different.
hoglet wrote:Did you experiment much with autotools, specifically:

Code: Select all

./autogen.sh
./configure
make

This seems to be close to working; there is just an issue with the allegro libraries.


Code: Select all

$ ./configure
configure: loading site script /mingw32/etc/config.site
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether make supports nested variables... (cached) yes
checking build system type... i686-w64-mingw32
checking host system type... i686-w64-mingw32
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking for g++... g++
checking whether we are using the GNU C++ compiler... yes
checking whether g++ accepts -g... yes
checking dependency style of g++... gcc3
checking whether to enable debugging... no
checking platform...... checking for allegro-config... no
checking for Allegro - version >= 4.0.0... no
*** The allegro-config script installed by Allegro could not be found
*** If Allegro was installed in PREFIX, make sure PREFIX/bin is in
*** your path, or set the ALLEGRO_CONFIG environment variable to the
*** full path to allegro-config.
configure: error: building B-em requires Allegro to be installed

Dave

That's how far I got. The missing allegro-config triggered me to attempt a fresh allegro build from the sources but that gave me a severe headache.

As I realized the makebem.bat commands should work I tried that, but actually I'd prefer the autogen/configure/make route myself. I don't have much knowledge on how to adjust those configurations though.

Even nicer would be to get allegro 4.4.x building against the Msys2 environment as OpenAL is a standard package and alut can be replaced with freealut which I succesfully built and installed in the same environment earlier.

But anyway, progress has been made I suppose....

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

Re: Building B-em on W10 Msys64 first draft

Postby pstnotpd » Sat Mar 11, 2017 1:49 pm

P.S. I suppose that you can resolve the ddl error by adding C:\msys64\mingw32\bin to the windows path, but I'd rather not do that permanently.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: Building B-em on W10 Msys64 first draft

Postby Coeus » Sat Mar 11, 2017 1:52 pm

On the autogen/configure problem I checked config.log which is the usual resource for problems and didn't find enough detail. Is there a bash shell under MSYS2? If could you run:

sh -x configure > config-trace.log 2>&1

and then fine in that file the lines that look like:

Code: Select all

+ printf '%s\n' 'configure:4201: checking platform...'
+ printf %s 'checking platform...... '
checking platform...... + test linux-gnu '!=' win
+ test '' = set


and see what is being compared against 'win'. If it is something else, like msys2-win we can update configure.ac to accept the new value and this should start working.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: Building B-em on W10 Msys64 first draft

Postby Coeus » Sat Mar 11, 2017 1:53 pm

pstnotpd wrote:P.S. I suppose that you can resolve the ddl error by adding C:\msys64\mingw32\bin to the windows path, but I'd rather not do that permanently.


Is static linking such a bad idea? I think if these were standard libraries used by many programs dynamic linking would be preferable but if there is a very high chance that B-em is the only program using them it may be better to make the executable more self-contained.

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

Re: Building B-em on W10 Msys64 first draft

Postby hoglet » Sat Mar 11, 2017 2:06 pm

I have no problem with static linking on Windows.

The autotools buiid gets a bit further on Windows if you add allegro-config (from the linux build) to your path somewhere.

It's just a script:
allegro-config.zip
(1.4 KiB) Downloaded 15 times

That gets you passed the allegro tests.

The next problem is openal seems to be called openal32 on Windows.

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

Re: Building B-em on W10 Msys64 first draft

Postby hoglet » Sat Mar 11, 2017 2:07 pm

pstnotpd wrote:P.S. I suppose that you can resolve the ddl error by adding C:\msys64\mingw32\bin to the windows path, but I'd rather not do that permanently.

Static linking gets over that problem.

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

Re: Building B-em on W10 Msys64 first draft

Postby pstnotpd » Sat Mar 11, 2017 5:51 pm

hoglet wrote:
pstnotpd wrote:P.S. I suppose that you can resolve the ddl error by adding C:\msys64\mingw32\bin to the windows path, but I'd rather not do that permanently.

Static linking gets over that problem.


I'm perfectly happy with static linking. It makes it more self contained as well.

I'll try a build with the native Mingw OpenAL package and a compiled freealut to avoid the legacy trap in the future on my own fork in the mean time.


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 4 guests