OpenVino add build_shared_lib flag in the build command

[sfatimar]

We were not able to build C++ samples without build_shared_lib flag in the build command.

Motivation and Context

• This changes was required in dockerfiles to enable c++ sample build
• If it fixes an open issue, please link to the issue here.

[HectorSVC]

/azp run Linux OpenVINO CI Pipeline

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[jywu-msft]

is it really necessary to change the dockerfiles? (which are for building python bindings/package)
the build_shared_lib option is for onnxruntime lib.
openvino ep gets built as a shared lib regardless of whether build_shared_lib option is enabled.

[sfatimar]

We have added build_shared_lib to build libonnxruntime.so as some developers found that it was easier to build C++ samples this way.

[MaajidKhan]

is it really necessary to change the dockerfiles? (which are for building python bindings/package)
the build_shared_lib option is for onnxruntime lib.
openvino ep gets built as a shared lib regardless of whether build_shared_lib option is enabled.

Hello George. To build the CPP samples that are already available here https://github.com/microsoft/onnxruntime/tree/master/samples/c_cxx, we need the libonnxruntime.so shared lib to be linked while compiling along with two other shared libs (libonnxruntime_providers_shared.so and libonnxruntime_providers_openvino.so).

Without this libonnxruntime.so lib, when we try compiling, it doesn't get compiled with this error.
/tmp/cctSSMOx.o: In function __static_initialization_and_destruction_0(int, int)': squeezenet_cpp_app.cpp:(.text+0x1c03): undefined reference to OrtGetApiBase'
collect2: error: ld returned 1 exit status

so, we thought of adding --build_shared_lib flag as default while compiling OpenVINO-EP, so that the developers won't have issues building CPP samples.

we added the same flag inside the docker files which are for building python bindings/package because anyways the onnxruntime dir gets deleted as part of optimization at this line

onnxruntime/dockerfiles/Dockerfile.openvino

Line 89 in f14c621

cd ${MY_ROOT}/ && rm -rf onnxruntime && cd /opt && rm -rf v1.0.22.zip && cd ${MY_ROOT} &&\

.

so, if some user wants to use the same docker file to build CPP samples, all he has to do is remove this step.

[HectorSVC]

/azp run Linux CPU CI Pipeline,Linux CPU x64 NoContribops CI Pipeline,Linux GPU CI Pipeline,Linux GPU TensorRT CI Pipeline,MacOS CI Pipeline,MacOS NoContribops CI Pipeline,Windows CPU CI Pipeline,Windows GPU CI Pipeline,Windows GPU TensorRT CI Pipeline

[azure-pipelines]

Azure Pipelines successfully started running 9 pipeline(s).

[jywu-msft]

is it really necessary to change the dockerfiles? (which are for building python bindings/package)
the build_shared_lib option is for onnxruntime lib.
openvino ep gets built as a shared lib regardless of whether build_shared_lib option is enabled.

Hello George. To build the CPP samples that are already available here https://github.com/microsoft/onnxruntime/tree/master/samples/c_cxx, we need the libonnxruntime.so shared lib to be linked while compiling along with two other shared libs (libonnxruntime_providers_shared.so and libonnxruntime_providers_openvino.so).

Without this libonnxruntime.so lib, when we try compiling, it doesn't get compiled with this error.
/tmp/cctSSMOx.o: In function __static_initialization_and_destruction_0(int, int)': squeezenet_cpp_app.cpp:(.text+0x1c03): undefined reference to OrtGetApiBase' collect2: error: ld returned 1 exit status

so, we thought of adding --build_shared_lib flag as default while compiling OpenVINO-EP, so that the developers won't have issues building CPP samples.

we added the same flag inside the docker files which are for building python bindings/package because anyways the onnxruntime dir gets deleted as part of optimization at this line

onnxruntime/dockerfiles/Dockerfile.openvino

Line 89 in f14c621

cd ${MY_ROOT}/ && rm -rf onnxruntime && cd /opt && rm -rf v1.0.22.zip && cd ${MY_ROOT} &&\

.
so, if some user wants to use the same docker file to build CPP samples, all he has to do is remove this step.

yes, understood that the CPP sample needs the libonnxruntime.so
On the other hand, I was questioning the usefulness of adding the build_shared_lib option in the dockerfile.openvino (whose main purpose is to build and install the python package).
As you mentioned, the build directory gets deleted so the libonnxruntime.so would also get removed.

[jywu-msft]

Azure Pipelines successfully started running 9 pipeline(s).

is it really necessary to change the dockerfiles? (which are for building python bindings/package)
the build_shared_lib option is for onnxruntime lib.
openvino ep gets built as a shared lib regardless of whether build_shared_lib option is enabled.

Hello George. To build the CPP samples that are already available here https://github.com/microsoft/onnxruntime/tree/master/samples/c_cxx, we need the libonnxruntime.so shared lib to be linked while compiling along with two other shared libs (libonnxruntime_providers_shared.so and libonnxruntime_providers_openvino.so).
Without this libonnxruntime.so lib, when we try compiling, it doesn't get compiled with this error.
/tmp/cctSSMOx.o: In function __static_initialization_and_destruction_0(int, int)': squeezenet_cpp_app.cpp:(.text+0x1c03): undefined reference to OrtGetApiBase' collect2: error: ld returned 1 exit status
so, we thought of adding --build_shared_lib flag as default while compiling OpenVINO-EP, so that the developers won't have issues building CPP samples.
we added the same flag inside the docker files which are for building python bindings/package because anyways the onnxruntime dir gets deleted as part of optimization at this line

onnxruntime/dockerfiles/Dockerfile.openvino

Line 89 in f14c621

cd ${MY_ROOT}/ && rm -rf onnxruntime && cd /opt && rm -rf v1.0.22.zip && cd ${MY_ROOT} &&\

.
so, if some user wants to use the same docker file to build CPP samples, all he has to do is remove this step.

yes, understood that the CPP sample needs the libonnxruntime.so
On the other hand, I was questioning the usefulness of adding the build_shared_lib option in the dockerfile.openvino (whose main purpose is to build and install the python package).
As you mentioned, the build directory gets deleted so the libonnxruntime.so would also get removed.

ok i missed your comment that the user would need to manually leave out the step which removes the build directory.
yes, i suppose that is true. you might explicitly add a comment explaining that.
otherwise i doubt the user would know this up front.

[HectorSVC]

is it really necessary to change the dockerfiles? (which are for building python bindings/package)
the build_shared_lib option is for onnxruntime lib.
openvino ep gets built as a shared lib regardless of whether build_shared_lib option is enabled.

Hello George. To build the CPP samples that are already available here https://github.com/microsoft/onnxruntime/tree/master/samples/c_cxx, we need the libonnxruntime.so shared lib to be linked while compiling along with two other shared libs (libonnxruntime_providers_shared.so and libonnxruntime_providers_openvino.so).
Without this libonnxruntime.so lib, when we try compiling, it doesn't get compiled with this error.
/tmp/cctSSMOx.o: In function __static_initialization_and_destruction_0(int, int)': squeezenet_cpp_app.cpp:(.text+0x1c03): undefined reference to OrtGetApiBase' collect2: error: ld returned 1 exit status
so, we thought of adding --build_shared_lib flag as default while compiling OpenVINO-EP, so that the developers won't have issues building CPP samples.
we added the same flag inside the docker files which are for building python bindings/package because anyways the onnxruntime dir gets deleted as part of optimization at this line

onnxruntime/dockerfiles/Dockerfile.openvino

Line 89 in f14c621

cd ${MY_ROOT}/ && rm -rf onnxruntime && cd /opt && rm -rf v1.0.22.zip && cd ${MY_ROOT} &&\

.
so, if some user wants to use the same docker file to build CPP samples, all he has to do is remove this step.

yes, understood that the CPP sample needs the libonnxruntime.so
On the other hand, I was questioning the usefulness of adding the build_shared_lib option in the dockerfile.openvino (whose main purpose is to build and install the python package).
As you mentioned, the build directory gets deleted so the libonnxruntime.so would also get removed.

I think what they mean is that some user reuse same docker file for development, the developer will comment out the line which delete the build directory. For normal user build docker image directly from the original docker file, they won't aware of the libonnxruntime.so file since it will be deleted anyway.

[HectorSVC]

/azp run orttraining-linux-ci-pipeline,orttraining-mac-ci-pipeline,orttraining-linux-gpu-ci-pipeline,centos7_cpu,Linux CPU Minimal Build E2E CI Pipeline,Linux Nuphar CI Pipeline,MacOS NoContribops CI Pipeline,orttraining-distributed

[azure-pipelines]

Azure Pipelines successfully started running 8 pipeline(s).

[MaajidKhan]

is it really necessary to change the dockerfiles? (which are for building python bindings/package)
the build_shared_lib option is for onnxruntime lib.
openvino ep gets built as a shared lib regardless of whether build_shared_lib option is enabled.

Hello George. To build the CPP samples that are already available here https://github.com/microsoft/onnxruntime/tree/master/samples/c_cxx, we need the libonnxruntime.so shared lib to be linked while compiling along with two other shared libs (libonnxruntime_providers_shared.so and libonnxruntime_providers_openvino.so).
Without this libonnxruntime.so lib, when we try compiling, it doesn't get compiled with this error.
/tmp/cctSSMOx.o: In function __static_initialization_and_destruction_0(int, int)': squeezenet_cpp_app.cpp:(.text+0x1c03): undefined reference to OrtGetApiBase' collect2: error: ld returned 1 exit status
so, we thought of adding --build_shared_lib flag as default while compiling OpenVINO-EP, so that the developers won't have issues building CPP samples.
we added the same flag inside the docker files which are for building python bindings/package because anyways the onnxruntime dir gets deleted as part of optimization at this line

onnxruntime/dockerfiles/Dockerfile.openvino

Line 89 in f14c621

cd ${MY_ROOT}/ && rm -rf onnxruntime && cd /opt && rm -rf v1.0.22.zip && cd ${MY_ROOT} &&\

.
so, if some user wants to use the same docker file to build CPP samples, all he has to do is remove this step.

yes, understood that the CPP sample needs the libonnxruntime.so
On the other hand, I was questioning the usefulness of adding the build_shared_lib option in the dockerfile.openvino (whose main purpose is to build and install the python package).
As you mentioned, the build directory gets deleted so the libonnxruntime.so would also get removed.

I think what they mean is that some user reuse same docker file for development, the developer will comment out the line which delete the build directory. For normal user build docker image directly from the original docker file, they won't aware of the libonnxruntime.so file since it will be deleted anyway.

Right Hector. This is the main reason, we added the option in the docker file. so, that we don't have to explicitly tell the user every time that they need to add this flag themselves if they want to work with CPP samples.