I compiled the POCO libraries in VC++, then I used Builder's implib to make libraries for Builder. I added these library files in my application's debug directory, however, linker still throws errors like
Unresolved external 'poco::session::...'
Could you please tell me what is the proper way to import the POCO library in my C++ Builder application?
One way to do it is to build the POCO libraries in C++ Builder directly. The POCO distribution doesn't come with a .cbproj file, but I found that it wasn't too difficult to figure out which files are required and then create my own Poco_Foundation.cbproj in C++ Builder.
If I recall correctly, there are some portions of Poco (involving template specialization) that C++ Builder won't compile. I was able to work around a lot of the compile errors, but I had to just exclude some of the units because they had too many dependencies on the units that don't compile. Most of the problems I found were in the Poco_Net library; I think the Poco_Foundation library compiled pretty easily.
Good luck.
Related
Tools and versions:
Visual Sudio 2017, Google Protobufs 3.11.3, gRPC 1.27.1, vcpkg 2020.02.04, on Microsoft Windows
I used vcpkg to build the Windows native C++ versions of gRPC and protobuf (and other dependencies) for Windows (x86). Everything builds successfully.
When I build my application I include "libprotobuf.lib" as a linker input. However, it doesn't get linked. Instead, my program will only run if the "libprotobuf.dll" is present for the program to load. I don't know of another way to specify that the library should be statically linked.
During the build of my application, I see a lot of warnings like this:
include\google\protobuf\duration.pb.h(220): warning C4251: 'google::protobuf::Duration::_internal_metadata_': class 'google::protobuf::internal::InternalMetadataWithArena' needs to have dll-interface to be used by clients of class 'google::protobuf::Duration'
This page mentions the warnings and says that static linking is the default but it seems like vcpkg isn't building it that way or I need to reference the library a different way.
I've also seen this page that offers a solution. That helped a bit. It made Visual Studio recognize unresolved externals, so at least it was trying to statically link the .lib file(s). With that in place I've tried various combinations of .lib files for protobuf, grpc, and dependencies but I still can't get a successful build - and the compiler warnings are still generated.
I feel like I'm missing something (a pre-processor define maybe) during the vcpkg build that would build the headers or libraries differently. I've tried to change some of the build settings but they're always overwritten when vcpkg generates cmake files for the build.
Or I'm missing the right combination of library files to reference from my project.
Has anyone gotten this to work? If you have examples of building the libraries for static linking via vcpkg, or the correct way to link the libraries in VS2017 project, could you share your information?
Finally got a chance to come back to this. The problem came down to two things:
1. Realizing that you can specify a triplet (as noted in original question).
2. Finally realizing using the static libraries also meant I had to switch my application to static c runtime libraries instead of shared dlls.
I can't switch my application. I've done testing with this non-static mode operation though. I haven't seen any problems, but does anyone else use protobufs (and gRPC this way) - it doesn't appear to be recommended.
I'm working with Embarcadero XE8 C++ builder 32 bit.
I was adding a library to my program for solving the Unresolved external error.
When I added the library I got the error as in the title. So I searched the web and found this topic on stackoverflow:
Linker error "contains invalid OMF record"
As it says the COFF2OMF tool, CAN work. Sadly it didn't work for me, I give a 7mb library file, when I convert it with the tool it's only 41kb... so I guess the convertion failed. When I add the converted files to my program it just ignores it and still says the unresolved external error.
So how can I get my library working with my C++ builder?
A little background:
Libraries need to be compiled with the same kind of tool as the application you are trying to make, because every compiler does things a wee bit differently. Most libraries for Windows are compiled with the MVSC (Microsoft Visual Studio Compiler).
You're using the Embarcardero Compiler, which means that the MVSC libraries are incompatible (you may have noticed that ;)).
You have multiple options.
If you can, get the source of the library and compile it with your own compiler. That way the chance to succeed is the highest.
I may be mistaken since it's been a while, however I believe there's a tool called implib which takes the shared library (.dll) and generates an Embarcardero-style .lib from that for use in your project.
Use COFF2OMF to convert the static library. And even if the file size is strange, do at least try it.
Try the LoadLibrary function call. This one requires you to map the functions you need manually, however you get around using the .lib.
Good luck.
Im helping on a c++ application. The application is very large and is spread out between different sub directories. It uses a script to auto generate qt .pro files for each project directory and uses qmake to then generate make files. Currently the libraries are being compiled in alphabetical order.. which is obviously causing linking errors when a library its trying to link isn't built yet.. Is there some kind of g++ flag i can set so it wont error out if a library its trying to link hasn't been built yet? or a way to make it build dependencies first through the qt .pro file?
NOTE:
This script works fine on ubuntu 10.10 because the statements to build the shared libraries didnt require that i use -l(libraryname) to link to my other libraries but ubuntu 11.10 does so it was giving me undefined reference errors when compiling on 11.10.
Have you looked into using Qt Creator as a build environment and IDE? I've personally never used it for development on Ubuntu, but I have used it on Windows with g++, and it works great there. And it appears its already available as a package in the repository.
Some of the advantages you get by using it are:
Qt Creator will (generally) manage the .pro files for you. (If you're like me, you can still add lots of extra stuff here, but it will automatically add .cpp, .h, and .ui files as they are added to the project.)
You can set up inter-project dependencies that will build projects in whatever order they need to link.
You can use its integration with gdb to step through and debug code, as well as jump to the code.
You get autocomplete on Qt signals and slots, as well as inline syntax highlighting and some error checking.
If you're doing GUIs, you can use the integrated designer to visually layout and design your forms.
Referring back to your actual question, I don't think it's possible for a flag to tell gcc to not error when a link fails simply because there is no way for the linker to lazily link libraries. If its linking to static libraries (.a), then it needs to be able to actually copy the implementation of that code into the executable/library. If its dynamically linking (.so), it still needs to verify that the required functions actually exist in the library. If it can't link it during the linkage step, when can it link?
As a bit of an afterthought, if there are cyclic dependencies in your compile process (A depends on B, B on C, and C on A), then you might need to have a fake version of a library get built first, which only has empty stubs for the implementation of each function, and the full definition for each class or object. Then, build everything else while linking to that, and at the end, build the real version of the fake library, and link it to all the other versions that were already linked. I think this would only work on dynamic linking, though.
You could use a subdirs project to have control over the build order (no matter whether the other dev wants it or not :) ).
E.g.
build_all.pro
TEMPLATE=subdirs
CONFIG+=ordered
SUBDIRS=lib2/lib2.pro lib1/lib1.pro app/app.pro
The lib1.pro, lib2.pro, ... are your generated pro files.
Then run qmake once for the build_all.pro and also run make in that directory. This will build lib2 before lib1 and then app.
I need some help with wrapping C++ libraries in XCode.
What I want to achieve is to create new library in XCode, import C++ library (I have .a and .h files), wrap it to Obj-C so I can import that library to MonoTouch.
The reason why I do it round way is that when I try to import C++ lib into MonoTouch, because of name mangling I keep getting WrongEntryPoint exceptions. Correct me if I'm wrong but there is no way for me to find out mangled names, which depends on compiler.
Thank you in advance
Correct me if I'm wrong but there is no way for me to find out mangled names, which depends on compiler.
Technically you could. Many compilers share the same mangling syntax, maybe the most useful and long-lasting gift from Itanium ;-)
However it will bring it's own pain (e.g. non-primitive types, other compilers) and maintenance issues as you update your C++ code.
You'll better served by:
writing an ObjectiveC wrapper and use MonoTouch's btouch tool to generated bindings;
writing a C wrapper and using .NET p/invoke to call your code;
The choice it yours but if you think about reusing the C++/C# code elsewhere (e.g. Mono for Android) then using C and p/invoke will be reusable.
I would definitely recommend going the route of wrapping the library in an Obj-C library and using btouch to import the library into MonoTouch. I have recently done this for a C++ library that implemented a Sybase database engine. If you look at my questions you will find quite a few pertaining to wrapping C++ libraries as I posted a few times regarding issues I encountered.
Specifically, you can look at these questions:
Linking to a C++ native library in MonoTouch
Wrapping a C++ library in Objective-C is not hiding the C++ symbols
Application with static library runs on simulator but not on actual device
Undefined symbols when linking PhoneGap static library in MonoTouch
Linker options 'Link all assemblies" and "Link SDK assemblies only" causes undefined symbols in 3rd party static library
I would also recommend, if you are going to go the route of an Obj-C wrapper, that you get btouch to output code and include that in your project rather than including a dll from btouch. From my experience, the code worked more reliably than the dll, although the issues with the dll may have been resolved by now. But take a look at this question regarding the btouch issue:
Exception System.InvalidCastException when calling a method bound with btouch that returns an object. MonoTouch bug?
If you have specific questions/problems in building the Obj-C wrapper then ask them here and post some code and I am sure that I or other members of the community would be able to help you with it.
Bruce, as you assumed, I have problems with wrapping C++ code. After hours and hours of reading and trying, I couldn't wrap the C++ code.
Anyway, I managed to create a simple Obj-C library made of some dummy class, and then import it into another library. That worked fine. However, following same pattern, I included C++ .a file along with .h file (I'm not sure whether .h is mandatory because we can link header files in build options, right??) and when I compiled it, it went fine, the build succeeded, but XCode didn't produce new .a library.
I added linker flags: -ObjC -lNameOfLib
Does C++ Standard Library Type in Build - Linking has to be Static? And Symbols Hidden By Default as well?
It would be great if we could write step-by-step tut, since there are tons of various instructions, but I haven't been able to push it through the end.
I'm confused a bit..
Thank you guys...
I need some advice on my project. I am going to use various C++ libraries to accomplish different tasks. I am using Visual Studio 2008. To me, it seems to get a little out of hand when I add the actual source code of the library to my project's path.
It seems easier to just use the include files of the library, and just link precompiled binaries to my application. So my question is this. Is it better for me to include the source code of each library to my project, compile and link, or will it be better to just compile the libraries separately (or download a precompiled version) and link it to my program? Are there any pitfalls of the second way?
Thanks
If a library is available use it.
With C++ and windows you may have to rebuild the library if it was built with a different compiler, there are issues linking C++ libs between gcc/mingw and visual studio.
but in general there is no reason to add the source to your code base.
Depending on the particular library, you might want to be able to debug it. Just downloading precompiled libraries and no source might make that difficult.