Bug#1007222: transition: onetbb

1 view
Skip to first unread message

M. Zhou

unread,
Mar 13, 2022, 5:10:04 PMMar 13
to
Package: release.debian.org
Severity: normal
User: release.d...@packages.debian.org
Usertags: transition

Hi release team,

This involves an upstream source name change (from tbb to onetbb),
as well as SOVERSION bump (from 2 to 12), along with a major API
change including some changes in the core API.

I should have submitted this after my local build test for the
reverse dependencies of libtbb-dev, but fellow developers from
debian-science are eager to see this in unstable to unblock
their works.

I have not tested by myself, but I heard from an archlinux
developer that this API bump breaks a lot packages. And
some upstreams decided to disable or drop tbb support as
a result. I guess we can take similar measures for short
term workaround.

Ben file:

title = "tbb";
is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
is_good = .depends ~ "libtbb12";
is_bad = .depends ~ "libtbb2";
Thank you for using reportbug

Sebastian Ramacher

unread,
Mar 13, 2022, 5:40:03 PMMar 13
to
Control: forwarded -1 https://release.debian.org/transitions/html/onetbb.html
Control: tags -1 moreinfo

On 2022-03-13 16:59:48 -0400, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.d...@packages.debian.org
> Usertags: transition
>
> Hi release team,
>
> This involves an upstream source name change (from tbb to onetbb),
> as well as SOVERSION bump (from 2 to 12), along with a major API
> change including some changes in the core API.
>
> I should have submitted this after my local build test for the
> reverse dependencies of libtbb-dev, but fellow developers from
> debian-science are eager to see this in unstable to unblock
> their works.
>
> I have not tested by myself, but I heard from an archlinux
> developer that this API bump breaks a lot packages. And
> some upstreams decided to disable or drop tbb support as
> a result. I guess we can take similar measures for short
> term workaround.

Please remove the moreinfo tag once these issues have been investigated
and bugs have been filed.

Cheers

>
> Ben file:
>
> title = "tbb";
> is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
> is_good = .depends ~ "libtbb12";
> is_bad = .depends ~ "libtbb2";
> Thank you for using reportbug
>

--
Sebastian Ramacher
signature.asc

Matthias Klose

unread,
Mar 13, 2022, 9:50:03 PMMar 13
to
On 13.03.22 21:59, M. Zhou wrote:
> Package: release.debian.org
> Severity: normal
> User: release.d...@packages.debian.org
> Usertags: transition
>
> Hi release team,
>
> This involves an upstream source name change (from tbb to onetbb),
> as well as SOVERSION bump (from 2 to 12), along with a major API
> change including some changes in the core API.
>
> I should have submitted this after my local build test for the
> reverse dependencies of libtbb-dev, but fellow developers from
> debian-science are eager to see this in unstable to unblock
> their works.
>
> I have not tested by myself, but I heard from an archlinux
> developer that this API bump breaks a lot packages. And
> some upstreams decided to disable or drop tbb support as
> a result. I guess we can take similar measures for short
> term workaround.

"I heard from archlinux" is not good enough. I sent you email about this
without getting a reply, then filed #1006920, without getting a reply, now this
incomplete proposal. you may want to look at all the build rdeps for libtbb2-dev
in Ubuntu to get an overview what at least breaks:

$ reverse-depends -b libtbb2-dev

Reverse-Testsuite-Triggers

* intel-mkl



Reverse-Build-Depends

* casparcg-server

* flexbar

* gazebo

* opencascade

* opensubdiv

* r-cran-rcppparallel
(plus implicit dependencies)


> Ben file:
>
> title = "tbb";
> is_affected = .depends ~ "libtbb2" | .depends ~ "libtbb12";
> is_good = .depends ~ "libtbb12";
> is_bad = .depends ~ "libtbb2";

this breaks everything immediately because of the conflicting libtbb2 and
libtbb12. Please fix this first.

Matthias

Jose Luis Rivero

unread,
Mar 21, 2022, 1:00:03 PMMar 21
to
On Mon, 14 Mar 2022 02:30:08 +0100 Matthias Klose <do...@debian.org> wrote:
> >
> > I have not tested by myself, but I heard from an archlinux
> > developer that this API bump breaks a lot packages. And
> > some upstreams decided to disable or drop tbb support as
> > a result. I guess we can take similar measures for short
> > term workaround.
>
> "I heard from archlinux" is not good enough.  I sent you email about this
> without getting a reply, then filed #1006920, without getting a reply, now this
> incomplete proposal. you may want to look at all the build rdeps for libtbb2-dev
> in Ubuntu to get an overview what at least breaks:
>
> $ reverse-depends -b libtbb2-dev
>
> Reverse-Testsuite-Triggers
>
> * intel-mkl
>
>
>
> Reverse-Build-Depends
>
...
>
> * gazebo
>

Speaking as the maintainer of Gazebo, upstream has released a new 11.10.2 version that is compatible with new tbb. I've uploaded it to experimental, it builds fine. The package should be ready for the transition as far as I can tell.

Thanks guys for working on the transition.

Paul Gevers

unread,
Mar 24, 2022, 8:20:03 AMMar 24
to
Hi lumin,

On 14-03-2022 02:30, Matthias Klose wrote:
> On 13.03.22 21:59, M. Zhou wrote:
>> I have not tested by myself, but I heard from an archlinux
>> developer that this API bump breaks a lot packages. And
>> some upstreams decided to disable or drop tbb support as
>> a result. I guess we can take similar measures for short
>> term workaround.
>
> "I heard from archlinux" is not good enough.  I sent you email about
> this without getting a reply, then filed #1006920, without getting a
> reply, now this incomplete proposal. you may want to look at all the
> build rdeps for libtbb2-dev in Ubuntu to get an overview what at least
> breaks:

[...]

> this breaks everything immediately because of the conflicting libtbb2
> and libtbb12. Please fix this first.

Can you please respond to these remarks? They raise valid points for us.

Paul
OpenPGP_signature

M. Zhou

unread,
Mar 24, 2022, 11:50:03 AMMar 24
to
On Thu, 2022-03-24 at 13:12 +0100, Paul Gevers wrote:
> >
> > "I heard from archlinux" is not good enough.  I sent you email about
> > this without getting a reply, then filed #1006920, without getting a
> > reply, now this incomplete proposal. you may want to look at all the
> > build rdeps for libtbb2-dev in Ubuntu to get an overview what at least
> > breaks:

Sorry for the late response but I think that's what usually happens when
the maintainer is occupied by research and studies. I would not have
submitted this incomplete transition slot if I did not hear so much
request.

I think the solution for allowing the co-existence of tbb and onetbb
is not the best. Because tbb will not have upstream support in the
future due to deprecation.

>
> > this breaks everything immediately because of the conflicting libtbb2
> > and libtbb12. Please fix this first.
>
> Can you please respond to these remarks? They raise valid points for us.

libtbb2 and libtbb12 contains some common files hence the conflict.
I'd rather wait for all the reverse deps to be ready for this
transition, compared to going through NEW again due to binary
package change.

I've started rebuilding the reverse dependencies and filing bugs,
will get back to you soon.

Sebastian Ramacher

unread,
Mar 24, 2022, 1:10:03 PMMar 24
to
This makes the transition and upgrades more painful than necessary. The
files shared between both packages are actually shared libraries with
their own SONAME that did not change. Why are the contained in libtbb12
if they do not follow the same version as libtbb itself?

Cheers
--
Sebastian Ramacher

M. Zhou

unread,
Mar 24, 2022, 3:20:05 PMMar 24
to
On Thu, 2022-03-24 at 17:55 +0100, Sebastian Ramacher wrote:
> >
> > libtbb2 and libtbb12 contains some common files hence the conflict.
> > I'd rather wait for all the reverse deps to be ready for this
> > transition, compared to going through NEW again due to binary
> > package change.
>
> This makes the transition and upgrades more painful than necessary.
> The
> files shared between both packages are actually shared libraries with
> their own SONAME that did not change. Why are the contained in
> libtbb12
> if they do not follow the same version as libtbb itself?

Ok. Before we start, a user said "Following this up,
the split of the libraries is breaking some common use
cases in the robotics community" at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1006920

But I did not figure out what bad could happen from the
links provided. I'm requesting more information there.
Once confirmed I'll merge doko's patches and go through NEW
again.

Andrius Merkys

unread,
May 17, 2022, 2:40:03 AMMay 17
to
Hello,

On Mon, 14 Mar 2022 02:30:08 +0100 Matthias Klose <do...@debian.org> wrote:
> this breaks everything immediately because of the conflicting libtbb2 and
> libtbb12. Please fix this first.

This has been fixed recently with tbb/2020.3-2 and onetbb/2021.5.0-8
uploads.

Best,
Andrius

M. Zhou

unread,
May 25, 2022, 8:10:03 PMMay 25
to
Control: tags -1 -moreinfo

Reverse-Build-Depends
* blender [irrelevant; ftpfs, no matching function for call to openvdb... ] #1011653
* bowtie [ok]
* bowtie2 [ok]
* casparcg-server [ftbfs, TBB not found during cmake] #1011654
* deal.ii [ftbfs, cmake could not find tbb] #1011655
* embree [ok]
* flexbar [ftbfs, cannot find tbb header] #1011656
* gazebo [irrelevant; ftbfs, missing symbol from libtiff] #1011657
* gudhi [ok]
* libatomic-queue [ok]
* libpmemobj-cpp [ftbfs, tbb api break] #1011658
* macaulay2 [unknown, timeout for doc build during ThreadedGB ... Minimal.out]
* madness [ok]
* mathicgb [ok]
* mpqc3 [irrelevant; eigen3 api break; already FTBFS]
* numba [irrelevant; incompatible with py3.10]
* onednn [ok]
* open3d [ok]
* opencascade [ftbfs; tbb api break] #1011659
* opencv [ok]
* opensubdiv [ftbfs; tbb api break] #1011660
* openturns [ok]
* openvdb [irrelevant; help2man error during manpage build; already FTBFS]
* pmemkv [ok]
* ptl [ok]
* r-cran-markovchain [ftbfs; tbb api break] #1011661
* r-cran-rcppparallel [ok]
* r-cran-uwot [ok]
* salmon [ftbfs; tbb api break] #1011662
* slic3r-prusa [FTBFS, TBB api break] #1011663
* sysdig [ok]
* tiledarray [irrelevant: other build depenency uninstallable]
* tiny-dnn [ftbfs, TBB not found during cmake] #1011664
* trilinos [irrelevant: isinf not defined]
* vtk9 [ok]

M. Zhou

unread,
May 25, 2022, 8:30:03 PMMay 25
to
This is the most uneasy transition I've ever handled. There was
massive upstream code overhaul breaking basically everything.

Build system has changed so I rewritten the d/rules, this took
me a while.

Going through NEW due to upstream rename took a while.

Then only amd64 does not FTBFS. I wrote patches to make it
green on release architectures, this took me a while.

Then there is package split, which means we have to go through
NEW again. This is relatively fast IIRC.

Throughout the whole process I'm dealing with paper submission
deadline which has passed several days ago. Before that
I wasn't able to allocate time for the massive reverse dependency
build. This took a while as well.

Now we can finally go ahead.

Graham Inggs

unread,
Jun 1, 2022, 2:40:03 PMJun 1
to
Control: tags -1 + moreinfo

Hi

I noticed some packages in the tracker not appearing in your list;
e.g. openimageio, pcl and yade. These packages have transitive
build-dependencies on libtbb-dev through e.g. libopenvdb-dev or
libvtk9-dev, and should be investigated as well.

Note that we will require fixes, or at least patches, for "key
packages" [1] before starting with this transition, and at least
trilinos is currently on that list.

It may be worth considering again Matthias' suggestion in #1006920 to
keep the old tbb package around as libtbb2-dev and libtbb2-doc in
order to allow packages like numba to get the new tbb soon, and other
packages stuck with the old tbb more time to get fixed.

Regards
Graham


[1] https://udd.debian.org/cgi-bin/key_packages.yaml.cgi

M. Zhou

unread,
Jun 1, 2022, 9:20:03 PMJun 1
to
On Wed, 2022-06-01 at 20:29 +0200, Graham Inggs wrote:
> Control: tags -1 + moreinfo
>
> I noticed some packages in the tracker not appearing in your list;
> e.g. openimageio, pcl and yade. These packages have transitive
> build-dependencies on libtbb-dev through e.g. libopenvdb-dev or
> libvtk9-dev, and should be investigated as well.

My bad. So solely `reverse-depends -b` may miss something. I'll
investigate and append results to the transition bug.

> Note that we will require fixes, or at least patches, for "key
> packages" [1] before starting with this transition, and at least
> trilinos is currently on that list.
>
> It may be worth considering again Matthias' suggestion in #1006920 to
> keep the old tbb package around as libtbb2-dev and libtbb2-doc in
> order to allow packages like numba to get the new tbb soon, and other
> packages stuck with the old tbb more time to get fixed.

I personally dislike making the old package libtbb2-dev.
How about we make the old src:tbb package go through NEW again
with the following renames:

libtbb-dev -> libtbb-legacy-dev, this sounds much better than libtbb2-dev
because it explains itself to be a to-be-deprecated version.

In this way we can finish the transition very quickly and leave
longer time for broken packages to migrate to onetbb.

For me, submitting patches is as well much easier as I only have to
change libtbb-dev -> libtbb-legacy-dev for broken packages.

Andrius Merkys

unread,
Jun 3, 2022, 3:10:04 AMJun 3
to
Hello,

On Wed, 1 Jun 2022 20:29:02 +0200 Graham Inggs <gin...@debian.org>
wrote:> I noticed some packages in the tracker not appearing in your list;
> e.g. openimageio, pcl and yade. These packages have transitive
> build-dependencies on libtbb-dev through e.g. libopenvdb-dev or
> libvtk9-dev, and should be investigated as well.

I have ratt-rebuilt the reverse dependencies (I believe ratt catches the
transitive ones). Here are my results:

OK
==

actiona
arc-theme
asl
auto-multiple-choice
bcnc
beads
bowtie
bowtie2
budgie-control-center
cheese
cimg
darknet
digikam
embree
empathy
esys-particle
eviacam
f3d
finalcif
freecad
frei0r
gearhead2
gfpoken
gmic
gnome-dvb-daemon
gnome-initial-setup
gnome-mousetrap
gnome-sound-recorder
golang-github-thecreeper-go-notify
gst-plugins-bad1.0
gstreamer-editing-services1.0
gstreamer-vaapi
gst-rtsp-server1.0
gtk4
gudhi
kdenlive
kylin-scanner
lammps
libatomic-queue
liggghts
mathicgb
mlt
monado
mrcal
mrgingham
mrpt
netgen
nheko
node-opencv
nomacs
obs-advanced-scene-switcher
octave-bim
octave-msh
odin
oggvideotools
onednn
open3d
opencfu
opencv
opendrop
openqa
openturns
os-autoinst
otb
pcl
planetary-system-stacker
pmemkv
pmemkv-python
pragha
psychopy
ptl
pulseeffects
pygmsh
pymatgen
python-escript
python-notify2
python-pcl
pytorch
pytorch-ignite
q2-dada2
qimgv
r-cran-luminescence
r-cran-openmx
r-cran-projpred
r-cran-rcppparallel
r-cran-rlumshiny
r-cran-rstantools
r-cran-semplot
r-cran-stanheaders
r-cran-treescape
r-cran-treespace
r-cran-uwot
ros-image-pipeline
ros-opencv-apps
ros-perception-pcl
ros-vision-opencv
sayonara
sdaps
seer
shotcut
sight
simple-whip-client
siril
skorch
sunpy
synfig
synfigstudio
sysdig
therion
tpot
trinityrnaseq
ukui-biometric-auth
ukui-biometric-manager
ukui-control-center
ukui-greeter
ukui-screensaver
uprightdiff
vecgeom
vedo
visp
vtk9
willow
yade

FTBFS with TBB (bugs reported)
==============================

blender
deal.ii
flexbar
gazebo
libpmemobj-cpp
opencascade
openimageio
opensubdiv
openvdb
r-bioc-dada2
r-cran-brms
r-cran-lamw
r-cran-markovchain
r-cran-prophet
r-cran-rstan
r-cran-rstanarm
r-cran-shinystan
salmon
slic3r-prusa
tiny-dnn

Unrelated FTBFS
===============

freeture
gmsh
kicad
limereg
madness
mldemos
mpqc3
numba
olive-editor
opencolorio
php-facedetect
pigx-rnaseq
pitivi
plastimatch
pytorch-audio
pytorch-text
pytorch-vision
trilinos

Unsatisfiable dependencies
==========================

hyperspy
poliastro
pynpoint
python-cogent
python-epimodels
python-fluids
python-loompy
python-numpy-groupies
python-pynndescent
python-sparse
sfepy
tiledarray
umap-learn

Is this enough to remove 'moreinfo'?

Best,
Andrius

Graham Inggs

unread,
Jun 3, 2022, 9:40:04 AMJun 3
to
Hi

On Thu, 2 Jun 2022 at 03:11, M. Zhou <lu...@debian.org> wrote:
> I personally dislike making the old package libtbb2-dev.
> How about we make the old src:tbb package go through NEW again
> with the following renames:
>
> libtbb-dev -> libtbb-legacy-dev, this sounds much better than libtbb2-dev
> because it explains itself to be a to-be-deprecated version.

I personally don't like tbb-legacy-dev. It's not common in the
archive for a -dev package. Most are unversioned, otherwise they
match the library package, so libtbb2-dev for libtbb2. See e.g.
lmsensors-dev, lmsensors4-dev, libpcre2-dev, libpcre3-dev, libvtk7-dev
and libvtk9-dev, etc. Explanations can go in the package description,
e.g. from libpcre3-dev
"New packages should use the newer pcre2 packages, and existing
packages should migrate to pcre2".

> In this way we can finish the transition very quickly and leave
> longer time for broken packages to migrate to onetbb.
>
> For me, submitting patches is as well much easier as I only have to
> change libtbb-dev -> libtbb-legacy-dev for broken packages.

Changing libtbb-dev -> libtbb2-dev should be even easier :). However,
we don't **have** to reintroduce the old tbb package, and **you**
don't have to be the one maintaining it. If all the packages that
FTBFS with the new tbb can be removed from testing, the old tbb can be
reintroduced after the transition, by some maintainers who wish to
care for it.

Regards
Graham

Graham Inggs

unread,
Jun 3, 2022, 10:20:03 AMJun 3
to
Hi Andrius

Thanks for your work on this. My comments below are inlined.

On Fri, 3 Jun 2022 at 09:06, Andrius Merkys <mer...@debian.org> wrote:
> Unrelated FTBFS
> ===============
>
> freeture - not in testing
> gmsh - https://tests.reproducible-builds.org/debian/rb-pkg/gmsh.html
> kicad - https://tests.reproducible-builds.org/debian/rb-pkg/kicad.html
> limereg - not in testing
> madness - https://tests.reproducible-builds.org/debian/rb-pkg/madness.html
> mldemos - not in testing
> mpqc3 - not in testing
> numba - not in testing
> olive-editor - not in testing
> opencolorio - not in testing
> php-facedetect - not in testing
> pigx-rnaseq - not in testing
> pitivi - https://tests.reproducible-builds.org/debian/rb-pkg/pitivi.html
> plastimatch - #1005485
> pytorch-audio - not in testing
> pytorch-text - not in testing
> pytorch-vision - not in testing
> trilinos - https://tests.reproducible-builds.org/debian/rb-pkg/trilinos.html
>
> Unsatisfiable dependencies
> ==========================
>
> hyperspy - not in testing
> poliastro - not in testing
> pynpoint - not in testing
> python-cogent - not in testing
> python-epimodels - not in testing
> python-fluids - not in testing
> python-loompy - not in testing
> python-numpy-groupies - not in testing
> python-pynndescent - not in testing
> python-sparse - not in testing
> sfepy - not in testing
> tiledarray - not in testing
> umap-learn - not in testing
>
> Is this enough to remove 'moreinfo'?

We can ignore everything that's not in testing, but please do look
again at those marked 'Unrelated FTBFS' where I have placed a link to
reproducible builds where they do not FTBFS.

Regards
Graham

Andrius Merkys

unread,
Jun 7, 2022, 12:40:03 PMJun 7
to
Hi Graham,

On 2022-06-03 17:14, Graham Inggs wrote:
> Unrelated FTBFS
> ===============
>
> freeture - not in testing
> gmsh - https://tests.reproducible-builds.org/debian/rb-pkg/gmsh.html
> kicad - https://tests.reproducible-builds.org/debian/rb-pkg/kicad.html
> limereg - not in testing
> madness - https://tests.reproducible-builds.org/debian/rb-pkg/madness.html
> mldemos - not in testing
> mpqc3 - not in testing
> numba - not in testing
> olive-editor - not in testing
> opencolorio - not in testing
> php-facedetect - not in testing
> pigx-rnaseq - not in testing
> pitivi - https://tests.reproducible-builds.org/debian/rb-pkg/pitivi.html
> plastimatch - #1005485
> pytorch-audio - not in testing
> pytorch-text - not in testing
> pytorch-vision - not in testing
> trilinos - https://tests.reproducible-builds.org/debian/rb-pkg/trilinos.html

I gave these a better look to find out the following actually builds fine:

gmsh
kicad
madness
pitivi

trilinos FTBFS with onetbb, but it can be patched to build without it
[1]. In the meantime I am test-rebuilding plastimatch, now unblocked by
#1005485.

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1011928#26

Best,
Andrius

Graham Inggs

unread,
Jun 12, 2022, 3:40:03 AMJun 12
to
Control: tags -1 + confirmed - moreinfo

Hi

On Tue, 7 Jun 2022 at 18:39, Andrius Merkys <mer...@debian.org> wrote:
> In the meantime I am test-rebuilding plastimatch, now unblocked by
> #1005485.

There you will hit #1012439, but plastimatch is now no longer in testing.

Please go ahead with the upload of onetbb to unstable.

Regards
Graham

Andrius Merkys

unread,
Jun 13, 2022, 5:10:03 AMJun 13
to
Hi,

On 2022-06-12 10:29, Graham Inggs wrote:
> Please go ahead with the upload of onetbb to unstable.

Uploaded. Thanks for the guidance!

Best wishes,
Andrius

M. Zhou

unread,
Jun 13, 2022, 12:00:04 PMJun 13
to
Hi Andrius,

Thank you so much for the help! I was still looking for time slot
to login into a build server to deal with this hard-to-build package.

Nowadays I sort of started to dislike packages that my laptop cannot
easily build within a few minutes :-)

Andrius Merkys

unread,
Jun 14, 2022, 6:00:03 AMJun 14
to
Hi Mo,

On 2022-06-13 18:54, M. Zhou wrote:
> Thank you so much for the help! I was still looking for time slot
> to login into a build server to deal with this hard-to-build package.

Thank you for updating the onetbb package! Building and uploading it was
not that much of a work. Admittedly, ratt-rebuilding all reverse
dependencies took quite some time and effort. I became aware of Lucas's
collab-qa-tools [1] only since, this could have saved some time.

> Nowadays I sort of started to dislike packages that my laptop cannot
> easily build within a few minutes :-)

I do not mind running unstable VM on my desktop to do builds in the
background. But yes, life is so much easier with smaller packages :)

[1] https://salsa.debian.org/lucas/collab-qa-tools

Best wishes,
Andrius

Graham Inggs

unread,
Jun 14, 2022, 6:10:04 AMJun 14
to
Hi

I've noticed some binNMUs failed on armel; mathicgb [1] (subsequently
fixed by maintainer upload) and r-cran-rcppparallel [2]. Both seem to
fail in a similar way:

/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
undefined reference to `__atomic_fetch_sub_8'
/usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
undefined reference to `__atomic_load_8'

call: dyn.load(path, local = FALSE, now = TRUE)
error: unable to load shared object '/usr/lib/arm-linux-gnueabi/libtbb.so':
/usr/lib/arm-linux-gnueabi/libtbb.so: undefined symbol: __atomic_fetch_sub_8

I also noticed the following in the armel build of onetbb [3]:

dpkg-shlibdeps: warning: symbol __atomic_fetch_sub_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries
dpkg-shlibdeps: warning: symbol __atomic_load_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries
dpkg-shlibdeps: warning: symbol __atomic_fetch_add_8 used by
debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
of the libraries

Is this something that can/should be fixed in onetbb, or should this
be fixed in the reverse-dependencies?

Additionally, r-cran-rcppparallel failed on mipsel [4] and mips64el
[5] with the following:

/usr/bin/ld: cannot find -ltbbmalloc: No such file or directory
collect2: error: ld returned 1 exit status

This seems related to #1011112 [6]. What needs to happen here?

Regards
Graham


[1] https://buildd.debian.org/status/logs.php?pkg=mathicgb&arch=armel
[2] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=armel
[3] https://buildd.debian.org/status/fetch.php?pkg=onetbb&arch=armel&ver=2021.5.0-10&stamp=1655112619&raw=0
[4] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=mipsel
[5] https://buildd.debian.org/status/logs.php?pkg=r-cran-rcppparallel&arch=mips64el
[6] https://bugs.debian.org/1011112

Andrius Merkys

unread,
Jun 14, 2022, 8:40:04 AMJun 14
to
Hi,

On 2022-06-14 13:05, Graham Inggs wrote:
> I've noticed some binNMUs failed on armel; mathicgb [1] (subsequently
> fixed by maintainer upload) and r-cran-rcppparallel [2]. Both seem to
> fail in a similar way:
>
> /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
> undefined reference to `__atomic_fetch_sub_8'
> /usr/bin/ld: /usr/lib/gcc/arm-linux-gnueabi/11/../../../arm-linux-gnueabi/libtbb.so:
> undefined reference to `__atomic_load_8'
>
> call: dyn.load(path, local = FALSE, now = TRUE)
> error: unable to load shared object '/usr/lib/arm-linux-gnueabi/libtbb.so':
> /usr/lib/arm-linux-gnueabi/libtbb.so: undefined symbol: __atomic_fetch_sub_8
>
> I also noticed the following in the armel build of onetbb [3]:
>
> dpkg-shlibdeps: warning: symbol __atomic_fetch_sub_8 used by
> debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
> of the libraries
> dpkg-shlibdeps: warning: symbol __atomic_load_8 used by
> debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
> of the libraries
> dpkg-shlibdeps: warning: symbol __atomic_fetch_add_8 used by
> debian/libtbb12/usr/lib/arm-linux-gnueabi/libtbb.so.12.5 found in none
> of the libraries
>
> Is this something that can/should be fixed in onetbb, or should this
> be fixed in the reverse-dependencies?

My guess is that libtbb12 lacks some shlib dependency, but I have little
idea where __atomic_* symbols come from.

> Additionally, r-cran-rcppparallel failed on mipsel [4] and mips64el
> [5] with the following:
>
> /usr/bin/ld: cannot find -ltbbmalloc: No such file or directory
> collect2: error: ld returned 1 exit status
>
> This seems related to #1011112 [6]. What needs to happen here?

libtbbmalloc2 is not provided for mips* architectures. I guess
bin:r-cran-rcppparallel should be RMed from mips* then.

Best,
Andrius
Reply all
Reply to author
Forward
0 new messages