Re: [openMSX-devel] Compile problems

[Joost Y. D. <j....@qa...>]

'Maarten ter Huurne' wrote about '[openMSX-devel] Compile problems' - Mon, =
Dec 31, 2001 at 03:20:47AM CET
> Hi,
>=20
> I'm having some compile problems the last couple of days. Since there was=
 a=20
> lot of activity and these weren't fixed, I am assuming I am the only one=
=20
> experiencing these compile problems.
>=20
>=20
> The first problem is in CPU.hh: the first section of members is not=20
> explicitly declared public, private or protected. According to r.11 of=20
> Stroustrup's book: "Members of a class declared with the keyword class ar=
e=20
> private by default." However, type CPU::offset is used in Z80::M_JR=20
> (Z80Core.hh, line 1180). So it is necessary to make this type protected (=
or=20
> public). I would suggest getting rid of the implicitly private block=20
> altogether and using explicit access qualifiers for all members.

Yup, explicit access qualifiers should be used.

> By the way, Z80Core.hh is not actually a header file, it is an include fi=
le=20
> for Z80.hh. Shouldn't it be named Z80Core.ii or something?
=20
Z80Core.nn [nested header] is my own invented notation.

Along with a :

#ifndef __Z80_H__
#error use Z80.hh
#endif

This makes for a clean approach imho.

> The second problem is a link problem. In MSXDiskRomPatch.hh the constants=
=20
> A_PHYDIO, A_DSKCHG, A_GETDPB, A_DSKFMT and A_DRVOFF are declared and assi=
gned=20
> a value. However, when linking I get this error:
> MSXDiskRomPatch.o: In function `MSXDiskRomPatch::MSXDiskRomPatch(void)':
> /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/include/new:64: undefined=
=20
> reference to `MSXDiskRomPatch::A_PHYDIO'
> /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/include/new:64: undefined=
=20
> reference to `MSXDiskRomPatch::A_DSKCHG'
> /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/include/new:64: undefined=
=20
> reference to `MSXDiskRomPatch::A_GETDPB'
> /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/include/new:64: undefined=
=20
> reference to `MSXDiskRomPatch::A_DSKFMT'
> /usr/lib/gcc-lib/i586-mandrake-linux-gnu/2.96/include/new:64: undefined=
=20
> reference to `MSXDiskRomPatch::A_DRVOFF'
> collect2: ld returned 1 exit status
>=20
> It can be solved by not assigning a value in MSXDiskRomPatch.hh, but in=
=20
> MSXDiskRomPatch.cc, like this:
> const int MSXDiskRomPatch::A_PHYDIO =3D 0x4010;
> const int MSXDiskRomPatch::A_DSKCHG =3D 0x4013;
> const int MSXDiskRomPatch::A_GETDPB =3D 0x4016;
> const int MSXDiskRomPatch::A_DSKFMT =3D 0x401C;
> const int MSXDiskRomPatch::A_DRVOFF =3D 0x401F;
>=20
> I don't know exactly why this link problem occurs. It has something to do=
=20
> with the addr_list.push_back() calls; if I remove those the error is gone=
.=20
> When doing "nm MSXDiskRomPatch.o", the A_XXX symbols are indeed unresolve=
d,=20
> so the actual problem is not in the linker. That leaves either the code o=
r=20
> the compiler.
>=20
> According to r.9.4 of Stroustrup's book: "Static members of a global clas=
s=20
> have external linkage (r.3.3). The declaration of a static data member in=
 its=20
> class declaration is /not/ a definition. A defitition is required elsewhe=
re;=20
> see also r.18.3." In r.18.3 it says "The definition of a static data memb=
er=20
> of a class for which initialization by default to all zeros applies (r.8.=
4,=20
> r.9.4) may be omitted.", which does not apply, I think.
>=20
> I encountered a problem like this before, which is the reason Renderer.cc=
=20
> exists. However, in many other cases using constants defined in header fi=
les=20
> works, even from other classes. Is that a coincidence or is there some ru=
le I=20
> don't know yet?

a static const member may be given a value in the header.
BTW, does this problem still occur, since I had it, but I fixed it
yesterday and committed it.

I see you're using gcc 2.96... this is a version of gcc that has
some gcc 3.x features and thus behaves a little more strict than
the 2.95.4 Debian uses.=20
Debian also installs gcc 3.0.3 in parallel, which
I should give soon another swing to check if our code is still clean.

Joost.