We have had users use wolfSSL on VxWorks before, and I believe last time we checked (which was on an older version), there weren't any changes required to the wolfSSL code base in order to get the library to build. It may be that something has changed in newer versions of VxWorks.
By default wolfSSL assumes a BSD-style socket API is available (ie: send(), recv()). It sounds like you may not have those available, or that there is a setting in VxWorks which enables them (but are disabled by default). In the case where they are not available, wolfSSL includes an I/O abstraction layer. This allows a user to write their own Send and Receive callbacks. More info on this can be found in Section 5.1.2 of the wolfSSL Manual:
http://wolfssl.com/yaSSL/Docs-cyassl-ma … ility.html
If you don't have opendir() available, you can define NO_WOLFSSL_DIR when compiling wolfSSL.
We do ship Visual Studio project files for wolfSSL with each release. These are located in the root of the download package. It's usually pretty easy to pull wolfSSL into a new build environment as well, and is outline in Section 2.4 of the wolfSSL Manual:
http://wolfssl.com/yaSSL/Docs-cyassl-ma … yassl.html