[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