Getting Unangband/Angband from SVN and Compiling on Windows

[Zero]

Okay, I rechecked the path system variable, opened a DOS prompt, cd'ed to the \src directory, and pasted in Andrew's command. It generated a lot of output text to the screen, which overflowed the window's history buffer, and stopped after maybe 8 seconds. After increasing the window buffer to catch all the output, I ran the command again, which generated this, and much faster:

[EDIT] These errors look the same as the errors that eclipse generates.

[EDIT] Updated the project in eclipse, then tried to rebuild, using Andrew's instructions in the first post. Eclipse generates the same errors.

[EDIT] Removed a reference to the nightly builds. I'm not using the nightly builds, I'm trying to build the program myself.

[EDIT] After updating, I notice that the modification dates in the src directory for the source and header files are all still 1/6/08. Have there been any changes since then? Shouldn't those changes result in changed modification dates?

E:\workspace\Angband\src>mingw32-make.exe -f makefile.win
gcc -o angband.exe attack.o birth.o cave.o compress.o cmd0.o cmd1.o cmd2.o cmd3.
o cmd4.o cmd5.o cmd6.o cmd-obj.o death.o debug.o dungeon.o effects.o files.o gam
e-cmd.o game-event.o generate.o history.o init1.o init2.o load.o loadsave.o mele
e1.o melee2.o monster1.o monster2.o object1.o object2.o obj-info.o obj-make.o op
tion.o randart.o randname.o pathfind.o score.o signals.o save.o spells1.o spells
2.o squelch.o store.o tables.o trap.o ui.o ui-event.o ui-menu.o util.o variable.
o wiz-spoil.o wiz-stats.o wizard.o x-spell.o xtra1.o xtra2.o xtra3.o z-file.o z-
form.o z-msg.o z-quark.o z-rand.o z-term.o z-type.o z-util.o z-virt.o z-blockfil
e.o z-smap.o  win/angband.res main-win.o win/readdib.o -mno-cygwin -e _mainCRTSt
artup
main-win.o:main-win.c:(.text+0x304): undefined reference to `GetPaletteEntries@1
6'
main-win.o:main-win.c:(.text+0x3db): undefined reference to `CreatePalette@4'
main-win.o:main-win.c:(.text+0x418): undefined reference to `SelectPalette@12'
main-win.o:main-win.c:(.text+0x423): undefined reference to `RealizePalette@4'
main-win.o:main-win.c:(.text+0x481): undefined reference to `SelectPalette@12'
main-win.o:main-win.c:(.text+0x4f7): undefined reference to `DeleteObject@4'
main-win.o:main-win.c:(.text+0x604): undefined reference to `RemoveFontResourceA
@4'
main-win.o:main-win.c:(.text+0x73d): undefined reference to `DeleteObject@4'
main-win.o:main-win.c:(.text+0x75e): undefined reference to `AddFontResourceA@4'

main-win.o:main-win.c:(.text+0x810): undefined reference to `CreateFontA@56'
main-win.o:main-win.c:(.text+0x85c): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0x873): undefined reference to `GetTextMetricsA@8'
main-win.o:main-win.c:(.text+0x882): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0xf90): undefined reference to `SetBkColor@8'
main-win.o:main-win.c:(.text+0xfa5): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0xfde): undefined reference to `ExtTextOutA@32'
main-win.o:main-win.c:(.text+0x1086): undefined reference to `PlaySoundA@12'
main-win.o:main-win.c:(.text+0x12ec): undefined reference to `SetBkColor@8'
main-win.o:main-win.c:(.text+0x1301): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0x133a): undefined reference to `ExtTextOutA@32'
main-win.o:main-win.c:(.text+0x13d3): undefined reference to `SetBkColor@8'
main-win.o:main-win.c:(.text+0x1406): undefined reference to `SetTextColor@8'
main-win.o:main-win.c:(.text+0x141b): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0x146f): undefined reference to `ExtTextOutA@32'
main-win.o:main-win.c:(.text+0x14f5): undefined reference to `ExtTextOutA@32'
main-win.o:main-win.c:(.text+0x1596): undefined reference to `ExtTextOutA@32'
main-win.o:main-win.c:(.text+0x1658): undefined reference to `CreateCompatibleDC
@4'
main-win.o:main-win.c:(.text+0x1672): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0x1721): undefined reference to `BitBlt@36'
main-win.o:main-win.c:(.text+0x1766): undefined reference to `BitBlt@36'
main-win.o:main-win.c:(.text+0x17ab): undefined reference to `BitBlt@36'
main-win.o:main-win.c:(.text+0x1870): undefined reference to `SetStretchBltMode@
8'
main-win.o:main-win.c:(.text+0x18c0): undefined reference to `StretchBlt@44'
main-win.o:main-win.c:(.text+0x1928): undefined reference to `StretchBlt@44'
main-win.o:main-win.c:(.text+0x1950): undefined reference to `SetStretchBltMode@
8'
main-win.o:main-win.c:(.text+0x19a3): undefined reference to `StretchBlt@44'
main-win.o:main-win.c:(.text+0x19ee): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0x19fc): undefined reference to `DeleteDC@4'
main-win.o:main-win.c:(.text+0x1a39): undefined reference to `CreateCompatibleDC
@4'
main-win.o:main-win.c:(.text+0x1a53): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0x1a6d): undefined reference to `SelectObject@8'
main-win.o:main-win.c:(.text+0x1a7b): undefined reference to `DeleteDC@4'
main-win.o:main-win.c:(.text+0x2135): undefined reference to `SelectPalette@12'
main-win.o:main-win.c:(.text+0x2140): undefined reference to `RealizePalette@4'
main-win.o:main-win.c:(.text+0x2cbb): undefined reference to `GetOpenFileNameA@4
'
main-win.o:main-win.c:(.text+0x323c): undefined reference to `GetOpenFileNameA@4
'
main-win.o:main-win.c:(.text+0x33f4): undefined reference to `SelectPalette@12'
main-win.o:main-win.c:(.text+0x33ff): undefined reference to `RealizePalette@4'
main-win.o:main-win.c:(.text+0x3b73): undefined reference to `DeleteObject@4'
main-win.o:main-win.c:(.text+0x3c1e): undefined reference to `DeleteObject@4'
main-win.o:main-win.c:(.text+0x3cb7): undefined reference to `DeleteObject@4'
main-win.o:main-win.c:(.text+0x4082): undefined reference to `GetDeviceCaps@8'
main-win.o:main-win.c:(.text+0x40a0): undefined reference to `GetDeviceCaps@8'
main-win.o:main-win.c:(.text+0x48fd): undefined reference to `CreateSolidBrush@4
'
main-win.o:main-win.c:(.text+0x4aa1): undefined reference to `GetStockObject@4'
win/readdib.o:readdib.c:(.text+0x39e): undefined reference to `CreatePalette@4'
win/readdib.o:readdib.c:(.text+0x3d3): undefined reference to `SelectPalette@12'

win/readdib.o:readdib.c:(.text+0x3e6): undefined reference to `RealizePalette@4'

win/readdib.o:readdib.c:(.text+0x42a): undefined reference to `CreateDIBitmap@24
'
win/readdib.o:readdib.c:(.text+0x44e): undefined reference to `SelectPalette@12'

win/readdib.o:readdib.c:(.text+0x45f): undefined reference to `RealizePalette@4'

win/readdib.o:readdib.c:(.text+0x5a1): undefined reference to `DeleteObject@4'
win/readdib.o:readdib.c:(.text+0x5cd): undefined reference to `GetStockObject@4'

win/readdib.o:readdib.c:(.text+0x61b): undefined reference to `DeleteObject@4'
win/readdib.o:readdib.c:(.text+0x634): undefined reference to `DeleteObject@4'
collect2: ld returned 1 exit status
mingw32-make.exe: *** [angband.exe] Error 1

[zaimoni]

Okay, I rechecked the path system variable, opened a DOS prompt, cd'ed to the \src directory, and pasted in Andrew's command. ....

E:\workspace\Angband\src>mingw32-make.exe -f makefile.win

This is not correct usage of makefile.win for MingW32. Per the instructions in Makefile.win, try

E:\workspace\Angband\src>mingw32-make.exe -f makefile.win MINGW=yes

(This default could be forgiven if the CygWin default actually worked, but as CygWin's devteam has intentionally broken --mno-cygwin for anything using assert() I'm not certain what the point will be of retaining default CygWin for V3.1.0 . Until the Windows front end becomes legal to link with CygWin, of course.)

[Zero]

Well, what do you know! It works! Thanks, zaimoni.

[jld]

*coughs* http://cygwin.com/license.html

The cygwin DLL (which gets linked into your binary if you use -mno-cygwin) is GPL with an exception for applications with OSI-free licences. Angband isn't one of those, so you have no licence to distribute a cygwin-compiled version of the game under the Angband licence...

Not that I suspect anyone will care, anyway. Licencing sucks.

Actually, I think you're backwards (and I'd hate for Cygwin to get a bad name and/or have its support revoked over a misunderstanding...) -mno-cgywin does NOT link the cygwin DLL. (Thus, the 'no cygwin' in the name). With this switch, your application does NOT require Cygwin to be installed, and it does not link against/require the cygwin DLL. The best documentation I could find is pretty out of date, but it might be useful to read

It is possible and pretty straightforward to compile Angband with Cygwin. I had to make some changes to the Makefile.win that shipped with 3.0.9 to get it to work... if there is interest, I will try to make them available.

(edit: Change line 55, which starts with LIBS = to start with LIBS +=, add a new line "CFLAGS += -mno-cygwin", and change line 60 (previously 59) to add the source files: "win/readdib.c win/readdib.h" (no quotes) and 3.0.9 should compile with cygwin as per the instructions on the official wiki)

[zaimoni]

Actually, I think you're backwards (and I'd hate for Cygwin to get a bad name and/or have its support revoked over a misunderstanding...) -mno-cygwin does NOT link the cygwin DLL.

The current Windows front-end still loses, as the CygWin license explicitly has the OSI requirement for libcygwin.a as well (which is statically linked in when libcygwin1.dll is not dynamically linked in).

I think the long-term plan is to get main-win.c compatible, however. The GPL poisoning for non-OSI code takes effect only on distribution.

It is possible and pretty straightforward to compile Angband with Cygwin. I had to make some changes to the Makefile.win that shipped with 3.0.9 to get it to work... if there is interest, I will try to make them available.

(edit: Change line 55, which starts with LIBS = to start with LIBS +=, add a new line "CFLAGS += -mno-cygwin", and change line 60 (previously 59) to add the source files: "win/readdib.c win/readdib.h" (no quotes) and 3.0.9 should compile with cygwin as per the instructions on the official wiki)

Line 60 change is already in SVN, fine.

Line 55 change exactly reverts the effective LIBS to Zaiband's Makefile.cyg; it should be safe.

I think the CFLAGS change is the critical one, but can't test it. My other native MingW32 projects also apply -mno-cygwin when compiling *.o files, so it may be the breaking change.

[zaimoni]

I think the CFLAGS change is the critical one, but can't test it. My other native MingW32 projects also apply -mno-cygwin when compiling *.o files, so it may be the breaking change.

Specifically, the mismatch between compiling and linking -mno-cygwin should be breaking the link. I wish I had seen this when this came up on RGRA.

Also: the archaic documentation is current MingW32. CygWin has been changed, however.

[jld]

The current Windows front-end still loses, as the CygWin license explicitly has the OSI requirement for libcygwin.a as well (which is statically linked in when libcygwin1.dll is not dynamically linked in).

Hmm, I still disagree with you. Can you point me at some documentation that backs up your assertion? The only reference I can find relating to statically linking libcygwin.a is this mailing list message, where the person specifically denies that is what happens.

I ran a couple of tests using my installed version of Cygwin and the 3.0.9 sources. First I removed all references to -mno-cygwin and compiled with the linker options including -v. This is the linking step:

 /usr/lib/gcc/i686-pc-cygwin/3.4.4/collect2.exe --subsystem windows -Bdynamic --dll-search-prefix=cyg -o angband.exe -e _mainCRTStartup -s -s /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../crt0.o -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4 -L/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../.. birth.o cave.o cmd0.o cmd1.o cmd2.o cmd3.o cmd4.o cmd5.o cmd6.o dungeon.o files.o generate.o init1.o init2.o load.o melee1.o melee2.o monster1.o monster2.o obj-info.o object1.o object2.o randart.o randname.o pathfind.o signals.o save.o spells1.o spells2.o squelch.o store.o tables.o ui.o use-obj.o util.o variable.o wizard1.o wizard2.o x-spell.o xtra1.o xtra2.o z-file.o z-form.o z-rand.o z-term.o z-type.o z-util.o z-virt.o win/angband.res main-win.o win/readdib.o -lwinmm -lgcc -lcygwin -lgdi32 -lcomdlg32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc

As you can see, the -lcygwin entry causes the resulting angband.exe to depend on the Cygwin DLL. I confirmed this with "objdump -p angband.exe"

However, if I specify -mno-cygwin during compilation and linking, this is the linker output:

 /usr/lib/gcc/i686-pc-mingw32/3.4.4/collect2.exe --subsystem windows -Bdynamic -o angband.exe -e _mainCRTStartup -s -s /usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/lib/crt2.o -L/usr/lib/gcc/i686-pc-mingw32/3.4.4 -L/usr/lib/gcc/i686-pc-mingw32/3.4.4 -L/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../../../i686-pc-mingw32/lib -L/usr/lib/gcc/i686-pc-mingw32/3.4.4/../../.. birth.o cave.o cmd0.o cmd1.o cmd2.o cmd3.o cmd4.o cmd5.o cmd6.o dungeon.o files.o generate.o init1.o init2.o load.o melee1.o melee2.o monster1.o monster2.o obj-info.o object1.o object2.o randart.o randname.o pathfind.o signals.o save.o spells1.o spells2.o squelch.o store.o tables.o ui.o use-obj.o util.o variable.o wizard1.o wizard2.o x-spell.o xtra1.o xtra2.o z-file.o z-form.o z-rand.o z-term.o z-type.o z-util.o z-virt.o win/angband.res main-win.o win/readdib.o -lwinmm -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -lmingw32 -lgdi32 -lcomdlg32 -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt

There is no reference to the cygwin library either statically or dynamically. In fact, it is clear from this that what is actually happening is that Cygwin is using the mingw toolchain to do the compile & link. (The objdump confirms no dynamic link to the cygwin1.dll, but that wasn't something we disagreed on anyhow)

From this, I would conclude that as long as you're using -mno-cygwin, the executable produced should have no licensing issues.

Is this convincing? If not, what information do you have that seems to contradict this?

(EDIT: ) To get this thread back on track, would instructions on installing and compiling with Cygwin be of any use? Or are people pretty much using the method in the first post?

[zaimoni]

Hmm, I still disagree with you. Can you point me at some documentation that backs up your assertion? The only reference I can find relating to statically linking libcygwin.a is this mailing list message, where the person specifically denies that is what happens.

We have two problems here.
* Working Google against libcygwin.a, there are *hordes* of references to link errors involving libcygwin.a 2000 and later. However, it is a stub for connecting in cygwin1.dll (as are its symlinks libm.a and libc.a, apparently.) So yes, a working -mno-cygwin should not use libcygwin.a either. Assuming that it's properly maintained.
* As reported on RGRA, recent V's do not link on CygWin with -mno-cygwin linker-only. ( http://groups.google.com/group/rec.g...27888bcbf64e55 ) That isn't what you did, so I'd consider patching it in.
* Per http://www.cygwin.com/ml/cygwin/2007-02/msg00079.html, there was an attempt to outright remove -mno-cygwin support from CygWin. Reading forward, this didn't go through but it is a medium-term target.

[jld]

We have two problems here.
* Working Google against libcygwin.a, there are *hordes* of references to link errors involving libcygwin.a 2000 and later. However, it is a stub for connecting in cygwin1.dll (as are its symlinks libm.a and libc.a, apparently.) So yes, a working -mno-cygwin should not use libcygwin.a either. Assuming that it's properly maintained.

OK, so I think we agree - There are no license issues so long as you use -mno-cygwin when using Cygwin to compile and link Angband (or any other code, for that matter). I don't know what to say about the maintenance of Cygwin - I guess like all open source projects (angband, eclipse, mingw included) you have to trust the maintainers to release versions that do what they should.

* As reported on RGRA, recent V's do not link on CygWin with -mno-cygwin linker-only. ( http://groups.google.com/group/rec.g...27888bcbf64e55 ) That isn't what you did, so I'd consider patching it in.

Sure, I can submit a patch... I'll look around for documentation about the best way to submit patches to the maintainer(s). I'll also grab the latest from SVN and port my fix from 3.0.9. If someone has some docs or a link, that would be helpful.

* Per http://www.cygwin.com/ml/cygwin/2007-02/msg00079.html, there was an attempt to outright remove -mno-cygwin support from CygWin. Reading forward, this didn't go through but it is a medium-term target.

After reading this thread, what it seems like they want to do is remove the option from gcc and replace it with shell scripts that redirect the command directly to the mingw toolset. There doesn't seem to be any end-user impact, except for perhaps a slight overhead cost in running the shell script versus running gcc directly. The disagreements and difficulties they express with the new solution seem to be related to compiling Cygwin itself from source.

I would think that even if they did remove the option, using the Cygwin environment could still be a viable compile option - you already have to install the mingw compilers to get Angband to compile, so it would just be a Makefile.win change for the cgywin case to use the mingw gcc instead.

I guess it boils down to a matter of opinion - would you rather install Eclipse, Java, etc or install Cygwin? I think they both end up with the same result - you get a compiled Angband executable built from the mingw gcc and linked against the default windows libraries.

[zaimoni]

Sure, I can submit a patch... I'll look around for documentation about the best way to submit patches to the maintainer(s). I'll also grab the latest from SVN and port my fix from 3.0.9. If someone has some docs or a link, that would be helpful.

Master index: http://rephial.org/develop .

Tersely, get the coding style right and use svn diff to create the patch.

After reading this thread, what it seems like they want to do is remove the option from gcc and replace it with shell scripts that redirect the command directly to the mingw toolset. There doesn't seem to be any end-user impact, except for perhaps a slight overhead cost in running the shell script versus running gcc directly.

Yes. Based on later threads, I believe they're going for doing the actual elimination with a GCC 4.x release. Note that the MingW32 devteam waited until GCC 4.2.1 to do anything, and I really can't blame them.

[takkaria]

Sure, I can submit a patch... I'll look around for documentation about the best way to submit patches to the maintainer(s). I'll also grab the latest from SVN and port my fix from 3.0.9. If someone has some docs or a link, that would be helpful.

I've rewritten some of the text on the development page:

http://rephial.org/develop#contribute

Do you think this text makes it clearer how to submit patches than it was before?

[jld]

I've rewritten some of the text on the development page:

http://rephial.org/develop#contribute

Do you think this text makes it clearer how to submit patches than it was before?

I think it does. I sent a patch to the mailing list earlier today, so let me know if I got it right

[Anne]

Okay, I'm stuck. The download link given here for Eclipse doesn't work - the page comes up, but clicking anything there just brings you back to the same page in an endless loop. So I googled it. It's possible that what I downloaded wasn't the same version, so that could be my problem. I have Eclipse SDK version 3.3.1.1.

I managed to get to here -

17. Right-click on the src directory, and choose Make Targets > Build...

That option doesn't appear when I right-click, and I can't figure out what to do from here. I'll attach a pic to show what appears on mine. Did I download the wrong thing? I hope not - that one took me 14 hours on dialup. Yoy. Any help will be greatly appreciated.

[Pete Mack]

I can't help you about what to do, since I never tried building a C++ program with eclipse. That said, no reason to give up. What you have looks exactly like a good setup for eclipse.

I am genuinely impressed--14 hours dialup!
There are command line (DOS-window) versions of SVN that are a lot more straightforward, especially if you are not planning to do development yourself.

[roustk]

That option doesn't appear when I right-click, and I can't figure out what to do from here.

I've never used Eclipse (or any other GUI svn thingy), but it looks to me as if you are examining the contents of the Berlios archive, rather than a local copy of the source. You might want to double-check Andrew's steps 11-14.

If that is a local copy of the source, you may want to left-click the src directory (to select it) and then poke around in the menubar for "make".

Of course, I'm probably completely wrong and should be ignored.

Kevin