{V} link failures on Windows (XP)
pete m
correctly EXCEPT V (and Eddie's V). I have edited the makefile so
that the flags are the same as for NPP (and others.) But I still get
a huge number of unresolved symbols at link time. Does anybody
recognize these symptoms, and what do I need to do to fix it? I'm
compiling under cygwin.
Kenneth 'Bessarion' Boyd
> I have a strange problem: I can build all versions of angband
> correctly EXCEPT V (and Eddie's V). I have edited the makefile so
> that the flags are the same as for NPP (and others.) But I still get
That includes library flags, right?
> a huge number of unresolved symbols at link time. Does anybody
> recognize these symptoms, and what do I need to do to fix it? I'm
> compiling under cygwin.
Restricting attention to V SVN for the moment:
What kind of unresolved symbols? I would hope not the following:
main-win.o:main-win.c:(.text+0x2a0): undefined reference to
`RemoveFontResourceA
@4'
...
which is handled in MingW32 by linking in -lwinmm; CYGWIN executation path in
Makefile.win explicitly does not link in this library.
Nick
Which makefile are you using? FA uses the V objective make system now, but I
still use Makefile.cyg for compiling in windows (and I use mingw rather than
cygwin now, too), and I don't think V has one of those.
Nick.
--
"There is no safety, and there is no end. The word must be heard in silence;
there must be darkness to see the stars. The dance is always danced above the
hollow place, above the terrible abyss."
- The Farthest Shore, Ursula Le Guin
pete m
> On 2007-12-15 03:03:37, pete m <pmac...@yahoo.com> wrote:
>
> > I have a strange problem: I can build all versions of angband
> > correctly EXCEPT V (and Eddie's V). I have edited the makefile so
> > that the flags are the same as for NPP (and others.) But I still get
> > a huge number of unresolved symbols at link time. Does anybody
> > recognize these symptoms, and what do I need to do to fix it? I'm
> > compiling under cygwin.
>
> Which makefile are you using? FA uses the V objective make system now, but I
> still use Makefile.cyg for compiling in windows (and I use mingw rather than
> cygwin now, too), and I don't think V has one of those.
>
I use Makefile.win, which is similar to Makefile.cyg in other
variants.
I had to edit it slightly to get the same link command as on NPP, etc.
But it didn't help.
pete m
wrote:
No, my compile line is:
gcc -o angband.exe angband.res win/readdib.o *.o -s -mno-cygwin -
mwindows -e _mainCRTStartup -mwinm
The missing symbols are:
__imp___ctype_
___assert
___getreent
___errno
(There may be another one or two, but these repeat over and over.)
Kenneth 'Bessarion' Boyd
> No, my compile line is:
>
> gcc -o angband.exe angband.res win/readdib.o *.o -s -mno-cygwin -
> mwindows -e _mainCRTStartup -mwinm
>
> The missing symbols are:
> __imp___ctype_
> ___assert
> ___getreent
> ___errno
Among other things, you're being nailed by the assert macro. V recently (after
March 2007) started using this as a C-standard debugging tool; it aborts out
when its parameter tests false.
There should be an *.a in your lib directories that provides these symbols.
It'll have to be added to the library requirements for Cygwin, but not MingW32.
Eddie Grove
googling on
getreent cygwin library
The first hit led to something that led to
http://cygwin.com/ml/cygwin/2004-06/msg00478.html
"Looks like I can link to /lib/libcygwin.a to resolve it."
Knowing nothing about windows, I'm not saying it will help, but it can't hurt
to look.
Eddie
Kenneth 'Bessarion' Boyd
> On 2007-12-15 06:07:17, Eddie Grove wrote:
> > The first hit led to something that led to
> > http://cygwin.com/ml/cygwin/2004-06/msg00478.html
> > "Looks like I can link to /lib/libcygwin.a to resolve it."
>
> That is, replace -mno-cygwin with -mcygwin.
>
> Unfortunately, Cygwin license requires that all applications built be
> OSI-certified open source. Koeneke license causes automatic violation, so the
> above solution is legal only for V SVN and later (which is GPLV2+, fine).
More precisely: linking againt libcygwin.a is what causes the automatic
violation. -mno-cygwin is required for a V3.0.9- build to be legal to release;
GPL'd V is fine with -mcygwin .
Kenneth 'Bessarion' Boyd
> Kenneth 'Bessarion' Boyd writes:
>
> > On 2007-12-15 05:56:03, pete m wrote:
> > > The missing symbols are:
> > > __imp___ctype_
> > > ___assert
> > > ___getreent
> > > ___errno
> >
> > Among other things, you're being nailed by the assert macro. V recently (after
> > March 2007) started using this as a C-standard debugging tool; it aborts out
> > when its parameter tests false.
> >
> > There should be an *.a in your lib directories that provides these symbols.
> > It'll have to be added to the library requirements for Cygwin, but not MingW32.
>
> googling on
> getreent cygwin library
>
> The first hit led to something that led to
> http://cygwin.com/ml/cygwin/2004-06/msg00478.html
> "Looks like I can link to /lib/libcygwin.a to resolve it."
That is, replace -mno-cygwin with -mcygwin.
pete m
wrote:
Fortunately, I am using V SVN. And in any case, that holds only for
distributions. You are allowed to do whatever you like when linking
on your own. In any case, I still don't understand why -mno-cygwin
works fine for NPP, O, Un, and for older versions of V.
Assert and errno are limited in use, but the __imp___ctype_ symbol
shows up everywhere.
pete m
> Kenneth 'Bessarion' Boyd <zaim...@zaimoni.com> writes:
>
>
>
> > On 2007-12-15 05:56:03, pete m <pmac...@yahoo.com> wrote:
>
> > > No, my compile line is:
>
> > > gcc -o angband.exe angband.res win/readdib.o *.o -s -mno-cygwin -
> > > mwindows -e _mainCRTStartup -mwinm
>
OK, the -mcygwin works. However, there is still a tiny bug in Eddie's
variant: in cave.c, move_cursor_relative() should no longer be
static.
Windows is very strict about that kind of thing.
Eddie Grove
I just checked the code, and move_cursor_relative is not static.
However, move_cursor_relative_map is static.
Am I supposed to change one of those, or change the extern, or what?
Eddie
pete m
Sorry, I have no idea what was wrong there. Earlier I got a link error
on move_cursor_relative. After recompiling cave.c, the problem seems
to have gone away. Please ignore my earlier comment.
So far, it's pretty fun, though I don't know why Amulet of Resist acid
is Excellent. What a let-down :/
Andrew Sidwell
The Windows port actually isn't GPLv2. The SDL port is, though, but I
don't know how to compile that with cygwin.
The disadvantage of using -mcygwin even then is that one has to
distribute the "cygwin1.dll" file. It is for these reasons that perhaps
I should look into writing an assert() just for Angband that doesn't
need -mcygwin.
Andrew Sidwell
pete m
> >> The first hit led to something that led to
> >>http://cygwin.com/ml/cygwin/2004-06/msg00478.html
> >> "Looks like I can link to /lib/libcygwin.a to resolve it."
>
> > That is, replace -mno-cygwin with -mcygwin.
>
> > Unfortunately, Cygwin license requires that all applications built be
> > OSI-certified open source. Koeneke license causes automatic violation, so the
> > above solution is legal only for V SVN and later (which is GPLV2+, fine).
>
> The Windows port actually isn't GPLv2. The SDL port is, though, but I
> don't know how to compile that with cygwin.
>
> The disadvantage of using -mcygwin even then is that one has to
> distribute the "cygwin1.dll" file. It is for these reasons that perhaps
> I should look into writing an assert() just for Angband that doesn't
> need -mcygwin.
>
What I don't understand is why assert() should fail at all--it is
required by the language, so it doesn't belong in the cygwin library,
but in something more primitive.
If all else fails, you can define assert as:
#define assert(X) true
Getting rid of errno should be a lot easier. I think it only shows up
in the zlib-related stuff.
Kenneth 'Bessarion' Boyd
> On Dec 22, 11:25 am, Andrew Sidwell wrote:
> > Kenneth 'Bessarion' Boyd wrote:
> > > On 2007-12-15 06:07:17, Eddie Grove wrote:
> > >> The first hit led to something that led to
> > >>http://cygwin.com/ml/cygwin/2004-06/msg00478.html
> > >> "Looks like I can link to /lib/libcygwin.a to resolve it."
> >
> > > That is, replace -mno-cygwin with -mcygwin.
> >
> > > Unfortunately, Cygwin license requires that all applications built be
> > > OSI-certified open source. Koeneke license causes automatic violation, so the
> > > above solution is legal only for V SVN and later (which is GPLV2+, fine).
> >
> > The Windows port actually isn't GPLv2. The SDL port is, though, but I
> > don't know how to compile that with cygwin.
> >
> > The disadvantage of using -mcygwin even then is that one has to
> > distribute the "cygwin1.dll" file. It is for these reasons that perhaps
> > I should look into writing an assert() just for Angband that doesn't
> > need -mcygwin.
> >
>
> What I don't understand is why assert() should fail at all--it is
> required by the language, so it doesn't belong in the cygwin library,
> but in something more primitive.
I suspect politics rather than technical concerns.
> If all else fails, you can define assert as:
>
> #define assert(X) true
Assuming appropriate macros supporting the macro PP_CONCAT to allow properly
concatenating __LINE__ without erroring out, something like
#ifdef BAD_ASSERT
#ifndef NDEBUG
#define assert(X) if (!X) {quit(__FILE__ ", " PP_CONCAT("Line ", __LINE__) ); }
#else
#define assert(X)
#endif
#else
#include <assert.h>
#endif
would work. [Turn on BAD_ASSERT for any platforms with known problems, probably
in the makefile. No, this is not a known-good replacement; some work
required.]
Not quite C-standard as you're reimplementing the standard, but arguably
platforms that need this are not standard-compliant anyway.
pete m
wrote:
Yeah, I've defined assert() like that before.
BTW, if you have an if statement in a #define, you should always have
an else just as well, for paranoia:
#define assert(X) if(...) {...} else {}
Kenneth 'Bessarion' Boyd
> BTW, if you have an if statement in a #define, you should always have
> an else just as well, for paranoia:
>
> #define assert(X) if(...) {...} else {}
Assuming early Borland (5.5-) doesn't have to be supported, the most
irrationally cautious way to to wrap it in a block would be
#define assert(X) do {if (...) {...};} while(0)
[The mentioned archaic Borland compilers don't know how to inline this away.]