Bug#882781: clang is missing a dependency on libomp-dev

[Alexander Kurtz]

Package: clang
Version: 1:3.8-37

Hi!

The gcc package Depends: on gcc-7 -> libgcc-7-dev -> libgomp1, which
means the following works out-of-the-box:

***@shepard:~$ cat test.c
int main(){
#pragma omp parallel for schedule(dynamic,50)
for(int i = 0; i < 10; i++);
}
***@shepard:~$ gcc -fopenmp test.c
***@shepard:~$ ./a.out
***@shepard:~$

In contrast, the clang package does not pull in libomp-dev, which means
the following fails:

***@shepard:~$ cat test.c
int main(){
#pragma omp parallel for schedule(dynamic,50)
for(int i = 0; i < 10; i++);
}
***@shepard:~$ clang -fopenmp test.c
/usr/bin/ld: cannot find -lomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
***@shepard:~$

I think that if the clang binary supports the -fopenmp switch, it is
reasonable to assume that it actually works. Therefore please make the
clang package depend on the libomp-dev package.

Best regards

Alexander Kurtz

[Sylvestre Ledru]

Post by Alexander Kurtz
Package: clang
Version: 1:3.8-37
In contrast, the clang package does not pull in libomp-dev, which means
int main(){
#pragma omp parallel for schedule(dynamic,50)
for(int i = 0; i < 10; i++);
}
/usr/bin/ld: cannot find -lomp
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I think that if the clang binary supports the -fopenmp switch, it is
reasonable to assume that it actually works. Therefore please make the
clang package depend on the libomp-dev package.

For now, I am not planning to add this a mandatory dep. openmp is a
niche and I don't think
we should have a hard dependency for every clang user.
By the way libomp-dev is suggested by clang packages.

Cheers,
Sylvestre

[Alexander Kurtz]

Hi!

Post by Sylvestre Ledru
For now, I am not planning to add this a mandatory dep. openmp is a
niche and I don't think
we should have a hard dependency for every clang user.
By the way libomp-dev is suggested by clang packages.

In theory, you are right, clang should not depend on library packages
just for convenience. However libomp-dev is special here, because its
usage is usually hidden: Typical OpenMP tutorials look like this:

cc -fopenmp foo.c

or maybe

cc -fopenmp -o foo.o foo.c
cc -fopenmp -o foo foo.o

and this works on GCC. The fact that this doesn't work with clang isn't
even the problem here, the fact that step 1 from above works, while
step 2 doesn't is. If users expected to need to link a library in for
this to work, things would be fine, but they don't (which arguably is
the real problem here, but thanks to GCC that's just the way it is).

TL;DR: If you want to write cross-compiler Makefiles, you use
-fopenmp for both compiling and linking, because the actual OpenMP
libraries differ between GCC and clang. And this breaks for clang.

And last but not least, libomp-dev pulls in 238 KB, which is about 0.4%
of the 59.1 MB clang pulls in:

***@shepard:~# apt install clang
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
binfmt-support clang-3.8 libclang-common-3.8-dev libclang1-3.8 libllvm3.8 libobjc-6-dev libobjc4 libstdc++-6-dev llvm-3.8 llvm-3.8-dev
llvm-3.8-runtime
Suggested packages:
gnustep gnustep-devel clang-3.8-doc libstdc++-6-doc llvm-3.8-doc
The following NEW packages will be installed:
binfmt-support clang clang-3.8 libclang-common-3.8-dev libclang1-3.8 libllvm3.8 libobjc-6-dev libobjc4 libstdc++-6-dev llvm-3.8 llvm-3.8-dev
llvm-3.8-runtime
0 upgraded, 12 newly installed, 0 to remove and 0 not upgraded.
Need to get 59.1 MB of archives.
After this operation, 308 MB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
***@shepard:~# apt install libomp-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libomp5
The following NEW packages will be installed:
libomp-dev libomp5
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 238 kB of archives.
After this operation, 808 kB of additional disk space will be used.
Do you want to continue? [Y/n] n
Abort.
***@shepard:~#

If you don't want a hard dependency (which I still think would be the
correct thing to do since "a command line argument of clang doesn't
actually work without it"), would you perhaps consider a Recommends: ?

Best regards

Alexander Kurtz

[Sylvestre Ledru]

Hi!

Post by Sylvestre Ledru
For now, I am not planning to add this a mandatory dep. openmp is a
niche and I don't think
we should have a hard dependency for every clang user.
By the way libomp-dev is suggested by clang packages.

In theory, you are right, clang should not depend on library packages
just for convenience. However libomp-dev is special here, because its
cc -fopenmp foo.c
or maybe
cc -fopenmp -o foo.o foo.c
cc -fopenmp -o foo foo.o
and this works on GCC. The fact that this doesn't work with clang isn't
even the problem here, the fact that step 1 from above works, while
step 2 doesn't is. If users expected to need to link a library in for
this to work, things would be fine, but they don't (which arguably is
the real problem here, but thanks to GCC that's just the way it is).
TL;DR: If you want to write cross-compiler Makefiles, you use
-fopenmp for both compiling and linking, because the actual OpenMP
libraries differ between GCC and clang. And this breaks for clang.
And last but not least, libomp-dev pulls in 238 KB, which is about 0.4%

Well, this won't be true in a future upload. I split clang & clang-tools;
clang should be about 9mb now.

If you don't want a hard dependency (which I still think would be the
correct thing to do since "a command line argument of clang doesn't
actually work without it"), would you perhaps consider a Recommends: ?

Sure, I fixed that in the vcs!

Thanks
S

[Alexander Kurtz]

Post by Sylvestre Ledru

If you don't want a hard dependency (which I still think would be the
correct thing to do since "a command line argument of clang doesn't
actually work without it"), would you perhaps consider a Recommends: ?

Sure, I fixed that in the vcs!

Great, thanks a lot!

Alexander Kurtz