How to build dependent library that depends on another library?
-
I have an unintuitive C library that I have wrapped using C++ into another library. I then need this library to be built and included in my Qt GUI application.
I have first tried to build the wrapper library as a shared library and include that in my core application but when building it is unable to find the original C dependencies within the C++ wrapper library and therefore does not build.
I am doing this the correct way? I also read somewhere about using .pri so that when I build my application it would build the C++ wrapper library first using the .pri file but I am not sure how I would then access the build .lib and .dll files from it.
Any help would be appreciated please.
@AaronKelsey You need to link against the C library as well, not only your wrapper library.
-
@AaronKelsey You need to link against the C library as well, not only your wrapper library.
So this is what I currently have in my core application .pro file
CONFIG(debug, debug|release) { LIBS += C:\cygwin64\home\admin\CertTool\sslcertificate\test\lib\debug\opensslwrap.lib } CONFIG(release, debug|release) { LIBS += C:\cygwin64\home\admin\CertTool\sslcertificate\test\lib\release\opensslwrap.lib }Are you saying that even though the C++ library wrapper contains the C includes, I should also add the include directory in the core application .pro like this?
CONFIG(debug, debug|release) { LIBS += C:\cygwin64\home\admin\CertTool\sslcertificate\test\lib\debug\opensslwrap.lib LIBS += C:\Tools64\v2.0.9\openssl-1.0.2p\lib\debug\ssleay-1_0_2.lib LIBS += C:\Tools64\v2.0.9\openssl-1.0.2p\lib\debug\libeay-1_0_2.lib } CONFIG(release, debug|release) { LIBS += C:\cygwin64\home\admin\CertTool\sslcertificate\test\lib\release\opensslwrap.lib LIBS += C:\Tools64\v2.0.9\openssl-1.0.2p\lib\release\ssleay-1_0_2.lib LIBS += C:\Tools64\v2.0.9\openssl-1.0.2p\lib\release\libeay-1_0_2.lib } -
So this is what I currently have in my core application .pro file
CONFIG(debug, debug|release) { LIBS += C:\cygwin64\home\admin\CertTool\sslcertificate\test\lib\debug\opensslwrap.lib } CONFIG(release, debug|release) { LIBS += C:\cygwin64\home\admin\CertTool\sslcertificate\test\lib\release\opensslwrap.lib }Are you saying that even though the C++ library wrapper contains the C includes, I should also add the include directory in the core application .pro like this?
CONFIG(debug, debug|release) { LIBS += C:\cygwin64\home\admin\CertTool\sslcertificate\test\lib\debug\opensslwrap.lib LIBS += C:\Tools64\v2.0.9\openssl-1.0.2p\lib\debug\ssleay-1_0_2.lib LIBS += C:\Tools64\v2.0.9\openssl-1.0.2p\lib\debug\libeay-1_0_2.lib } CONFIG(release, debug|release) { LIBS += C:\cygwin64\home\admin\CertTool\sslcertificate\test\lib\release\opensslwrap.lib LIBS += C:\Tools64\v2.0.9\openssl-1.0.2p\lib\release\ssleay-1_0_2.lib LIBS += C:\Tools64\v2.0.9\openssl-1.0.2p\lib\release\libeay-1_0_2.lib }@AaronKelsey said in How to build dependent library that depends on another library?:
Are you saying
Yes, how else can it work? Your C++ library is a wrapper, it does not contain the C library itself. So, you have to link against the C library as well.
-
@AaronKelsey said in How to build dependent library that depends on another library?:
Are you saying
Yes, how else can it work? Your C++ library is a wrapper, it does not contain the C library itself. So, you have to link against the C library as well.
@jsulm I guess I just presumed when I built the library wrapper into a .dll and .lib it would contain the path to the original C library. This is my first time creating libraries so I was unsure.
How can I create my application so that when I build it automatically builds the C++ wrapper into the application, without having to pre-build the C++ wrapper and then copying the files into the application directory?
-
@jsulm I guess I just presumed when I built the library wrapper into a .dll and .lib it would contain the path to the original C library. This is my first time creating libraries so I was unsure.
How can I create my application so that when I build it automatically builds the C++ wrapper into the application, without having to pre-build the C++ wrapper and then copying the files into the application directory?
https://wiki.qt.io/SUBDIRS_-_handling_dependencies explains the concept.
Just make sure to ignore the section
CONFIG+=ORDEREDif you don't want to kill kittens: https://blog.rburchell.com/2013/10/every-time-you-configordered-kitten-dies.html -
https://wiki.qt.io/SUBDIRS_-_handling_dependencies explains the concept.
Just make sure to ignore the section
CONFIG+=ORDEREDif you don't want to kill kittens: https://blog.rburchell.com/2013/10/every-time-you-configordered-kitten-dies.html -
@aha_1980 Thank you. Could you please explain the difference between using SUBDIRS and .pri files? I was under the impression you included the path to the .pri to build the library.
A .pri file is just an "project include file". It contains variables that you want to share between different .pro files.
-
A .pri file is just an "project include file". It contains variables that you want to share between different .pro files.
@aha_1980 So if my library were only to be used by my core application then I should leave it as a .pro, but if another project within the application requires the library it would be best to make the library a .pri?
-
@aha_1980 So if my library were only to be used by my core application then I should leave it as a .pro, but if another project within the application requires the library it would be best to make the library a .pri?
@AaronKelsey said in How to build dependent library that depends on another library?:
but if another project within the application requires the library it would be best to make the library a .pri?
No. All projects are always in a pro file. A pri file is used to share common definitions between the project. E.g.
VERSION=1.2.3. If you define this in a pri file, all projects can use that information.Think of a pri file like a C++ header file for projects.
-
@aha_1980 So if my library were only to be used by my core application then I should leave it as a .pro, but if another project within the application requires the library it would be best to make the library a .pri?
@AaronKelsey One note: if the only application using this C++ wrapper is the one you're currently developing, then you can simply make this wrapper part of your application project (so, no shared library).
