If you are including the .h file for the .c file in your .cpp file and it
doesn't already have extern "C" in it, wrapping it like this when including it
in your cpp should help:
extern "C"
{
#include "header.h"
}
Sent from my Verizon Wireless 4G LTE smartphone
Original message
Or make c++ wrappers that use dlopen/dlsym or loadlibrary/getprocaddress as
appropriate and reference the libs through an interface class.
On Fri, Jun 5, 2015 at 7:44 PM, J Decker wrote:
> it's not the lib, it's the header interface to the lib.
>
> On Fri, Jun 5, 2015 at 7:42 PM, Sunrise wrote:
it's not the lib, it's the header interface to the lib.
On Fri, Jun 5, 2015 at 7:42 PM, Sunrise wrote:
> Thanks for your reply. I am aware of extern "C" {} but this is not an
> option for me. As I mentioned, there are a lot of lib files (which were not
> written by me) and I was wondering if li
Thanks for your reply. I am aware of extern "C" {} but this is not an
option for me. As I mentioned, there are a lot of lib files (which were
not written by me) and I was wondering if lib itself could be untouched.
On 06/05/2015 07:33 PM, J Decker wrote:
c++ does name mangling on functions... s
c++ does name mangling on functions... so functions like 'f' become a much
more complex name (as shown in the xxx not found in your error messages).
In order for C++ to not produce a mangled name C functions have to be
defined as
extern "c" void f( void );
but 'extern "c"' is not liked by C... so
Hello,
I am linking my code to a library. My code is in C++ but the library is
in C.
The problem is that whenever the extension of library implementations
are "c" (not cpp), they are not linked and I get "undefined reference
to" error.
Here is an example:
Suppose I have
./src/main.cpp //
Am Donnerstag, 4. Juni 2015, 15:53:11 schrieb Ette, Anthony:
> Ok I've got this installed but can't get it to work. I've selected the
Please discuss this on the appropriate mailing list.
https://groups.google.com/forum/#!forum/cmake4eclipse-users
Martin
--
Cd wrttn wtht vwls s mch trsr.
-
Hello, CMake users.
I'm running into an error trying to cross-compile Icinga2 for OpenWRT.
The root of this issue is that there are helper programs compiled to
help complete the compilation (I believe these are called generators).
I have understood that I can compile on my native system, then som
I was using add_custom_command to execute three commands, triggering
that rule with add_custom_target, and it worked great with make and
ninja on linux and mac.
Over on Windows, though, with visual c++ 2013 and cmake 3.0.1, only
the first of the three commands was executed.
After much head-scratch
On Fri, Jun 5, 2015 at 9:03 AM, Robert Maynard
wrote:
...
>
> * The "Visual Studio 7" generator (.NET 2002) is now deprecated and
> will be removed in a future version of CMake.
>
> * The "Visual Studio 6" generator is now deprecated and will be
> removed in a future version of CMake.
>
...
A
I am proud to announce the first CMake 3.3 release candidate.
Sources and binaries are available at:
http://www.cmake.org/download/
Documentation is available at:
http://www.cmake.org/cmake/help/v3.3
Release notes appear below and are also published at
http://www.cmake.org/cmake/help/v3.3/
11 matches
Mail list logo