Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#46160 - [intel-tbb] missing iRML libs?

Attached to Project: Arch Linux
Opened by Leonard König (LeonardK) - Monday, 31 August 2015, 12:55 GMT
Last edited by Anatol Pomozov (anatolik) - Wednesday, 27 January 2016, 04:29 GMT
Task Type Feature Request
Category Packages: Extra
Status Waiting on Response
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Description:
The intel-tbb archive provided by intel also is the source to build iRML (intel Resource Management Layer). Maybe the libirml.so should be included into this package (or built seperately?).
To build just run 'make rml' in the root directory. There are some programs that want to link against that library but so far I could not find any package that provides it. Some games on steam just ship the libary themselves but most just search (and fail to find it) but ignore that.

Additional info:
* package version(s): latest (4.3_20150611-1)
* config and/or log files etc.:

LD_DEBUG on unity-editor binary:

26751: find library=libirml.so.1 [0]; searching
26751: search path=/opt/Unity/Editor/Data/Tools:/opt/Unity/Editor (RPATH from file ./Unity)
26751: trying file=/opt/Unity/Editor/Data/Tools/libirml.so.1
26751: trying file=/opt/Unity/Editor/libirml.so.1
26751: search cache=/etc/ld.so.cache
26751: search path=/usr/lib/tls/x86_64:/usr/lib/tls:/usr/lib/x86_64:/usr/lib (system search path)
26751: trying file=/usr/lib/tls/x86_64/libirml.so.1
26751: trying file=/usr/lib/tls/libirml.so.1
26751: trying file=/usr/lib/x86_64/libirml.so.1
26751: trying file=/usr/lib/libirml.so.1


Steps to reproduce:
For example install unity-editor from the AUR and run
LD_DEBUG=libs /opt/Unity/Editor/Unity
This task depends upon

Comment by Anatol Pomozov (anatolik) - Thursday, 03 September 2015, 03:55 GMT
I am fine with building this library. I can add it. Eric, any objections?
Comment by Anatol Pomozov (anatolik) - Tuesday, 08 September 2015, 17:12 GMT
Running 'make rml' fails for me:


g++ -c -MMD -DTBB_USE_DEBUG -DDO_ITT_NOTIFY -g -O0 -DUSE_PTHREAD -m64 -Wall -fno-rtti -fno-exceptions -Wno-parentheses -Wno-non-virtual-dtor -I../../src -I../../src/rml/include -I../../include -I../../src/rml/include -I. -I../../src/test -I../../src/rml/server -fPIC ../../src/rml/test/rml_omp_stub.cpp
gcc -DTBB_USE_DEBUG -DDO_ITT_NOTIFY -g -O0 -DUSE_PTHREAD -m64 -Wall -o test_rml_omp_c_linkage.exe test_rml_omp_c_linkage.o rml_omp_stub.o omp_dynamic_link.o -lpthread -lrt -ldl -Wl,-rpath-link=. -rdynamic
./test_job_automaton.exe
done
./test_thread_monitor.exe
done
./test_rml_tbb.exe
done
./test_rml_omp.exe
done
./test_rml_mixed.exe
Assertion my_make_server_routine failed on line 86 of file ../../src/rml/client/rml_factory.h
../../build/Makefile.rml:150: recipe for target 'rml_test' failed
make[1]: *** [rml_test] Aborted (core dumped)
make[1]: Leaving directory '/home/anatol/sources/core-arch/intel-tbb/trunk/src/tbb43_20150611oss/build/linux_intel64_gcc_cc5.2.0_libc2.22_kernel4.2.0_debug'
Makefile:50: recipe for target 'rml' failed
make: *** [rml] Error 2
Comment by Leonard König (LeonardK) - Friday, 25 September 2015, 17:33 GMT
Hm, just tried it myself and got the same result. Interestingly the `rml` target is not in `all`. But even one submake in `all` (`test` more specifically `test_tbb_plain`) fails, as I also get:

TBB Warning: RML might limit the number of workers to 7 while 15 is requested.

Call stack info (6):
./test_tbb_fork.exe(_Z16print_call_stackv+0x44)[0x4045ba]
./test_tbb_fork.exe(_Z11ReportErrorPKciS0_S0_+0x1d)[0x4046a3]
./test_tbb_fork.exe(_Z8TestMainv+0x377)[0x404f45]
./test_tbb_fork.exe(main+0x2d)[0x404a1a]
/usr/lib/libc.so.6(__libc_start_main+0xf0)[0x7f976d601610]
./test_tbb_fork.exe(_start+0x29)[0x4044a9]
../../src/test/test_tbb_fork.cpp:195, assertion 0: Hang after fork
../../build/Makefile.test:251: recipe for target 'test_tbb_plain' failed
make[1]: *** [test_tbb_plain] Aborted (core dumped)
make[1]: Leaving directory '/home/leonard/Downloads/intel-tbb/tbb44_20150728oss/build/linux_intel64_gcc_cc5.2.0_libc2.22_kernel4.1.8_debug'
Makefile:44: recipe for target 'test' failed
make: [test] Error 2 (ignored)

The error in the `rml` target is that the assertion failed that 'factory' could not be opened - at least that's the comment above the critical line:

Assertion my_make_server_routine failed on line 86 of file ../../src/rml/client/rml_factory.h


Yet it builds target `rml` (of ./build/Makefile.rml - not ./Makefile) just fine. One just needs to adjust the `default_rml` target (of ./build/Makefile.rml) to not include `rml_test` - or only remove the line

$(run_cmd) ./test_rml_mixed.$(TEST_EXT) $(args)

As long as nobody utilises 'factory' in their use of libiRML there should be nothing to be noticed. You need to decide whether to ship though ^^
Comment by Anatol Pomozov (anatolik) - Friday, 25 September 2015, 17:38 GMT
Could you please clarify this test failure with upstream? The test should fail like this and it should be fixed.
Comment by Leonard König (LeonardK) - Friday, 25 September 2015, 17:43 GMT
Yep, I'm currently gathering more info on what is failing exaclty to not come with empty hands if possible. Sadly I could not find any info about this assert failing via web search :/
We have 2 asserts failing, one in tbb and one in iRML - but in the case of RML the tests are done by default, that's why one doesn't notice the failing tbb_test (maybe we could add the tests into the check() section of the PKGBUILD?)

Will see what I can find out.
Comment by Leonard König (LeonardK) - Friday, 25 September 2015, 21:23 GMT
Yep, I'm currently gathering more info on what is failing exaclty to not come with empty hands if possible. Sadly I could not find any info about this assert failing via web search :/
We have 2 asserts failing, one in tbb and one in iRML - but in the case of RML the tests are done by default, that's why one doesn't notice the failing tbb_test (maybe we could add the tests into the check() section of the PKGBUILD?)

Will see what I can find out.
Comment by Anatol Pomozov (anatolik) - Wednesday, 27 January 2016, 04:29 GMT
Any update on the issue?
Comment by Leonard König (LeonardK) - Friday, 29 January 2016, 23:39 GMT
Oh, I'm sorry, I thought I've already replied to this :/

I've contacted upstream here, but they are basically saying that albeit the source being 'part' of the distribution it's not really for building it yourself. One should rely on the binary distribution by programs that need it instead.
https://software.intel.com/en-us/forums/intel-threading-building-blocks/topic/594395

So one should probably contact programs that use iRML (like Unity) instead and ask them to ship the library instead of relying on building it ourselves... .
Comment by Gustavo Alvarez (sl1pkn07) - Sunday, 03 October 2021, 18:14 GMT
Hi. any posibility to bump this?

some packages needs the library libirml.so created by TBB

other distributions already include it

"https://pkgs.org/download/libirml.so.1()(64bit)"

greetings
Comment by loqs (loqs) - Sunday, 03 October 2021, 18:51 GMT
@sl1pkn07 which packages need libirml.so? What do those packages do for TBB 2021 which removed rml?
Comment by Gustavo Alvarez (sl1pkn07) - Sunday, 03 October 2021, 18:59 GMT
for example, opencl-cpu provided by intel needs that library

strace clinfo when intel opencl stack is installed
~~~
openat(AT_FDCWD, "/usr/lib/glibc-hwcaps/x86-64-v3/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/glibc-hwcaps/x86-64-v3", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/glibc-hwcaps/x86-64-v2/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/glibc-hwcaps/x86-64-v2", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/tls/haswell/x86_64/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/tls/haswell/x86_64", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/tls/haswell/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/tls/haswell", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/tls/x86_64/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/tls/x86_64", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/tls/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/tls", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/haswell/x86_64/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/haswell/x86_64", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/haswell/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/haswell", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/x86_64/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib/x86_64", 0x7ffc818878a0, 0) = -1 ENOENT (No existe el fichero o el directorio)
openat(AT_FDCWD, "/usr/lib/libirml.so.1", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No existe el fichero o el directorio)
newfstatat(AT_FDCWD, "/usr/lib", {st_mode=S_IFDIR|0755, st_size=471040, ...}, 0) = 0
munmap(0x7f4f93dff000, 372176) = 0
~~~

opencl cpu provides by, or via https://github.com/intel/llvm/blob/sycl/buildbot/dependency.conf , or via intel-oneapi-runtime-opencl provides by https://software.intel.com/content/www/us/en/develop/documentation/installation-guide-for-intel-oneapi-toolkits-linux/top/installation/install-using-package-managers/apt.html (yes, is deb packages. but can install it by hand after extract)

greetings
Comment by Anatol Pomozov (anatolik) - Sunday, 03 October 2021, 19:18 GMT
> One should rely on the binary distribution

Pulling a binary into Arch package is no-go.


I see that intel-tbb/tbb package switched to https://github.com/oneapi-src/oneTBB
and it mentions rml here https://github.com/oneapi-src/oneTBB/tree/master/python/rml

Gustavo, are you interested in this rmlserver library ^^?
Comment by Gustavo Alvarez (sl1pkn07) - Sunday, 03 October 2021, 19:30 GMT
if build libirml.so.1, yes XD. i test it rigth now. but seems not avail :(

i will talk with upstream for what happen with that library

sorry for the noise

greetings
Comment by Anatol Pomozov (anatolik) - Sunday, 03 October 2021, 19:44 GMT
python/rml is under python directory and it requires following cmake flag "-DTBB4PY_BUILD=ON". But even with it "install" phase fails with

```
-- Installing: /build/tbb/pkg/tbb/usr/lib/libtbbmalloc_proxy.so
CMake Error at python/cmake_install.cmake:46 (file):
file INSTALL cannot find "/build/tbb/src/oneTBB-2021.3.0/python/./build":
No such file or directory.
Call Stack (most recent call first):
cmake_install.cmake:86 (include)


FAILED: CMakeFiles/install.util
```

That sounds like an upstream issue.
Comment by Gustavo Alvarez (sl1pkn07) - Sunday, 03 October 2021, 19:49 GMT
ctest also fails about missing python modules when test


~~~
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.9.7", minimum required is "3.5")
CMake Error at /tmp/makepkg/tbb/src/oneTBB-2021.3.0/cmake/python/test_launcher.cmake:21 (message):
Cannot find oneTBB Python module
~~~

EDIT: mi fault. nothig

greetings
Comment by Gustavo Alvarez (sl1pkn07) - Sunday, 03 October 2021, 20:53 GMT
finally

is not a bug.

~~~
# Maintainer: Felix Yan <felixonmars@archlinux.org>
# Contributor: Stéphane Gaudreault <stephane@archlinux.org>
# Contributor: Thomas Dziedzic < gostrc at gmail >
# Contributor: Denis Martinez <deuns.martinez AT gmail.com>
# Contributor: Bogdan Burlacu <bogdan.burlacu AT pm.me>

pkgname=tbb
pkgver=2021.3.0
pkgrel=3
pkgdesc='High level abstract threading library'
arch=('x86_64')
url='https://www.threadingbuildingblocks.org/'
license=('Apache')
depends=('gcc-libs')
makedepends=('cmake' 'inetutils' 'swig' 'python')
conflicts=('intel-tbb')
provides=("intel-tbb=$pkgver")
replaces=('intel-tbb')
source=(https://github.com/oneapi-src/oneTBB/archive/v$pkgver/$pkgname-$pkgver.tar.gz
tbb-gcc-11-433.patch::https://github.com/oneapi-src/oneTBB/pull/433.patch
tbb-gcc-11-447.patch::https://github.com/oneapi-src/oneTBB/pull/447.patch)
sha512sums=('969bc8d1dcf50bd12f70633d0319e46308eb1667cdc6f0503b373a35dcb2fe6b2adf59c26bd3c8e2a99a8d2d8b9f64088db5a43e784218b163b3661d12908c0e'
'bd6bfd46c74f45c786c20f72654b554fd20bd105c0739e2e98b17b801f07ee149581df0c4e6f8ed2111dad9da8a9361b5e532572be30604dda32d49102bdca03'
'756faf918c56115007241e607590d1d370d45bca9313125987d739a271e022a47043f4bd4f47633c9239e1033299876899c3769d7ae17cfaefb114a5462cda95')

prepare() {
mkdir -p build
patch -d oneTBB-$pkgver -p1 < tbb-gcc-11-433.patch
patch -d oneTBB-$pkgver -p1 < tbb-gcc-11-447.patch
}

build() {
cd build
cmake ../oneTBB-$pkgver \
-DCMAKE_INSTALL_PREFIX=/usr \
-DTBB4PY_BUILD=ON

make
make python_build
}

check() {
cd build
ctest --output-on-failure
}

package() {
cd build
make DESTDIR="$pkgdir" install
}
~~~
Comment by Gustavo Alvarez (sl1pkn07) - Sunday, 03 October 2021, 21:05 GMT
ops. other window with se same reply. sorry
Comment by Anatol Pomozov (anatolik) - Monday, 04 October 2021, 00:09 GMT
Gustavo, I enabled python and merged it to SVN repo as revision 425061. Please check it.

I did not build any binary package as it requires rebuilding dependencies. It is better if it done by Felix.
Comment by loqs (loqs) - Monday, 04 October 2021, 09:55 GMT
TBB 2021 is blocked by https://github.com/PixarAnimationStudios/USD/issues/1600 everything else has support or can be trivially patched or in the case of suitesparse is switching to openmpi rather than supporting it.

Loading...