8000 Conflicting OMP implementations linked when building with MKLDNN · Issue #126211 · pytorch/pytorch · GitHub
[go: up one dir, main page]

Skip to content
Conflicting OMP implementations linked when building with MKLDNN #126211
Open
@mwlon

Description

@mwlon

🐛 Describe the bug

Custom builds with MKLDNN can link to both libomp and libgomp, which could cause invalid or slow behavior if some symbols are missing from one.

This happens because the MKLDNN extension always builds with libgomp, whereas pytorch by default prefers libomp.

Assuming libomp is present on the system, this can be replicated via a custom build with

export CMAKE_PREFIX_PATH="/path/to/mkl/"
cmake -DUSE_MKLDNN=1 -DUSE_STATIC_MKL=1 -DBLAS=MKL

Producing things like this:

$ readelf -d libtorch_cpu.so 

Dynamic section at offset 0x12425918 contains 40 entries:
  Tag        Type                         Name/Value
...
 0x0000000000000001 (NEEDED)             Shared library: [libomp.so]
 0x0000000000000001 (NEEDED)             Shared library: [libgomp.so.1]
...

I suspect the fix here would be to always use libgomp in FindOpenMP.cmake when USE_MKLDNN is true, but perhaps there's a way to make MKLDNN use whatever OMP we've discovered?

Versions

I think this has been the case for a while.

cc @malfet @seemethere @gujinghui @PenghuiCheng @XiaobingSuper @jianyuh @jgong5 @mingfeima @sanchitintel @ashokei @jingxu10 @min-jean-cho @yanbing-j @Guobing-Chen @Xia-Weiwen @snadampal

Metadata

Metadata

Assignees

Labels

module: buildBuild system issuesmodule: mkldnnRelated to Intel IDEEP or oneDNN (a.k.a. mkldnn) integrationmodule: openmpRelated to OpenMP (omp) support in PyTorchtriagedThis issue has been looked at a team member, and triaged and prioritized into an appropriate module

Type

No type

Projects

Status

No status

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions

    0