несоответствие версий библиотек на разных компьютерах

вариант 1 - собери всё статически

вариант 2 - поставь те же версии библиотек что на кластере

вариант 3 - сделай сборочное окружение соответствующее кластеру

1. а статические сборки на скорость исполнения кода не влияют?
и под «всё» подразумеваем только то, что не подхватывает (libgomp.so, libstdc++.so)?
2. наверное, если первое не пойдет.
3. отпадает...
спасибо. будем экспериментировать.

patchelf // thread

На кластере и компилируй, там всё для этого должно быть

Я может не всё прочитал, но как patchelf может поменять версию символов в собранном бинарнике?

На сайте написано что оно умеет только ld.so заменить да RPATH переписать.

Да, и тогда ты сможешь нормально запускать свой приветмир, без указания [пути] библиотеки (залить всеравно придется). Если совсем хочешь сделать все правильно, то надо собирать программу в окружении кластера, облака или что там у тебя. Можешь конечно и статично собрать, что и предлагали.

Ещё раз, как замена RPATH или ld.so позволит мне загрузить символы с другой версии abi в моём хеллоуворде?

Для тупых, по пунктам :)

Ещё раз, как замена RPATH или ld.so позволит мне загрузить символы с другой версии abi в моём хеллоуворде?

Ты можешь собрать libc.so и все другие либы, которые нужны так, чтобы они запускались везде. Далее складируешь их в какую-то одну, стандартную для всех компьютеров директорию. С помощью patchelf указываешь путь к этой директории через rpath. Заливаешь на все компы свою программу и библиотеки и запускаешь как ./helloworld.

решил не париться, и собирать там... (как то об этом вообще не подумал)
а как насчет openmp, оно там заработает?

Дык тогда аффтору rgB тупо

man ld.so ldconfig

А тебе точнее изьясняться:)

man ld.so ldconfig

С чего уверенность, что версии libc.so, libstdc++.so не окажутся выше, чем необходимо программе/библиотекам? Кроме rpath и ld.so есть переменная окружения LD_LIBRARY_PATH. Просто через rpath более правильно, имхо, и не надо на всех компах что-то менять, прописывать: залил архив, распаковал и все пашет из коробки.

С помощью patchelf указываешь путь к этой директории через rpath.

Зачем, когда проще загрузчик сконфигурять в рантайме. И складировать куда черная душенька моя пожелает.

Я то думал ты какой то хинт придумал как обмануть загрузчик и запустить бинарник с более старшими версиями символов с либой с более младшими (хотя как такое чудо будет работать я себе слабо представляю, до первой оптимизации дяди Васи).

Я то думал ты какой то хинт придумал как обмануть загрузчик и запустить бинарник с более старшими версиями символов с либой с более младшими

Тут кто-то выкладывал как это сделать.

Нуу, есть ещё ldconfig и ld.so.conf.d. Те же отладчики могут слать LD_LIBRARY_PATH лесом при определённых условиях(х3 баг ли это или фича).

залил архив, распаковал и все пашет из коробки

Ну согласен, что без рута сиё может быть и удобней, однако зачем тогда шить rpath какой то «левой тулой», чего бы не прошить его сразу на этапе линковки?

сразу на этапе линковки?

Да пожалуйста. Просто у человека все имеется, а бинарь строится полдня :)

Решается это сборкой своего тулчейна, товарищь DELIRIUM так завещал. Однако, потыкать в сиё решение мне на работе не дали, а дома желания не было.

http://stackoverflow.com/questions/2856438/how-can-i-link-to-a-specific-glibc...

http://www.trevorpounds.com/blog/?p=103

Лоровский пост не нашел.

gcc version 4.6.3
g++ -std=c++11 -fopenmp -O3
undefined reference to 
std::regex_token_iterator 
<__gnu_cxx::__normal_iterator<char const*,
std::basic_string<char,
std::char_traits<char>,
std::allocator<char> > >

не умеет #include «regex»

все еще печальнее

Собери свое окружение на кластере, docker там или тупо в chroot'е.

this!

gcc version 4.6.3

Ну так ещё и не совсем плохо для дефолтного.

Если кластер реально под нагрузкой, то что выдаёт module avail

Возможно там уже есть в списке доступного ПО и более свежий компилятор.

Либо собирай более новый компилятор сам (это тоже норма для кластера).

Если кластер реально под нагрузкой

он не загружен...

Возможно там уже есть в списке доступного ПО и более свежий компилятор.

знаю gcc, clang, mingw...
стоит только gcc 4.6.3

Либо собирай более новый компилятор

:) я не могу переписать пару строчек с regex на какой-нибудь split_string для gcc 4.6...
а еще разбираться как собирать компилятор...

как то, да запущу я этo все...

а еще более я не уверен в том, что #pragma omp parallel кластер подхватить...
тогда эту часть придется писать на питоне...

p.s. прав root'a нет.

конпелять на исходной системе правильным конпелятором для целевой системы, с правильными версиями глибц (такой же как на целевой) и либгомп :)

На кластере и компилируй, там всё для этого должно быть

Вообще не факт что на продакшене будут средства разработки, если админы ставят не дефолт.

На кластерах обычно так:

$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3)
...
$ module load gcc/4.8.4 
$ gcc --version
gcc (GCC) 4.8.4
...

а еще более я не уверен в том, что #pragma omp parallel кластер подхватить...

Это компилятор подхватывает. И нафиг нужен кластер, если там не многоядерные многопроцессорные узлы. Плюс не забывай указывать требуемое число ядер, для PBS что-то вида -l select=1:ncpus=20:mpiprocs=1:ompthreads=20

Вообще не факт что на продакшене будут средства разработки, если админы ставят не дефолт.

При чём тут «продакшене», если

и я скинул hello_world на кластер с pbs-планировщиком

указывать число ядер, для PBS

это уже задано...

И нафиг нужен кластер, если там не многоядерные многопроцессорные узлы.

я немного не о том...
если в планировщик задать типа:

for i=1:100
./hello_world i
end

./hello_world data.txt

$ module load gcc/4.8.4

спасибо! проверю это когда будет доступ...

p.s. прав root'a нет.

И?

Планировщик задаёт переменные окружения, в твоём случае это OMP_NUM_THREADS. Именно по этой переменной окружения подсистема OpenMP и определяет, сколько потоков по умолчанию должно быть использовано. Превышать этот предел самостоятельно на кластере НЕЛЬЗЯ иначе по рукам надают. Далее не забывай, что OpenMP - это только для одного узла, если надо задействовать больше, то это уже к MPI. Нужно знать, сколь ядер доступно на вычислительных узлах, например, на для узлов с двумя десятиядерными процами можно написать:

#!/bin/bash
#PBS -N HelloWorld20
#PBS -l select=1:ncpus=20:mpiprocs=1:ompthreads=20
#PBS -l walltime=480:00:00

cd ${PBS_O_WORKDIR}
module load gcc/4.8.4
./hello_world data20.txt

Тогда:

• будет запрошен один набор (select=1) с 20 ядрами (ncpus=20) для одного процесса (mpiprocs=1) с 20 OpenMP-потоками (ompthreads=20);
• переходим в рабочую директорию (cd ${PBS_O_WORKDIR}), не забываем, что для нас появилась новая сессия на неизвестном нам узле;
• загружаем необходимое окружение (module load gcc/4.8.4);
• выполняем нашу программу, которая прочитает переменную OMP_NUM_THREADS, которую определил PBS исходя из запроса, и будет использовать по умолчанию 20 потоков.

При таком подходе, можно сгенерировать нужное количество PBS- и входных файлов и отправить их разом в очередь. Пусть себе параллельно выполняются на разных узлах.

p.s. прав root'a нет.

И?

от куда права root у рядового пользователя «кластера с pbs-планировщиком». Так что либо пользователь сам компилирует себе на кластере необходимые инструменты и библиотеки, либо админы это делают. Как правило на таких кластерах используется environment modules для управления окружением (предоставление доступа к разным версиям ПО с учётом зависимостей). Так же есть Spack/EasyBuild/RESIF которые упрощают этот процесс.

p.s. прав root'a нет.

Можешь через Nix поставить нужное.

пришлось переписывать... отказываться от regex...
зато опыт...

Ты, как истинный профдеформированный, ответил на чей вопрос? Мне неинтересно почему у него нет рута :) Инструментов собирания чего-то на целевой машине запросто может не быть. «Потому что» (с) И админы запросто могут этого не делать, и не идти на уступки, добавляя туда инструменты разработки. Это может быть прямо запрещено :)

Так что либо пользователь сам компилирует себе на кластере необходимые инструменты и библиотеки, либо админы это делают.

Либо не делают и конпеляет у себя все сам :)

«кластер с pbs-планировщиком» -> HPC-кластер. HPC-кластер без инструментов разработчика смотрится как бред сивой кобылы.

все.
побороть несоответствие версий не получилось.
собираю и у себя и там.
это уже не проблема... когда отказался от std=c++11.
проблемы с планировщиком... но это уже другая история.

p.s. по мануалам... там и «планировщик» может компилить... и все остальное...
для кластера MPI получше будет...

p.s.s всем большое спасибо!

«кластер с pbs-планировщиком» -> HPC-кластер. HPC-кластер без инструментов разработчика смотрится как бред сивой кобылы.

«НетЪ!» Это вы привыкли к послаблениям и попустительству :)

«HPC - High Performance Cluster» (с) Где тут что-то про инструменты разработки? Аргументация инвалидная, мнение ничтожно :) Из High Performance никак не следует наличие инструментов разработчика на кластере. Хотя они, разумеется, могут быть на «интерактивных нодах»(у бедных и беспечных) или... на кластере разработчиков... или если некты кластер сделали, но не придумали чем занять — и шарят для бедных в облаке, сколько нод арендовал — все твои, не забудь привязать кредитку, а то мало ли :) Нескупой заказчик с случайно кластером в кустах, однако, лехко даже может предоставить кластер-песочницу для стейджинга и QA, где-то у себе в датацентре (некоторые, залетевшие на огонек по объявлению, даже прямо там разрабатывают, «стараясь как лучше» (ставят конпелятор, которого не было, аудит заказчика внезапно спамит руганью их руковоцтво — потом все получают по голове, резко умнеют и исправляются), ибо для деплоинга компилятор на каждой ноде (или как и вообще на боевом кластере), оказывается, не нужен от слова совсем. А HPC или «не очинь-то HPC», pbs или вхатевер — дело абсолютно десятое. Нет в политике и плане оплаты — нет на кластере, ибо нефиг и время потраченное на обогрев атмосферы компактификацией быдлокота в нули и единички будет обязательно включено в и так конский счет за кажный месяц «очинь быстрых вычислений» :)

Попробуй как-нибудь потыкать Go.

Теперь тут должен быть ниже срач про Go и HPC :)