Привет всем!

Была у меня на днях одна проблема...

Дано:

1. Система Linux c установленными компиляторами gcc 2.95.4 и 4.3.1.
2. gcc 2.95.4 установлен в /usr, 4.3.1 — в /usr/local.
3. Разделяемая библиотека (so) написанная на С++, но имеющая pure C интерфейс. Библиотека компилируется только gcc 4.3.1.
4. Несколько приложений (тестовых) на Си и С++, собранных 2.95.4 (тип 1) и 4.3.1 (тип 2), использующих эту библиотеку.

Если мы используем библиотеку из приложений типа 2 (не важно С или С++), то все нормально, что в принципе ожидаемо.
Если мы используем библиотеку из приложений типа 1 (не важно С или С++), то появляется ошибка сегментации.

Прблема в С++ runtime. Он пытается использовать его от 2.95.4. Пока что решение проблемы состоит в том, чтобы линковать С++ runtime статически к библиотеке. В этом случае ошибки пропадают.

А вопрос такой: вот допустим библиотека захочет использовать какую-нибудь so-шку, написанную на C++, которая С++ runtime линкует динамически. Все обвалится. Каким бы таким хитрым образом изменить способ решения проблемы, чтобы этого избежать? Я пробовал колдовать с -rpath-link, но к положительным результатм не пришел.

Самое главное — избежать лишних телодвижений со стороны пользователей библиотеки. То есть они должны писать

gcc mycpp.c -l<lib name> -o myapp

и получать работающее приложение.

Заранее спасибо.

Здравствуйте, Аноним, Вы писали:

А>А вопрос такой: вот допустим библиотека захочет использовать какую-нибудь so-шку, написанную на C++, которая С++ runtime линкует динамически. Все обвалится. Каким бы таким хитрым образом изменить способ решения проблемы, чтобы этого избежать? Я пробовал колдовать с -rpath-link, но к положительным результатм не пришел.

суть проблемы состоит в том, что они несовместимы. твой вопрос аналогичен "во что мне одеть мужика, чтобы его можно было использовать как женщину?"

On 23.04.2011 15:25, Аноним 694 wrote:

Я ничего не понял, тип 1, тип 2 ...
Главное -- в одном приложении должен быть ОДИН С/С++
рантайм, ОБЩИЙ для всего приложения и всех используемых
библиотек. Поскольку обычно в lin библиотеки делаются
бинарно обратно совместимыми, то использовать везде 4.3.1
было бы более правильно, и в принципе всё должно работать.
Но 2.95 -- это очень старая версия, не знаю, как там с
совместимостью с 4.

On 23.04.2011 15:25, Аноним 694 wrote:

> Самое главное — избежать лишних телодвижений со стороны пользователей
> библиотеки. То есть они должны писать
>
> gcc mycpp.c -l<lib name> -o myapp
>
> и получать работающее приложение.

А вообще, нафига тебе два GCC ? Удали старый, и пересобери
старые библиотеки на новом, если не будут работать.

Здравствуйте, MasterZiv, Вы писали:

MZ>On 23.04.2011 15:25, Аноним 694 wrote:

>> Самое главное — избежать лишних телодвижений со стороны пользователей
>> библиотеки. То есть они должны писать
>>
>> gcc mycpp.c -l<lib name> -o myapp
>>
>> и получать работающее приложение.

MZ>А вообще, нафига тебе два GCC ? Удали старый, и пересобери
Нельзя. Такие правила, я тут не решаю.
MZ>старые библиотеки на новом, если не будут работать.
Не будут.

Здравствуйте, MasterZiv, Вы писали:

MZ>On 23.04.2011 15:25, Аноним 694 wrote:

MZ>Я ничего не понял, тип 1, тип 2 ...
Тип 1, тип 2 — это наоборот для понятности, приложения собираемые 2.95 — это первый тип, приложения собираемые 4.3.4 — это второй тип.
MZ>Главное -- в одном приложении должен быть ОДИН С/С++
MZ>рантайм, ОБЩИЙ для всего приложения и всех используемых
MZ>библиотек.
Это понятно. Еще раз объясняю на пальцах: есть so-шка собранная 4-м копилятором на С++. Задача: иметь возможность использовать эту so-шку из приложений типа 1 и приложений типа 2 (см. выше). Для этого у so-шки pure C интерфейс. Но so-шка тащит с собой зависимость от libgcc.so и libstdc++.so от 4.3.4. Когда мы линкуем ее с 2.95, то происходит попытка использовать другой libgcc.so и все падает. Я решил проблему, прилинковав к нашей so-шке libgcc.a и libstdc++.a. Но теперь возник другой вопрос, каким образом сделать так, что с этой so-шкой можно было линковать библиотеки на С++, которые сторонние и цепляют libgcc.so и libstdc++.so. Это же получается классическая схема разных рантаймов, такое работать
не должно. Вот я и спрашиваю, можно ли сделать так, чтобы заработало и с учетом первой проблемы и с учетом второй. Я вот склоняюсь, к тому, что совсем нельзя, но совета спросить решил, перед тем как окончательное решение принимать.

MZ>Поскольку обычно в lin библиотеки делаются
MZ>бинарно обратно совместимыми, то использовать везде 4.3.1
MZ>было бы более правильно, и в принципе всё должно работать.
MZ>Но 2.95 -- это очень старая версия, не знаю, как там с
MZ>совместимостью с 4.
Бинарной совместимости с 2.95 нет.

Здравствуйте, Аноним, Вы писали:

MZ>>А вообще, нафига тебе два GCC ? Удали старый, и пересобери
А>Нельзя. Такие правила, я тут не решаю.
Такие решальщики не поймут, если ты так сделаешь. Когда-нибудь вскроется, но будет поздно. А может вообще не вскрыться.
MZ>>старые библиотеки на новом, если не будут работать.
А>Не будут.
Пробовал, или у Ванги спросил?

Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, Аноним, Вы писали:

MZ>>>А вообще, нафига тебе два GCC ? Удали старый, и пересобери
А>>Нельзя. Такие правила, я тут не решаю.
Ops>Такие решальщики не поймут, если ты так сделаешь. Когда-нибудь вскроется, но будет поздно. А может вообще не вскрыться.
Ничего не понял. Решальщики как раз в курсе, это с их подачи я делаю вышеизложенный костыль.

MZ>>>старые библиотеки на новом, если не будут работать.
А>>Не будут.
Ops>Пробовал, или у Ванги спросил?
Не будут старые библиотеки работать на новом gcc, они так написаны, с завязкой на особенности 2.95. Переписывать их — большой труд.

On 24.04.2011 15:11, Аноним 962 wrote:

> Не будут старые библиотеки работать на новом gcc, они так написаны, с завязкой
> на особенности 2.95. Переписывать их — большой труд.

В смысле они не собираются на чём-то более поздним чем gcc 2.95 ?

Здравствуйте, MasterZiv, Вы писали:

MZ>On 24.04.2011 15:11, Аноним 962 wrote:

>> Не будут старые библиотеки работать на новом gcc, они так написаны, с завязкой
>> на особенности 2.95. Переписывать их — большой труд.

MZ>В смысле они не собираются на чём-то более поздним чем gcc 2.95 ?
Так точно.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Ops, Вы писали:

Ops>>Здравствуйте, Аноним, Вы писали:

MZ>>>>А вообще, нафига тебе два GCC ? Удали старый, и пересобери
А>>>Нельзя. Такие правила, я тут не решаю.
Ops>>Такие решальщики не поймут, если ты так сделаешь. Когда-нибудь вскроется, но будет поздно. А может вообще не вскрыться.
А>Ничего не понял. Решальщики как раз в курсе, это с их подачи я делаю вышеизложенный костыль.
Понятно, что с их подачи, подругому никак. Все-таки помедитируй над моим постом.

Здравствуйте, Ops, Вы писали:

Ops>Здравствуйте, Аноним, Вы писали:

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