OSG integration with QT...Trouble linking libraries.

SGaist

With Visual Studio, if you have a shared library and you want to be able to use a class/method from another application/library, you have to export it properly.

You can see more details about that here.

mBiz

@SGaist it was to my understanding I was building OSG as a static lib.
I am able to build and execute the application using CMakelists, but I'm trying to convert it to a .pro file for experimental reason.

SGaist

Ok, then are you linking them in the correct order ?

mBiz

This post is deleted!

mBiz

@SGaist I would like to think so. I was linking them the way i commented above but that was wrong so i went and changed it. But no results. same errors
LIBS += -L"C:/Packages/VC14/osg-3.5.1-qtcreator/lib" -losg141-osg
-lot20-OpenThreads
-losg141-osgAnimation
-losg141-osgDB
-losg141-osgFX
-losg141-osgGA
-losg141-osgManipulator
-losg141-osgParticle
-losg141-osgPresentation
-losg141-osgQt
-losg141-osgShadow
-losg141-osgSim
-losg141-osgTerrain
-losg141-osgText
-losg141-osgUI
-losg141-osgUtil
-losg141-osgViewer
-losg141-osgVolume
-losg141-osgWidget

SGaist

And the exact same application builds properly with cmake ?

mBiz

@SGaist
Yes. With CMake I can run it just fine.
Could it be because I have not linked the plugins?

SGaist

Which plugins are you referring to ?

mBiz

@SGaist 0_1478558672144_upload-789a9b9f-9e5e-4bde-9100-687d3b1c5483

0_1478558684171_upload-8adf3c55-f061-4cb5-a7cd-4ed82e2916e8

First is the page of lib folder
2nd is the plugins.

Fixing the order of the libraries got rid of the remaining LNK2001 errors i had.
Now all I have left is 7 LNK2019 errors similar to the original post

mBiz

@SGaist i thought i attached the images but i hadnt seen they arent visible. I will link them first hting in the morning. I appreciate the input greatly.
Thank you

SGaist

The upload feature is currently broken so you have to use an image sharing site in between.

mBiz

@SGaist [url=https://postimg.org/image/a2npfn1en/][img]https://s3.postimg.org/a2npfn1en/osglib.png[/img][/url]

[url=https://postimg.org/image/w341w9k2n/][img]https://s3.postimg.org/w341w9k2n/plugins.png[/img][/url]

[url=https://postimage.org/]image hosting over 5mb[/url]
there are more plugins but the ones I use are
osgdb_osg
osgdb_serializers_osg
osgdb_ply
osgdb_3ds
osgdb_stl
osgdb_obj)
osgdb_bmp
osgdb_bvh
osgdb_cfg
osgdb_dxf
osgdb_glsl
osgdb_tga
osgdb_png
osgdb_jpeg
osgdb_tiff
osgdb_gif
osgdb_freetype

mBiz

@SGaist https://postimg.org/image/gqmzyjptp/
https://postimg.org/image/9op2ccm7x/

SGaist

Can you compare the link line you have between your cmake project and your qmake project ?

mBiz

@SGaist I went an added all the plugins in the order the CMakelist does it and it didnt fix any errors. The problems seem. THe remaining errors have to do with
osg::Matrixd
osg::Matrixf

osgVolume::Volume
osgVolume::Layer
osg::Group
osg::BoundingSphereImpl

I was able to eliminate another error by simply linking the libraries before certain statements in the .pro file but im still at 6 errors

I had 2 additional errors previously at
osg::Sphere
osg::Vec3f
but I was able to get this remove by simply moving my LIBS statement higher up in the .pro.
What i dont understand is that even though im using a .pri file and including in every subproject, unless i directly add the libraries to the .pro file more errors persist

SGaist

Check the order of the libraries you are linking, when building with static libraries it is important.

mBiz

I have. The order is identical to the CMakeList.
What im noticing though is that depending on where i call the LIBS i get more LNK2019 errors.

What is the ideal way to import Libraries on a high level thus that the subproject inherit them.

I have included the OSG libs in every subproject and in my .pri file that I am currently adding to every project.

mBiz

isnt a .pri file just an extension of a .pro ?
my first statement in every .pro file is including the .pri which then has the dependecies and includepaths/depedentpath and libs set up.
But I get less LNK2019 errors when i directly go and add the LIBS to the .pro in every subproject.

If what im saying is unclear. Ill try another explanation.
in my 5 subprojects i copy pasted the OSG LIBS in the right order. Which minimized my LNK2019 errors. At the same time I include a .pri file that calls OSG LIBS anyway. With that set up I received 6 LNK2019 errors.
IF i remove the LIBS call in every .pro, and just call it in my .pri file. I receive 26 Lnk2019 errors

SGaist

No, a .pri file follows exactly the same patterns as a .pro file. The difference is purely that .pri files are meant to be included in other .pro/.pri files while .pro files represent the project itself.

However, if you have other LIBS statement in your .pro files then you should include your .pri file after that. The point where you include your .pri files depend on what you are doing in that .pri file. e.g. if you modify the TARGET variable then you should include that .pri file after you have setup TARGET in your .pro file.

mBiz

my .pro files follow the following format

include .pri

target <project name>
template = lib
Config += staticlib
DEFINES += <name>

sources

headers

my .pri file looks like this

QT += core gui opengl widgets
LIBS -L<path to osg> -l<lib>
...
-l<last osg lib>

includepaths
dependentpaths

Then i use the following code to set my dependencies as my main is in a subproject and i want to link the other lib subprojects to the app. the following code below seems to work just fine.
TARGET_DIRECTORY_NAME = 0 #The target directory name (just the project folder name)
TARGET_PATH = 0 #The path to the project directory from the root folder
LIB_PATH = 0 #The path to the LIB

[The MACRO]

The "dep" variable that is used in these two for loops will hold the paramaters from the DEPENDENCY_PROJECT.

From the example above this would hold projectX and projectY (a litteral string)

Now this function will loop through all the parameters

[Setup the Dependencies]

for(dep, DEPENDENCY_PROJECT) {
TARGET_NAME = $${dep} # The name of the depending target
message($${TARGET}.depends = $${TARGET_NAME})
$${TARGET}.depends += $${TARGET_NAME}
}

[setup the actual library dependencies]

for(dep, DEPENDENCY_PROJECT) {
TARGET_NAME = $${dep} # The name of the depending target
TARGET_PATH = $${PWD} # The path to the depending target source
LIB_PATH = $${OUT_PWD}/../$${TARGET_NAME} # The path to the depending compiled target
#message(Depending target "$${TARGET_NAME}" source path: $${TARGET_PATH})
#message(Depending target "$${TARGET_NAME}" compiled path: $${LIB_PATH})

# Adds the wanted lib to the linker
win32:CONFIG(release, debug|release): LIBS += -L$${LIB_PATH}/release/ -l$${TARGET_NAME}
else:win32:CONFIG(debug, debug|release): LIBS += -L$${LIB_PATH}/debug/ -l$${TARGET_NAME}
#message(Depending lib to linker "$$LIBS")

# Adds the wanted lib to the project.
INCLUDEPATH += $${TARGET_PATH}
#message(INCLUDEPATH: $${INCLUDEPATH})

# Adds a dependpath to the project
# This forces a rebuild if the headers change
DEPENDPATH += $${TARGET_PATH}
#message(DEPENDPATH: $${DEPENDPATH})

#Pre target
PRE_TARGETDEPS += $${PWD}/$${dep}
message(PRE_TARGETDEPS: $${PRE_TARGETDEPS})

}