Как конвертировать o. -> .obj?
касательно второго вопроса: вроде, надо откомпилять всю сишную часть (см. {ссылка на MSDN} а затем слинковать фортраном (см. {ссылка на MSDN})
Подправил ссылки. Кстати, они одинаковые. //Lynn
Подправил ссылки. Кстати, они одинаковые. //Lynn
Как конвертировать .o файл, созданный g77-win32 компилятором, в "нормальный" .obj?Что есть нормальный .obj?
Например, .o файл, подразумеваемый тобой -- это релокируемый ELF
(что-нибудь вроде "ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV not stripped"
или "ELF 64-bit LSB relocatable, AMD x86-64, version 1 (SYSV stripped" по диагнозу file).
В принципе, конвертировать из одного объектного формата в другой может objcopy, он использует библиотеку BFD. BFD точно знает следующие форматы: aout, COFF, ELF и MMO. Возможно, она знает и формат в
котором у тебя "нормальный .obj", или её можно этому формату обучить (в последнем случае надо иметь спецификацию формата).
Дальше. Одной конвертации формата не достаточно. Необходимо также совпадение ABI (Application Binary Interface) на вызывающей и вызываемой стороне. Это всякие мелочи, вроде соглашений, о том какие
параметры передавать в регистрах, последовательность параметров с стеке, конкретные размеры типов и т.д.
Если ABI не совпадают, придётся написать прослойку, которую вызывают по одному ABI, и которая передаёт управление дальше по другому ABI. В принципе, дело не сложное. Но писать надо будет, по крайней мере частично, на ассемблере, плюс надо иметь спецификации обоих ABI.
Ещё дальше. Код цепляемого тобой объектника скорее всего зовёт внешние функции и обращается к внешним переменным. Командой objdump -x file.o | grep "\*UND\*" можно узнать какие именно. Все эти функции и переменные необходимо ей предоставить в ABI объектника file.o.
Маленький момент. Если цепляемый объектник содержит непосредственные обращения к операционной системе,
то это, мягко говоря, полная #^%$. Так как придётся эти системные вызовы ей предоставить. И скорее всего придётся править бинарный код (если нет возможности повесить своё прерывание или свой вход по SYSENTER, в зависимости от того, как бинарник обращается к операционке). К счастью, вероятность такой #^%$ невелика.
Проверить можно командой objdump -d file.o | grep "\(int\)\|\(sysenter\)". Признак #^%$ -- наличие хоть одной строки в выводе этой команды.
Вот вобщем-то и весь перевод из одного формата в другой.
Спецификации ELF и ELF ABI у меня есть.
И ещё вопрос - есть фортрановская библиотека в виде .a - файла, как её подключить к C++ проекту под MS VC++?Задача сводится к предыдущей. .a -- это архив (распаковывается командой ar -x file.o содержащий набор .o файлов.
PS. Можно пойти другим путём -- прикрутить маршалер/демаршалер в/из сокет/сокета к нужному объектнику, и запустить сервером на одной машине с одной OS, а с другой машины (с другой OS) делать RPC.
касательно второго вопроса: вроде, надо откомпилять всю сишную часть (см. {ссылка на MSDN} а затем слинковать фортраном (см. {ссылка на MSDN})Ему это не поможет. Посмотри внимательно -- у него библиотека фортрановая в файле с разрешением .a.
Как ты думаешь, под какую она систему? Ставлю на то, что это ar-овский архив. Соответственно, лежат в нём ELF'ы.
Подправил ссылки. //Lynn
Вас не затруднит делать ссылки покороче, с помощью кнопочки URL?
Не вмещается по длине в 1024х768 при размере шрифта порядка 12 пунктов.
Не вмещается по длине в 1024х768 при размере шрифта порядка 12 пунктов.
Вас не затруднит делать ссылки покорочеЭто не мои ссылки. Если вы заметили, там стоит цитата на пост предыдущего оратора. Вероятно, к нему вам и следует обращаться.
Если ВЫ ОБА их не укоротите, ситуация не изменится.
Большое спасибо за весьма содержательный ответ. Попробую уточнить ситуацию:
:Я работаю под Windows, и доступа к *nix-машинам не имею (равно как и места для установки одной из них). Под "нормальным" obj я подразумеваю "obj-файл, сгенерированный компилятором cl.exe или же другим, ему подобным (e.g., F77.exe, F90.exe из Compaq Visual Fortran 6.6c). При этом, .o-файл, сгенерированный компилятором g77 (версия для win32) не является "нормальным", ибо его формат ен совместим с форматом, используемым линкером из MS VS 2003.
Что есть нормальный .obj?
:К счастью, нет - это библиотека линейной алгебры SLATEC.
Задача сводится к предыдущей. .a -- это архив (распаковывается командой ar -x file.o содержащий набор .o файлов.
<...>
Код цепляемого тобой объектника скорее всего зовёт внешние функции и обращается к внешним переменным
g77 (версия для win32)Если там рядом с этим фортраном есть версия objcopy (из пакета binutils) для win32, есть надежда, что она сможет конвертнуть в .obj.
Увы, нет 
PS. Наконец-то добрался до машины с Linux-ом. Нельзя ли поподробнее рассказать про "рецепт" с objcopy?
PPS. Вот что пишет "file":
.o -> "80386 COFF executable not stripped - version 30821",
.obj -> "80386 COFF executable not stripped - version 25970".
PS. Наконец-то добрался до машины с Linux-ом. Нельзя ли поподробнее рассказать про "рецепт" с objcopy?
PPS. Вот что пишет "file":
.o -> "80386 COFF executable not stripped - version 30821",
.obj -> "80386 COFF executable not stripped - version 25970".
o -> "80386 COFF executable not stripped - version 30821",Тогда они по идее должны линковаться. COFF, правда, кривой формат, может они и несовместимы.
.obj -> "80386 COFF executable not stripped - version 25970".
Если не линкуются, напиши как ругается линкер. Может ему просто расширение .o не нравится и
простое переименование поможет.
Кстати, по идее в windows должен быть PE COFF, а не просто COFF, стоит проверить.
Если линкуются, но не работает -- вероятно разные ABI.
Нельзя ли поподробнее рассказать про "рецепт" с objcopy?objcopy file.o file.obj -O <bfd_name>
bfd_name -- что-нибудь вроде coff-i386. Точнее можно узнать посмотрев, что выдает
strings /usr/lib64/libbfd.a | grep coff
вместо /usr/lib64/libbfd.a надо указать путь к библиотеке BFD. Искать надо в библиотеке под windows,
objcopy использовать тоже тот, что под windows.
Тогда они по идее должны линковаться.Я пробовал разными способами цеплять эту библиотеку - и добавляя как dependency, и через #pragma comment(lib, ...) - такое впечатление, что линкер "не видит" этот файл, и, как следствие, ругается на отсутствующие символы (хотя при компиляции аналогичногоо кода через g77-win32 --- всё работает).
Переименование я пробовал - не работает. Сейчас, конечно, перепроверю...
В общем, как я понимаю, всё совсем плохо?...
В общем, как я понимаю, всё совсем плохо?...Ну, как минимум очень странно.
Запость как выглядят objdump -x <file.o> и objdump -x <file.obj>. Только objdump нужен под windows (или как минимум, чтобы он понимал COFF).
Пока я на это дело гляну, попробуй слинковать не тем линкером, которым ты пытался, а каким-нибудь другим. Первый кандидат -- GNU ld под windows. А здесь есть целый список линкеров.
Ок, по ходу недели поэкспериментирую. Но, как я уже вроде писал, линкером из комплекта g77-win32 всё нормально соьирается (но он, судя по README, не должен жевать obj-и от MS VC, а gcc в комплекте нет).
Такой вопрос, из util.obj экспортятся только эти символы (переменные, функции)
?
Все остальные символы там не читаемы (в стиле $SG2156) и их нельзя подцепить линкером, можно только релокировать. Если среди них есть экспортящиеся, то только линкер, знающий как расшифровать их настоящие имена сможет слинковать этот файл.
Ещё вопрос: эти символы из dgefa.o
как экспортятся, как idamax, dscal и daxpy? (И вообще, это настоящие функции?)
Если да, то заметно следующее:
в .o-файле все символы имеют вид _<экспортируемое имя>_, а в .obj-файле -- _<экспортируемое имя>.
То есть, может помочь extern "C" <экспортируемое имя>_; или даже extern "C" _<экспортируемое имя>_ (вместо extern "C" <экспортируемое имя>;) на стороне VC для подключения .o-файла.
_delay_output
_PDC_usleep
_flushinp
_c_ungind
_c_pindex
_c_gindex
_traceon
_trace_on
_traceoff
_strbuf
_PDC_usleep
_c_gindex
_c_pindex
_c_ungind
_trace_on
_trace_on
_unctrl
_keyname
_delay_output
_flushinp
_traceon
_traceoff
?
Все остальные символы там не читаемы (в стиле $SG2156) и их нельзя подцепить линкером, можно только релокировать. Если среди них есть экспортящиеся, то только линкер, знающий как расшифровать их настоящие имена сможет слинковать этот файл.
Ещё вопрос: эти символы из dgefa.o
_idamax_
_dscal_
_daxpy_
как экспортятся, как idamax, dscal и daxpy? (И вообще, это настоящие функции?)
Если да, то заметно следующее:
в .o-файле все символы имеют вид _<экспортируемое имя>_, а в .obj-файле -- _<экспортируемое имя>.
То есть, может помочь extern "C" <экспортируемое имя>_; или даже extern "C" _<экспортируемое имя>_ (вместо extern "C" <экспортируемое имя>;) на стороне VC для подключения .o-файла.
README в студию.
Такой вопрос, из util.obj экспортятся только эти символы (переменные, функции)Вроде да (это кусок pdCurses - порта nCurses для win32).
Ещё вопрос: эти символы из dgefa.oДа, это настоящие функции.
_idamax_
_dscal_
_daxpy_
как экспортятся, как idamax, dscal и daxpy? (И вообще, это настоящие функции?)
README попозже опубликую (lorien -> "g77-bin").
в .o-файле все символы имеют вид _<экспортируемое имя>_, а в .obj-файле -- _<экспортируемое имя>.Гугл, когда я его спросил, подкинул именно этот рецепт, но он не помог. Перечитал README - видимо, ошибся про тот gcc.
То есть, может помочь extern "C" <экспортируемое имя>_; или даже extern "C" _<экспортируемое имя>_ (вместо extern "C" <экспортируемое имя>;) на стороне VC для подключения .o-файла.
Вопрос из практической сферы (т.е. - НАДО!) переходит в сферу теоретическую (а можно ли...?).
Но актуальности для меня не теряет!
Попробуй линковать другими линкерами.
Оставить комментарий
Bird_V
Как конвертировать .o файл, созданный g77-win32 компилятором, в "нормальный" .obj?И ещё вопрос - есть фортрановская библиотека в виде .a - файла, как её подключить к C++ проекту под MS VC++?
Варианты типа "перекомпилировать" и "перейти на linux/перейти на gcc" идут в топку. Первые - потому что исходников у меня нет. Вторые - из принципа.