[solved] conda: win: build-errors 20191201

[UR_]

So this means that azure now uses vs 2019?

log from your build #69:

Screenshot 004.png (52.22 KiB) Viewed 810 times

[wmayer]

linker still uses libboost_program_options.lib

AFAIK this is the static version of the boost library. The name of the import lib of the shared library lacks of the "lib" prefix and may include version name and compiler version in its name, e.g.: boost_program_options-vc141-mt-x64-1_67.lib

Apparently on conda still an older LibPack is used. In the new one provided by apeltauer the pcl cmake stuff has been moved to the LibPack and inside its cmake directory there are two pcl related config files:
PCLConfigVersion.cmake:

Code: Select all

# Check whether the requested PACKAGE_FIND_VERSION is compatible

set(PACKAGE_VERSION 1.9.1)

# Check whether the requested PACKAGE_FIND_VERSION is compatible
if("${PACKAGE_VERSION}" VERSION_LESS "${PACKAGE_FIND_VERSION}")
  set(PACKAGE_VERSION_COMPATIBLE FALSE)
else()
  set(PACKAGE_VERSION_COMPATIBLE TRUE)
  if ("${PACKAGE_VERSION}" VERSION_EQUAL "${PACKAGE_FIND_VERSION}")
    set(PACKAGE_VERSION_EXACT TRUE)
  endif()
endif()

PCLConfig.cmake:

Code: Select all

#
#
#   Helper  to find pcl
#   use this modified version, the original one will mess up the boost 
#   the original one is stored with the name PCLConfig.cmake_org
#  PCL_FOUND - system has pcl lib with correct version


link_directories(${FREECAD_LIBPACK_DIR}/lib)
set(PCL_INCLUDE_DIRS ${FREECAD_LIBPACK_DIR}/include/pcl-1.9)
set(PCL_LIBRARY_DIRS ${FREECAD_LIBPACK_DIR}/lib)

set(PCL_COMMON_LIBRARIES optimized pcl_common_release debug pcl_common_debug)
set(PCL_FEATURES_LIBRARIES optimized pcl_features_release debug pcl_features_debug)
set(PCL_FILTERS_LIBRARIES optimized pcl_filters_release debug pcl_filters_debug)
set(PCL_IO_LIBRARIES optimized pcl_io_release debug pcl_io_debug)
set(PCL_IO_PLY_LIBRARIES optimized pcl_io_ply_release debug pcl_io_ply_debug)
set(PCL_KDTREE_LIBRARIES optimized pcl_kdtree_release debug pcl_kdtree_debug)
set(PCL_KEYPOINTS_LIBRARIES optimized pcl_keypoints_release debug pcl_keypoints_debug)
set(PCL_ML_LIBRARIES optimized pcl_ml_release debug pcl_ml_debug)
set(PCL_OCTREE_LIBRARIES optimized pcl_octree_release debug pcl_octree_debug)
set(PCL_RECOGNITION_LIBRARIES optimized pcl_recognition_release debug pcl_recognition_debug)
set(PCL_REGISTRATION_LIBRARIES optimized pcl_registration_release debug pcl_registration_debug)
set(PCL_SAMPLE_CONSENSUS_LIBRARIES optimized pcl_sample_consensus_release debug pcl_sample_consensus_debug)
set(PCL_SEARCH_LIBRARIES optimized pcl_search_release debug pcl_search_debug)
set(PCL_SEGMENTATION_LIBRARIES optimized pcl_segmentation_release debug pcl_segmentation_debug)
set(PCL_STEREO_LIBRARIES optimized pcl_stereo_release debug pcl_stereo_debug)
set(PCL_SURFACE_LIBRARIES optimized pcl_surface_release debug pcl_surface_debug)
set(PCL_TRACKING_LIBRARIES optimized pcl_tracking_release debug pcl_tracking_debug)

set(PCL_LIBRARIES
    ${PCL_COMMON_LIBRARIES}
    ${PCL_FEATURES_LIBRARIES}
    ${PCL_FILTERS_LIBRARIES}
    ${PCL_IO_LIBRARIES}
    ${PCL_IO_PLY_LIBRARIES}
    ${PCL_KDTREE_LIBRARIES}
    ${PCL_KEYPOINTS_LIBRARIES}
    ${PCL_ML_LIBRARIES}
    ${PCL_OCTREE_LIBRARIES}
    ${PCL_RECOGNITION_LIBRARIES}
    ${PCL_REGISTRATION_LIBRARIES}
    ${PCL_SAMPLE_CONSENSUS_LIBRARIES}
    ${PCL_SEARCH_LIBRARIES}
    ${PCL_SEGMENTATION_LIBRARIES}
    ${PCL_STEREO_LIBRARIES}
    ${PCL_SURFACE_LIBRARIES}
    ${PCL_TRACKING_LIBRARIES}
)
set(PCL_FOUND TRUE)
set(PCL_COMMON_FOUND TRUE)
set(PCL_FEATURES_FOUND TRUE)
set(PCL_FILTERS_FOUND TRUE)
set(PCL_IO_FOUND TRUE)
set(PCL_IO_PLY_FOUND TRUE)
set(PCL_KDTREE_FOUND TRUE)
set(PCL_KEYPOINTS_FOUND TRUE)
set(PCL_ML_FOUND TRUE)
set(PCL_OCTREE_FOUND TRUE)
set(PCL_RECOGNITION_FOUND TRUE)
set(PCL_REGISTRATION_FOUND TRUE)
set(PCL_SAMPLE_CONSENSUS_FOUND TRUE)
set(PCL_SEARCH_FOUND TRUE)
set(PCL_SEGMENTATION_FOUND TRUE)
set(PCL_STEREO_FOUND TRUE)
set(PCL_SURFACE_FOUND TRUE)
set(PCL_TRACKING_FOUND TRUE)

If you compare this with the changes of git commit ead9c5c67080 then the removed content of UseLibPackCLbundler.cmake is almost identical. So you can try to copy the two files to your LibPack on Conda and change the version number to 1.7 and set the include path to:

Code: Select all

set(PCL_INCLUDE_DIRS ${FREECAD_LIBPACK_DIR}/include/pcl-1.7)

In this case you should have the exact same behaviour as before.

But I am not entirely sure that my change caused these problems because pcl is not used in the core system and on Windows the pcl config files do not affect any boost configuration (while on Linux it does because the pcl config files are completely different there).

[wmayer]

But I am not sure if this relates to pcl.

For me it's definitely related as I can make the errors come and go by enable/disable pcl.

But how do the pcl cmake related files look on Conda? The files there must deal with boost in a certain way which the files of the LibPack doesn't do. And I wonder why on Linux systems the pcl doesn't pull in the static boost versions, then.

[UR_]

On my system there is o PCL installed wether by conda nor elsewhere and

Code: Select all

      -D FREECAD_USE_PCL=FALSE 

is set.

Linker error occures even if only FreeCADApp is build, nothing else.

[wmayer]

Linker error occures even if only FreeCADApp is build, nothing else.

But then something else is wrong and it might be related to the newer compiler.

sgrogan said when he switches off pcl support then everything is fine and when enabling it the linker errors occur. I have downloaded the pcl conda version an opened the PCLConfig.cmake file and there I found this code:

Code: Select all

  # use static Boost in Windows
  if(WIN32)
    set(Boost_USE_STATIC_LIBS ON)
    set(Boost_USE_STATIC ON)
    set(Boost_USE_MULTITHREAD )
  endif(WIN32)

So, for Windows pcl forces to use the static boost version and there is no easy way to avoid that.

[looo]

So, for Windows pcl forces to use the static boost version and there is no easy way to avoid that.

So we should rebuild pcl with shared boost libraries?:
https://github.com/PointCloudLibrary/pc ... t.cmake#L4

[wmayer]

So, for Windows pcl forces to use the static boost version and there is no easy way to avoid that.

So we should rebuild pcl with shared boost libraries?:
https://github.com/PointCloudLibrary/pc ... t.cmake#L4

No, the easiest is to use the pcl files of the LibPack (which I assume you did in the past?) and create the PCLConfig.cmake file with the above mentioned content but adjusting its include path to be again 1.7.

If you want to use the newer PCL version this should be also OK but important is then to use the PCLConfig.cmake of the LibPack which just fills up the pcl variables and doesn't do any boost checks.

[looo]

No, the easiest is to use the pcl files of the LibPack (which I assume you did in the past?) and create the PCLConfig.cmake file with the above mentioned content but adjusting its include path to be again 1.7.

No, never build freecad with pcl support previously. There was a recent change in our cmake which enabled pcl by default which lead to the issue mentioned in the first post of this topic. So I tried to enable pcl...

For the freecad-feedstock I really have to use the available resources. Using another build than the available pcl package doesn't make any sense.

If you want to use the newer PCL version this should be also OK but important is then to use the PCLConfig.cmake of the LibPack which just fills up the pcl variables and doesn't do any boost checks.

I guess pcl needs to be build against the same boost version (currently 1.70). So using the package from the libpack is not really an option.

The easiest solution to change the config at build time is using sed. I will try to do so.

[sgrogan]

But then something else is wrong and it might be related to the newer compiler.

sgrogan said when he switches off pcl support then everything is fine and when enabling it the linker errors occur. I have downloaded the pcl conda version an opened the PCLConfig.cmake file and there I found this code:

Thanks for the info.
It seems we do have 2 issues;
For looo and me the error is only present when pcl is enabled (VS2015)
For UR_ the error is independent of pcl (VS2019)
It's strange we get the same error though.

I over came my issues by running cmake-gui > config, and then manually setting the boost paths to the shared libs, then config > generate.
I was able to build FreeCAD and pass all the self tests, I can switch to the ReverseEngineering WB. Is there a way to test if this actually worked and there will not be problems at runtime?

Also is pcl of any use if not using the ReverseEngineering WB?

[sgrogan]

On my system

Can you try to build FreeCAD with VS2019 using the Libpack?
I will eventually try this myself BUT [excuse] I'm still on Win7 and I'm preparing for when I bork my system with the Win10 upgrade [excuse]