Есть две или более static LIB. В каждой из них определён символ 'X' (ф-ция, например). Если их одновременно включить в процесс линковки программы, использующей этот символ, линкер не сможет определить к какому из подключенных либов следует обратиться. Нельзя ли определить символ 'X' так, чтобы указать ещё и имя LIB, вроде

externdef mylib!X SYSCALL ...

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

ЗЫ: Имя символа в либах менять нельзя.
ЗЗЫ: Это я всё разбираюсь с глюками в Dll2Lib :-)

По-моему, не существует возможности указать линкеру на это. Тебе нужен какой-то редактор таких файлов, но и о них я не слышал (мы это уже обсуждали). Надо посмотреть. Посмотрел - пост http://www.wasm.ru/forum/index.php?action=vthread&forum=5&topic=1772

Не ручаюсь, но можно попробовать: расположить LIB-ы в разные директории, а LINK-еру указать эти директории в определенной последовательности - LINK-ер должен пришить функцию, которая попадется первой.

Попытаюсь уточнить...
Всё это связано с утилитой Dll2Lib, которая конвертирует библиотеку DLL в статическую либу, но, при этом, она меняет имена ф-ций на малозначащие символы:
Первая экспортируемая ф-ция именуется 00000000
Вторая -- 00000001
Третья -- 00000002
и т.д. Все имена -- строковые константы (не числа).
Поэтому, если сконвертировать две или более DLL для одного проекта, получатся два или более символов 00000000, 00000001 и т.д. Есть два радикальных решения:
1. Написать утилиту для изменения имён ф-ций в либах (я это уже сделал вручную, но повторять это при каждом конвертировании очень неудобно)
2. Добавить ещё один OBJ с переходниками, что собственно и делает незарегистрированная версия Dll2Lib. Только вместе с переходниками она ещё всовывает NAG-лые сообщения :-) В общем, без переходников код работает лучше, быстрее и без NAG.

Тогда есть самый лучший вариант - трахнуть Dll2Lib!

Верно подмечено. Кстати, Asterix как раз пошёл этим путём (Dll2Lib запакована, закриптована и т.д.), а я всё пытался возиться с полученной либой. НО, если в зарегистрированном (крякнутом) варианте Dll2Lib не будет выдавать по OBJ на каждую ф-цию, все наши труды пропадут напрасно...

У меня баланс на данный момент такой:

• Полученный LIB прекрасно линкуется из масма
  
• NAG убран подальше вместе с таблицей переходников
  
• Имеется удобный INC для ф-ций из LIB (вместо 000000XX в INC'е нормальные имена)
  

НО
размер EXE = размер самого кода + размер LIB!!!

[ volodya: Тогда есть самый лучший вариант - трахнуть Dll2Lib!]

Там не всё так просто, во-первых прога запакована ASPR'ом,
я её распаковал в 98-й и ХР, и сравнил treeIAT с помощью
ITCompare, блин там столько отличий, что уже плохо, но обе распакованные версии работают(!).
Взломал за пару минут, но оказалось не всё так просто,
я прошёлся по тем же граблям что и одна известная хакерская
группа, кстати они потом сделали "fix". В сети я не нашёл
ни одного нормального кряка, это уже говорит о некоторой
устойчивости проги к взлому. Да и не особо удобно это ломать,
т.к. результат виден только после компиляции какого-нибудь
exe'шника с использованием сконвертированной lib'ы.

Мне, конечно, хорошо сидеть на стуле и умничать... А ты не пробовал посмотреть, ЧТО засовывает код в lib?
Скажем, дизассемблить сам lib, найти опкода инструкций, выводящих NAG и потом поискать их в самой программе?

... А ты не пробовал посмотреть, ЧТО засовывает код в lib?
Скажем, дизассемблить сам lib, найти опкода инструкций, выводящих NAG и потом поискать их в самой программе?

Идея такая была :-)
Но всё-же хотелось знать преимущества зарегённой версии, т.е. отсутствие NAG
или ещё что-то. Но если зарегённая генерит точно такую же lib'у с одним obj, то
кому оно такое надо ;-) Кстати присутствие ASPR'а наводит на мысль об отсутствии
части нужного кода в незарегённой версии, тем более что прога не имеет
ограничений по времени.

Тогда мдя...

volodya
А ты не пробовал посмотреть, ЧТО засовывает код в lib?
А это уже вопрос ко мне :-)
Даже в самом либе есть некоторая защита от взлома, что уже о многом говорит. В общем, Dll2Lib поступает следующим образом:
1. Дампит DLL в ОДИН большой OBJ-файл
2. Анализирует экспорт и переименовывает ф-ции (я об этом уже писал) Например: ф-ция _FSOUND_Init@12 превращается в 0000008B.
3. Противный Dll2Lib создаёт ещё один OBJ и заполняет его примерно следующим образом:

FSOUND_Init:
call NAG
jne <0000008B> ; <- это не число, а символ (строка)
retn
Следующая_Функция:
call NAG
jne <0000008C>
retn
. . .
Последняя,Функция:
call NAG
jne <000000E2>
retn
NAG:
Длинный_цикл ; Для лишней загрузки проца
             ; при каждом вызове ф-ций из LIB
if(первый_раз == TRUE) Показать_NAG;
retn

Хотя я всё это уже пофиксил, осталась проблема с размером кода.

Анализирует экспорт и переименовывает ф-ции (я об этом уже писал) Например: ф-ция _FSOUND_Init@12 превращается в 0000008B.

Интересно, а что если в самой проге убрать эту ерундень нахрен?

Забыл упомянуть, что единственная ф-ция без переходника -- это DllMain.

volodya
Интересно, а что если в самой проге убрать эту ерундень нахрен?
Переходники я вообще убрал через INC (определил FSOUND_Init@12 как 0000008B и таблицу переходов вместе с NAG как рукой сняло :-)

Могу бросить желающим покопаться распакованный exe'шник, но там есть таки
покриптованный немалый кусок кода, только сейчас глянул
ещё раз :-(