I'm trying to use the SkypeKit SDK to create an Objective-C++ project using Xcode 4. I have two compiled libraries from SkypeKit, libskypekit_cyassl_lib.a and libskypekit_cppwrapper_2_lib.a, which I need to be able to use so as to access the Skype API.
I've added in both .a files under 'Linked Frameworks and Libraries' and added -all_load -ObjC -lstdc++ to the 'Other Linker Flags', and that builds okay, but as soon as I try to use any of the methods in those libraries, building fails.
Any help would be greatly appreciated, thank you!
You can call C++ code from Objective-C++, which means that your files should have the .mm extension instead of .m
I assume that this could be the issue, but since you did not specify the errors you get it is just a guess. Specifically, if you call C++ code from a .m file you get compilation errors.
Another possible cause is forgetting to import the header files of the library. For the import to be successful, you also have to add the directory where the headers are to your project "header search path".
If this does not help, please post the error message.
Related
I want to run the example project which is available for free from this link. It is a simple FFT library and needs no compiler. In it, there is an example c file with its required header files and .c files.
When I try to run it in Vivado SDK I get errors of multiple definitions of fft and ifft. How can I run this example inside SDK?
What I had done is created an empty application project and then imported all these files inside src folder and then selected build the project option but didn't succeed in building and running the project.
I guess, looking at the ufft.zip archive, that you've tried to link files issued form the compilation of fft-dit.c and fft-dif.c.
Both files define ftt functions using differents method (see README).
You have to choose betwen using ftt-dif.c or ftt-dit.c, not both.
This is the same for itt-dif.c and itt-dit.c, choose one, not both.
I am trying to call this C library from my Swift code. I dragged the source files into my project and created a module.map file and added the directory containing the module map to Build Settings->Search Paths->Import Paths.
It seems to work. I can import the library and the name even shows up in autocomplete:
And I can access functions from the library and again autocomplete knows they are there:
But when I build, I get this error:
This name, "_mtex2MML_parse", is the same as the name of C function I'm trying to call except prefixed with an underscore.
I've gotten this same error before in similar circumstances trying to get cmark to work, but fixed it there by making sure that the .c file was included in the Target Membership, and then everything was fine. When I fiddled with doing that in this project, I've not had any luck. And in that case, autocomplete didn't even know about the function.
I've tried cleaning, deleting derived data, quitting Xcode, restarting computer, etc. I've tried on Xcode 8.3.3 Swift 3.1 and on Xcode 9b4, Swift 4.0. I'm on macOS 10.12.6. There is no other thing in the project besides this.
Can anyone offer any advice on how to proceed? Thanks.
I'm trying to compile an old project in Borland C++ Builder 4. I have a working exe and the source files for that, therefore someone must have managed to compile it earlier. However, when I open the project, check if the project hs all the necessary files in the resources and try to compile it, I keep getting the following linker error:
[Linker Error] Unresolved external '_fastcall TMapperForm::Button1Click(System::TObject*)' referenced from ...\Unit1.obj
I can see that it cannot find an object in the library but I am not sure how to resolve it, because the obj file with the same name as the main cpp file is in the same file as the other files of the project and seems fine.
I have looked through the answers provided here for similar linker errors but none of what these have suggested worked for me. I have already tried the following:
Adding the .obj file to the Project Resources.
Trying to add pragma lines manually such as #pragma link (Unit1.obj)
Making sure that in Project>Options>Directories the right Include and Library paths were selected.
Checking if all the packages have been added.
None of this seems to work. I am fairly new to C++ and C++ Builder, so I am hoping that it is something trivial.
Has anybody seen this particular error?
The error was caused by a missing handler or more precisely a handler containing nothing.
While the handler for the button contained nothing, the TMapperForm class still included the definitions for an extra button named Button1 but it was not used. Commenting out the method and the declaration in the TMapperForm class (in the header file for Unit1) along with the handler in the C++ file resolved the problem.
I am using the LPCXpresso IDE to program my microcontroller to use the libjpeg library for a particular application. However, I cannot seem to get the LPCXpresso IDE to recognize libjpeg. The way I see it, there are two options:
1) Take the jpeglib.a file, include it as an external library, and then attempt to import jpeglib.h. I have tried this, at the IDE still does not recognize jpeglib.h.
2) Create a new static library from the libjpeg source code. Is this my only option? It seems a bit excessive.
Any tips regarding adding/linking external libraries in LPCXpresso would be greatly appreciated. Thanks!
You can easily add a library to Eclipse/LPCXpresso by creating a new project (not a C project or a LPCXpresso project but a 'normal' project) by clicking File->New->Project. Name is as you wish, let's say 'JPEG'. Add your library file to it under the folder 'lib' (you have to create the folder first). Call the library file 'libJPEG.a'. Also include the header file under the folder 'inc'. It is not mandatory to create these folders by the way, but it makes it all more organised.
The edit the properties of the project that's needs to include the header and library. Right click the project and choose properties. Go to C/C++ Build->Settings->MCU C compiler->Includes and add the include path of the inc folder of the library project. The go to C/C++ Build->Settings->MCU Linker->Libraries and add the library file WITHOUT the lib in front of the file name, hence just JPEG. Also add the library search path below (point to the lib folder).
That's all!
Ok, so here's my question:
I have a working DUB project which produces an application. I decided I also wanted a "library" configuration in my dub.json file:
"configurations": [
{
"name": "application",
"targetType": "executable"
},
{
"name": "library",
"targetType": "library",
}
],
So, now when I build the project using dub build --config=library, it produces a libXXXX.a file in the same directory.
So far, so good.
I tried using this library (actually a tiny test-function marked as extern "C" from a test C app).
So, I compile my C app using gcc -c ctest.c and then link them all together like dmd libMYLIBRARY.a ctest.o.
Now, here is the problem:
In this last step, the linker complains that many symbols are missing - all coming from external dependencies (2 object files and several .a libraries) that would normally be linked when building the project as an application.
So, the question is... how do I solve this?
I mean... Should I just link my test C app against ALL of the original dependencies (this would not make the library very portable admittedly), or is there any way around it, so that anybody could use my library, only by linking against my libXXXXX.a file?
Should I just link my test C app against ALL of the original dependencies (this would not make the library very portable admittedly),
This is the "technically correct" answer. The reason for that is because, otherwise, if the C app wanted to use another D library which had among its dependencies some package that's also a dependency in your library, and if it were linked in the same way (including all of its dependencies in its static library file), this dependency would then occur twice in the linker inputs. Even if you told the linker to discard one copy, there can be problems due to the dependency being of separate incompatible versions, etc. (Note that there is an ongoing D SAOC project to handle this.)
If you were to assume that the only D library the C program will use is your Dub package, then you could conceivably create a static library which includes all dependencies, though it would probably need to include the D standard library and runtime as well.