Exult Forum

In file included from Flex.cc:27:
Flex.h: In copy constructor 'Flex::Flex(const Flex&)':
Flex.h:55: error: 'memcpy' is not a member of 'std'
Flex.h:56: error: 'memcpy' is not a member of 'std'
Flex.h: In member function 'Flex& Flex::operator=(const Flex&)':
Flex.h:63: error: 'memcpy' is not a member of 'std'
Flex.h:64: error: 'memcpy' is not a member of 'std'
make[3]: *** [Flex.lo] Error 1
make[3]: Leaving directory `/home/rpmbuild/exult/exult-1.2/files'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/rpmbuild/exult/exult-1.2/files'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/rpmbuild/exult/exult-1.2'
make: *** [all] Error 2

----

I tried adding

#include
and
using namespace std;

to files/Flex.h but still fails with the same errors. Can anyone point me in the right direction to fix this? I am currently compiling this on Fedora 10 Beta. Thanks.

Are the sources uploaded in the download section snapshots of the latest? I want to say I remembered reading that some where but I can't find the source. With that said, is this new compiling errors something that has been happening recently?

./configure runs fine but make fails with above.

/me wonders if #include will fix it

/me wonders if #include will fix it

No. For one, it is a deprecated form (the correct form for C++ would be "#include "), for the other, std::memcpy is actually at cstring; so adding "#include " should fix it.

The snapshot sources in the download section is the latest, and it is the one I would recommend; the 1.2 release has a lot of bugs since fixed in the snapshots, including most compilation problems with GCC 4.3.x like the one you are having (as IIRC, Fedora 10 uses GCC 4.3.x).

Perfect. cstring worked

Now I get...

Table.cc: In member function 'void Table::IndexTableFile()':
Table.cc:57: error: 'exit' is not a member of 'std'

Adding #include to Table.cc worked.

Now I get:
In file included from IFF.cc:24:
IFF.h: In copy constructor 'IFF::IFFhdr::IFFhdr(const IFF::IFFhdr&)':
IFF.h:39: error: 'memcpy' is not a member of 'std'
IFF.h:40: error: 'memcpy' is not a member of 'std'
IFF.h: In member function 'IFF::IFFhdr& IFF::IFFhdr::operator=(const IFF::IFFhdr&)':
IFF.h:45: error: 'memcpy' is not a member of 'std'
IFF.h:46: error: 'memcpy' is not a member of 'std'
IFF.cc: At global scope:
IFF.cc:41: error: 'std::memcmp' has not been declared
IFF.cc:42: error: 'std::memset' has not been declared
IFF.cc: In member function 'void IFF::IndexIFFFile()':
IFF.cc:58: error: 'memcmp' was not declared in this scope
IFF.cc:88: error: 'memset' was not declared in this scope

*goes back to compiling*

Adding #include now gives

In file included from IFF.cc:24:
IFF.h: In copy constructor 'IFF::IFFhdr::IFFhdr(const IFF::IFFhdr&)':
IFF.h:39: error: 'memcpy' is not a member of 'std'
IFF.h:40: error: 'memcpy' is not a member of 'std'
IFF.h: In member function 'IFF::IFFhdr& IFF::IFFhdr::operator=(const IFF::IFFhdr&)':
IFF.h:45: error: 'memcpy' is not a member of 'std'
IFF.h:46: error: 'memcpy' is not a member of 'std'
In file included from IFF.cc:24:
IFF.h: In copy constructor 'IFF::IFFhdr::IFFhdr(const IFF::IFFhdr&)':
IFF.h:39: error: 'memcpy' is not a member of 'std'
IFF.h:40: error: 'memcpy' is not a member of 'std'
IFF.h: In member function 'IFF::IFFhdr& IFF::IFFhdr::operator=(const IFF::IFFhdr&)':
IFF.h:45: error: 'memcpy' is not a member of 'std'
IFF.h:46: error: 'memcpy' is not a member of 'std'


One of the main reasons I want the 1.2 "stable" release is so we can include this into the Fedora repos.

If needed, I am documenting all of this, and can supply patches if needed to help get this going under the GCC 4.3.

Just keep adding either:

#include
or
#inlcude

When you get to the actors.cc errors there is/was a patch at http://www.math.leidenuniv.nl/~wpalenst ... tors.patch which should get it to compile.

It's a total kludge job but it should compile.

Version 1.4 is better

I tried compiling 1.4 (after running the autogen.sh) and it failed as well. ;(

If 1.4 is better, is the exult team looking to release a stable version anytime soon?

Thanks!

How did the 1.4 compilation fail?

@djolk

Thanks for the response! I did that and got very far. Now I am stuck at the following:
/usr/lib/gcc/x86_64-redhat-linux/4.3.2/../../../../include/c++/4.3.2/backward/backward_warning.h:33:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
In file included from bodies.cc:28:
../hash_utils.h:32: error: 'std::hash_map' has not been declared
In file included from bodies.cc:28:
../hash_utils.h:50: error: 'std::hash_set' has not been declared
In file included from bodies.cc:29:
../game.h:60: error: ISO C++ forbids declaration of 'hash_map' with no type
../game.h:60: error: expected ';' before '<' token
../game.h:61: error: ISO C++ forbids declaration of 'hash_map' with no type
../game.h:61: error: expected ';' before '<' token
bodies.cc: In static member function 'static int Body_lookup::find(int, int&, int&)':
bodies.cc:426: error: expected initializer before '<' token
bodies.cc:431: error: 'htable' was not declared in this scope
bodies.cc:434: error: expected type-specifier before 'hash_set'
bodies.cc:434: error: expected `;' before 'hash_set'
bodies.cc:458: error: 'hash_set' was not declared in this scope
bodies.cc:458: error: expected primary-expression before 'short'
bodies.cc:458: error: expected `;' before 'short'
bodies.cc:463: error: 'it' was not declared in this scope
bodies.cc:463: error: 'htable' was not declared in this scope



-----------------

@Marzo
That was my fault. I didn't have libtool installed. It was at the very beginning of the autogen script. Everything worked fine after that.

@Marzo

I lied... It was compiling perfectly as I was posting. autogen worked and so did configure. When I did make, it ran for a good while but failed here:

/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:51: undefined reference to `XQueryTree'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:53: undefined reference to `XFree'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:59: undefined reference to `XGetWindowAttributes'
xdrag.o: In function `Xdnd':
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:88: undefined reference to `XInternAtom'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:89: undefined reference to `XInternAtom'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:90: undefined reference to `XInternAtom'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:91: undefined reference to `XInternAtom'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:93: undefined reference to `XInternAtom'
xdrag.o:/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:94: more undefined references to `XInternAtom' follow
xdrag.o: In function `Xdnd::select_msg(XSelectionEvent&)':
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:258: undefined reference to `XGetAtomName'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:275: undefined reference to `XGetWindowProperty'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:307: undefined reference to `XFree'
xdrag.o: In function `Xdnd::client_msg(XClientMessageEvent&)':
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:132: undefined reference to `XGetAtomName'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:190: undefined reference to `XSendEvent'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:154: undefined reference to `XGetWindowProperty'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:200: undefined reference to `XConvertSelection'
xdrag.o: In function `Xdnd':
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:108: undefined reference to `XChangeProperty'
/home/rpmbuild/exult/exult-svn/exult/xdrag.cc:108: undefined reference to `XChangeProperty'
collect2: ld returned 1 exit status
make[2]: *** [exult] Error 1
make[2]: Leaving directory `/home/rpmbuild/exult/exult-svn/exult'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/rpmbuild/exult/exult-svn/exult'

Ah, yes; that is a know problem for which we have found a portable solution. You can make it work by following the instructions I give in this thread.

Perfect. That worked with 1.4 Marzo. The only problem I have now is that 1.4 is devel, and not considered stable. Is there a timeframe we are looking to get 1.4 as a stable release? Better yet, how often is the SVN 1.4 tar ball updated?

Thanks for the help!

The 1.4 tarball is updated whenever there are source changes; IIRC, it is done automatically (but wjp can correct me if I am wrong). There haven't been many changes lately, but is just because I am busy with other things (and probably the same for the other team members, but I won't speak for them), but that isn't something that can be relied on.

There is, as of now, no schedule for a 1.4 release (which will probably be 1.5 or something). It has been talked a couple times, and suggested a few more, but no definite consensus has been formed (other than waiting until some things related to mods get done).

I must make the note that, except for a few times when the changes make Exult unstable for a couple of weeks, the 1.4.x version works much better overall than 1.2; there hasn't, in fact, been an update to 1.2 source for quite a while, and all its bugs are still there (but most have been fixed in 1.4.x).

I have been recommending 1.4.x over 1.2 for quite some time; but if Fedora must stay with 1.2, I will help fix whatever needs to be fixed to get it to compile in GCC 4.3.x. But if you decide to switch to 1.4.x, you will be the first major distribution that I know of which uses 1.4.x; in this case, I would recommend compiling without Exult Studio support (as ES is the most likely to change in a way that breaks compatibility between both) or having a package for ES matching (and depending on) the corresponding Exult version.