[ENet-discuss] Three problems building ENet and their solutions
Luke Dean
LukeD at pobox.com
Mon Dec 31 03:43:56 PST 2007
Hi, I'm new to ENet and I just spent half the night trying to build it
into my project, as opposed to building it as an external library and
linking to it. I thought I'd share what I learned.
I had almost no problem at all throwing the code into my project in
FreeBSD and using it. I only had to make one minor change.
In unix.c I had to stick a
#define HAS_SOCKLEN_T
up near the top because one of the system libraries had already made that
definiton. Easy. I even did some quick "hello world" tests just to play
with it.
Then I took that same code and tried to build it on Windows XP using the
GNU MINGW32+MSYS environment.
The first thing it did was complain about an invalid typecast on line 183
of protocol.c. I STFW and found other people who'd had the same problem
and gotten past it by explictly typecasting the assignment.
I did this:
- commandNumber = outgoingCommand -> command.header.command & ENET_PROTOCOL_COMMAND_MASK;
+ commandNumber = (ENetProtocolCommand)(outgoingCommand -> command.header.command & ENET_PROTOCOL_COMMAND_MASK);
I don't know if that's the right solution or not, but it at least makes my
compiler happy.
At this point, everything was compiling. The linker, on the other hand,
was spewing all kinds of horrible nonsense about how several of the
files had "undefined reference to 'enet_list_clear'" and several other
enet_list_* methods. This was after I fixed all the other linker
complaints about how I wasn't linking to windows libraries and socket
libraries and such in my makefile. This was ENet unable to link with
ENet!
This one took me a long time to figure out.
I should mention that I'm using the g++ compiler. I had already read
about the importance of "extern "C"" in the enet.h file when using the
library with a C++ compiler. That advice was given to people who were
building ENet as an external library. I was trying to build it into my
project... Perhaps I needed it in more places?
So I added
#ifdef __cplusplus
extern "C"
{
#endif
to the top of list.h and
#ifdef __cplusplus
}
#endif
to the bottom, and now make doesn't bomb anymore with linker errors. I
wonder if I'll run into this again later if make decides to build the
objects in a different order someday. Perhaps I should reconsider
building ENet as an external library.
Anyway, I think I'm going to like ENet a lot. Thank you for making this
available!
More information about the ENet-discuss
mailing list