search

dividiti / ck-caffe

Collective Knowledge workflow for Caffe to automate installation across diverse platforms and to collaboratively evaluate and optimize Caffe-based workloads across diverse hardware, software and data sets (compilers, libraries, tools, models, inputs):
http://cKnowledge.org
BSD 3-Clause "New" or "Revised" License
193 stars 40 forks source link

Clean up Boost dependencies in classification and detection programs #113

Open psyhtest opened 7 years ago

psyhtest commented 7 years ago

I've found several issues with the Boost dependencies in the Caffe classification and detection programs (caffe-classification, caffe-classification-cuda, caffe-classification-opencl, caffe-detection-ssd, caffe-detection-ssd-cuda).

  1. Boost is specified twice as follows:

    "boost": {
  "local": "yes",
  "name": "Boost C++ libraries",
  "skip_from_bat": "yes",
  "sort": 30,
  "tags": "lib,boost"
},
...
"lib-boost": {
  "force_add_static_lib_path": "yes",
  "local": "yes",
  "name": "Boost library",
  "sort": 13,
  "tags": "lib,boost"
},

    Apart from the obvious name difference, the first dependency specifies "skip_from_bat": "yes", while the second dependency specifies "force_add_static_lib_path": "yes". Removing the first dependency seems not to affect anything at compile or runtime on Linux. But I'm cautious not to commit this change until we understand possible implications on Windows and Android.

  2. With the lib-boost sort order of 13, using a non-system Boost installed via CK (e.g. ck install package:lib-boost-1.62.0) results in the following link warnings:

    g++-5     classification.o  -o classification    -L/home/anton/CK_TOOLS/lib-caffe-bvlc-master-cpu-master-gcc-5.4.0-linux-64/install/lib -lcaffe  -L/home/anton/CK_TOOLS/lib-gflags-2.2.0-gcc-5.4.0-linux-64/install/lib -lgflags -L/usr/lib/x86_64-linux-gnu  -lglog  -L/home/anton/CK_TOOLS/lib-openblas-0.2.19-gcc-5.4.0-linux-64/install/lib -lopenblas  -L/home/anton/CK_TOOLS/lib-protobuf-host-3.1.0-linux-64/install/lib -lprotobuf  -L/usr/lib/x86_64-linux-gnu -lopencv_core -L/home/anton/CK_TOOLS/lib-boost-1.62.0-gcc-5.4.0-linux-64/install/lib  -L/home/anton/CK_TOOLS/lib-rtl-xopenme-0.3-gcc-5.4.0-linux-64/lib -lrtlxopenme   -lglog -lboost_thread -lboost_date_time -lboost_filesystem -lboost_system -lopencv_imgproc -lopencv_highgui -lopencv_core    -lm    
/usr/bin/ld: warning: libboost_system.so.1.62.0, needed by /home/anton/CK_TOOLS/lib-caffe-bvlc-master-cpu-master-gcc-5.4.0-linux-64/install/lib/libcaffe.so, may conflict with libboost_system.so.1.58.0
/usr/bin/ld: warning: libboost_thread.so.1.62.0, needed by /home/anton/CK_TOOLS/lib-caffe-bvlc-master-cpu-master-gcc-5.4.0-linux-64/install/lib/libcaffe.so, may conflict with libboost_thread.so.1.58.0
***************************************************************************************

    and a runtime failure suggesting the conflict does happen:

    (run ...)
executing code ...
./tmp-SujpBs.sh: line 38: 10861 Aborted                 (core dumped) ./classification ${CK_CAFFE_MODEL_FILE} ${CK_CAFFE_MODEL_WEIGHTS} ../imagenet_mean.binaryproto ../synset_words.txt /home/anton/CK_REPOS/ctuning-datasets-min/dataset/image-jpeg-dnn-cropped-panda/cropped_panda.jpg > tmp-output1.tmp 2> tmp-output2.tmp

(printing output files) 

* tmp-output1.tmp

* tmp-output2.tmp

  terminate called after throwing an instance of 'std::bad_alloc'
    what():  std::bad_alloc

    Changing the sort order to 6 eliminates the warnings:

    g++-5     classification.o  -o classification    -L/home/anton/CK_TOOLS/lib-caffe-bvlc-master-cpu-master-gcc-5.4.0-linux-64/install/lib -lcaffe  -L/home/anton/CK_TOOLS/lib-gflags-2.2.0-gcc-5.4.0-linux-64/install/lib -lgflags -L/home/anton/CK_TOOLS/lib-boost-1.62.0-gcc-5.4.0-linux-64/install/lib -L/usr/lib/x86_64-linux-gnu  -lglog  -L/home/anton/CK_TOOLS/lib-openblas-0.2.19-gcc-5.4.0-linux-64/install/lib -lopenblas  -L/home/anton/CK_TOOLS/lib-protobuf-host-3.1.0-linux-64/install/lib -lprotobuf  -L/usr/lib/x86_64-linux-gnu -lopencv_core  -L/home/anton/CK_TOOLS/lib-rtl-xopenme-0.3-gcc-5.4.0-linux-64/lib -lrtlxopenme   -lglog -lboost_thread -lboost_date_time -lboost_filesystem -lboost_system -lopencv_imgproc -lopencv_highgui -lopencv_core    -lm
***************************************************************************************

    Interestingly, increasing the sort order past 6 produces the same warnings and failures. Now, the sort order of 7 given to lib-glog, so I suspect it is GLog that "mixes in" the system Boost 1.58.0.

Now, I am currently using the system GLog as well.

anton@diviniti:~/CK_REPOS/ck-caffe/program/caffe-classification$ ck show env --tags=lib,glog
Env UID:         Target OS:      Bits: Name:        Version:            Tags:

49231e5e41df8f74        linux-64    64 GLog library 0                   64bits,glog,host-os-linux-64,lib,target-os-linux-64,v0
anton@diviniti:~/CK_REPOS/ck-caffe/program/caffe-classification$ cat /home/anton/CK_REPOS/local/env/49231e5e41df8f74/env.sh 
#! /bin/bash
# CK generated script

if [ "$1" != "1" ]; then if [ "$CK_ENV_LIB_GLOG_SET" == "1" ]; then return; fi; fi

# Soft UOA           = lib.glog (d42a1422abbcbb6a)  (lib,glog,64bits,host-os-linux-64,target-os-linux-64,v0)
# Host OS UOA        = linux-64 (4258b5fe54828a50)
# Target OS UOA      = linux-64 (4258b5fe54828a50)
# Target OS bits     = 64
# Tool version       = 0
# Tool split version = [0]

export CK_ENV_LIB_GLOG_LIB=/usr/lib/x86_64-linux-gnu
export CK_ENV_LIB_GLOG_INCLUDE=/usr/include

export LD_LIBRARY_PATH="/usr/lib/x86_64-linux-gnu":$LD_LIBRARY_PATH
export LIBRARY_PATH="/usr/lib/x86_64-linux-gnu":$LIBRARY_PATH

export CK_ENV_LIB_GLOG=/usr
export CK_ENV_LIB_GLOG_DYNAMIC_NAME=libglog.so
export CK_ENV_LIB_GLOG_LFLAG=-lglog
export CK_ENV_LIB_GLOG_STATIC_NAME=libglog.a

export CK_ENV_LIB_GLOG_SET=1

Next, I'll try to install GLog via CK.

psyhtest commented 7 years ago

In fact, even if GLog is installed via CK (from trunk, although a stable package is wanted), the problem is the same.

gfursin commented 7 years ago

There is an issue that I noticed some time ago and it's not fixed. When mixing automatically detected libs and installed via CK, a system path /usr/lib64 can be added to LD_LIBRARY_PATH in the middle and it mixes up linking (i.e. part of the libs will be from CK and part suddenly overloaded from /usr/lib64). There is no obvious solution and I found that other package managers/cmake complain about the same issue... One of the ideas is to avoid using LD_LIBRARY_PATH and always use full explicit paths, but not all native packages support that (cmake often tries to be smart)... That's why I had this ugly trick with adding boost twice ...

psyhtest commented 7 years ago

As I mentioned, boosting (sic:)) the order of:

    "lib-boost": {
      "force_add_static_lib_path": "yes",
      "local": "yes",
      "name": "Boost library",
      "sort": 13,
      "tags": "lib,boost"
    },

to 4, eliminated the link-time warnings and run-time failures.

Moreover, I could get rid of:

    "boost": {
      "local": "yes",
      "name": "Boost C++ libraries",
      "skip_from_bat": "yes",
      "sort": 30,
      "tags": "lib,boost"
    },

completely (at least on my Ubuntu laptop).

Is it still needed? If yes, I suggest we clean this across all the programs e.g. as follows:

    "lib-boost": {
      "force_add_static_lib_path": "yes",
      "local": "yes",
      "name": "Boost library",
      "sort": 4,
      "tags": "lib,boost"
    },
    "lib-boost2": {
      "local": "yes",
      "name": "Boost library (2)",
      "skip_from_bat": "yes",
      "sort": 400,
      "tags": "lib,boost"
    },

I'm also confused about the skip_from_bat and force_add_static_lib_path keys.

gfursin commented 7 years ago

Unfortunately, there are some nuances on some platforms, so I would suggest not to touch it now! The solution is to avoid using LD_LIBRARY_PATH with mixing CK-installed packages and usr/lib, but instead use only explicit paths ... But it's not done yet, and will require various changes in the CK ... I would prefer not to do it right now since we can break lots of deps ... But I am thinking one day to update handling of such vars in the CK when I have more time ...