Зачем избавляться от _этих_ зависимостей? Они ж почти везде есть.

Red Had? это что - Red Hat пустила местастазы?

пересобираю пакет под другую систему, расхождение в зависимостях выходит, вот и нужно избавиться, а если нельзя, то почему ?

Если собираешь gcc >= 4.4, то можно линковаться статически.

Для 4.4 http://www.trilithium.com/johan/2005/06/static-libstdc/ тут описан хак, как это сделать. Для 4.5 и выше линкуешься с ключами

-static-libgcc -static-libstdc++

и всё.

пересобираю пакет под другую систему, расхождение в зависимостях выходит, вот и нужно избавиться, а если нельзя, то почему ?

Используй mock: http://fedoraproject.org/wiki/Projects/Mock

спасибо за статью, буду читать, обязательно отпишусь что вышло (если конечно это интересно) так как gcc version 4.4.5

> > пересобираю пакет под другую систему, расхождение в зависимостях выходит, вот и нужно избавиться, а если нельзя, то почему ?

Используй mock: http://fedoraproject.org/wiki/Projects/Mock

обязательно покурю тему, спасибо ... работаю в девственно чистой среде - под чрутом, мне что нибудь мок даст дополнительное ? (для чего он - вот к чему свелся ответ)

работаю в девственно чистой среде - под чрутом, мне что нибудь мок даст дополнительное ?

Если у тебя в чруте развёрнут целевой дистрибутив, то почему левые зависимости получаются? mock, в принципе, только готовит чрут и собирает пакет в нём.

> Если у тебя в чруте развёрнут целевой дистрибутив, то почему левые зависимости получаются? mock, в принципе, только готовит чрут и собирает пакет в нём.

сделаю предположение, что под другой системой он собирался с другой версией компилятора, откуда возможна сборка уже с динамически разделяемой либой, а была, скажем, статической

В чруте нужно развернуть целевую систему, и собирать пакет её компилятором и с её библиотеками.

SOLVED (спасибо DELIRIUM за статью)

Сборка пакета происходила в 64 разрядной среде используя исходник src.rpm. Пересобранные пакеты показывали зависимости от libgcc_s.so.1 и libstdc++.so.6, от чего, собственно, и нужно было избавиться. Прочитав статью http://www.trilithium.com/johan/2005/06/static-libstdc/ было найдено решение - собирать пакет статически (без shared object при динамической линковке). В моем случае нужно было править spec файл, чтобы на выходе получить rpm пакеты собранные в моей системе (в моем chroot'е).

В spec файл добавляется в раздел %prep:
ln -s `g++ -print-file-name=libstdc++.a`
что создаст одноименную названию либы симлинку libstdc++.a.

Далее, в разделе %build перед %configure (скажем, на строку выше) добавляем:
export LDFLAGS="-L%{_builddir}/bacula-%{version} -static-libgcc"
(в моем случае %{_builddir}/bacula-%{version} это место, где создалась симлинка, и переменная компоновщика $LDFLAGS укажет место/путь к необходимой/установленной библиотеке)

После сборки, зависимости исчезли.

* -static-libgcc в переменных $CPPFLAGS, $CFLAGS не дали подобного результата, хотя думал, что именно в них нужен этот параметр
** компетентные линуксоиды, поправки желательны :)