C++Builder компилит только те файлы, которые включены в проект. Если не включить какой-либо файл в проект и подключить его include'ом (и, естественно использовать его в программе), то в процессе компиляции объектники для него созданы не будут. И как следствие - ошибка линковки...
Дело в том, что у меня исходники либы (xercesc) представлены огромным числом файлов. Необходимые хидеры я подключаю include'ом. При этом в проект их не вношу, т.к. внести в проект придётся не только подключаемые файлы, но и те, которые используются подключаемыми файлами...

Т.е. нужно, чтобы IDE автоматически включала в проект все используемые файлы, либо указать компилятору Borland, чтобы он создавал объектники для всех используемых файлов.
Как это сделать ?

Бред какой-то. 
Хочешь использовать любой файл obj, lib.. - добавь его в проект. Если это не исходник - компилятор его транслировать не будет (не барское это дело). Если чего-то линкеру не хватит - придется ручками добавить.


А как еще можно подключить headers?

Вообще то нужно открыть проект xercesc и собрать библиотеку( lib и dll ) и уже их использовать в проекте. Потребуется в свои cpp включит пару хидеров с помощью #include  да указать линковщику , что нужно использовать библиотеку xercesc 

>pandrew
>А как еще можно подключить headers? 

Ты меня прям озадачил...
Что ж, попробую найти способ...

Vyacheslav
Пытаюсь, BCB6. Только вот ошибка всё портит:

[RC Error] Version.rc(10)

там: #include "winres.h"
но файла winres.h нигде и в помине нет...

Начальный фрагмент файла Version.rc:

//Microsoft Developer Studio generated resource script.
//
#include "resource.h"

#define APSTUDIO_READONLY_SYMBOLS
/////////////////////////////////////////////////////////////////////////////
//
// Generated from the TEXTINCLUDE 2 resource.
//
#include "winres.h"


/////////////////////////////////////////////////////////////////////////////
#undef APSTUDIO_READONLY_SYMBOLS

...


В VC и не пытался, т.к. пишу в BCB6, а calling convention у них разные...

Добавлено @ 23:28 
Vyacheslav, вы работали с xerces ?

Ну что за народ ленивый пошел. Включи ты в проект все файлы библиотеки и не мучайся. По другому никак.

Я вот тоже использовал либу mpich так подключал все хеадеры + либы нужные.

Akeem, по-другому можно:
1. Получить объектники и их юзать
2. Получить dll и её юзать
3. Каким-то образом указать make'у, чтобы все заinclude'нные хидеры в случае необходимости подвергались компиляции (без включения их в проект)...

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

А нужные хидеры отобрать тоже будет весьма затруднительно...

>pandrew
>А как еще можно подключить headers? 

Например, через параметры компилятора...


Что касается сборки dll-ки XercesLib.dll, то кроме той ошибки (тот include я закомментил), имеются и другие, в частности, в папке internal отсутствуют следующие .cpp-файлы, указанные в Xerces-all.bpg и XercesLib\XercesLib.bpr:
- XTemplateComparator
- XObjectComparator
(может есть ещё...)

Это что - мои глюки или разработчики чего-то недодумали...

Вообще-то такой файл есть в  $(BCB)\include\mfc


Да, только использовал ее в VS2005


А какая разница, если будете использовать библиотеку как dll?. Я бы на Вашем месте вообще бы не мучался. Взял  готовую XercesLib.dll. А библиотеку импорта  получил бы с помощью implib.



Поскольку в проекте для VS их нет, то думаю, их смело можно выкинуть

>Вообще-то такой файл есть в  $(BCB)\include\mfc

Тогда зачем Xerces'у mfc ?  Как он с ними связан ?

Это сообщение отредактировал(а) CyraxZ - 14.12.2006, 17:36

Vyacheslav, 
>А какая разница, если будете использовать библиотеку как dll?. Я бы на Вашем месте вообще 
>бы не мучался. Взял  готовую XercesLib.dll. А библиотеку импорта  получил бы с помощью implib.

По поводу implib. Допустим, у меня имеется dll'ка, полученная компилятором Borland. С помощью implib я могу получить библиотеку импорта для этой dll, позволяющей обращаться к функциям dll'ки из программы, скомпиленной компилятором MS (опция -a implib'а).
Правильно ли я понимаю, что в этом случае implib в формируемом .lib-файле изменит имена функций согласно стандарту MS, при этом имена функций станут различаться в .lib-файле (и, соответственно, в exe-файле после линковки последнего) и в dll'ке, но проблем с вызовами не возникнет по той причине, что при неявном подключении dll обращение к dll-функциям происходит всегда по номеру функции, а не по имени ?

Ещё такой вопрос. В одной из статей привели следующую схему именования функций в объектных файлах:

Соглашение о вызове           VC++                      C++ Builder
__stdcall                                _MyFunction@4       MyFunction
__cdecl                                MyFunction              _MyFunction
    
Если здесь всё верно, то каким образом в случае с C++ Builder в соглашении _stdcall различаются перегруженные методы ?  Там ведь после имени функции инфоромации о размере списка аргументов не добавляется...

По поводу сборки dll'ки из файла проекта C++ Builder. Всё-таки собрал. При этом:
- исключил из файла проекта файлы XTemplateComparator и XObjectComparator
- добавил файл XMLInitializer (использовался компилируемыми файлами)
- закомментил строку "#include "winres.h" в файле Version.rc

Кстати, файл winres.h компилятор находил (путь к mfc в файле проекта был прописан). Ошибка в чём-то другом...

Теперь, кинул к проге XercesLib.lib и XercesLib.dll, включил в проект XercesLib. (Все нужные хидеры из сырцов подключил.) Компилю, запускаю. Прога выкидывает исключение EAccessViolation "Access Violation at address ... in module 'XERCESLIB.DLL' " на вызове любой функции из dll...
Это я что-то сделал не так или dll'ка собрана криво ?


>Потребуется в свои cpp включит пару хидеров с помощью #include

Каких хидеров - тех, которые я использую ?

Вообще то я полагал, что опция -а, как для того, что бы библиотеку импорта использовать  с компилятором MS. Ибо тогда она сгенерирована в соответствии с соглашениями MS
А чем и как собрана dll - это может быть только вопросом любопытства ради. Так как dll - это dll и не важно чем она собрана  

Неправильно понимаете.  Имена функций важны при линковке. IMPLIB просто генерит файл импорта  в соответствии с соглашениями, которые Вы ей укажите. Если оптция -a  указана, то сгенерит в соответствии с соглашением MS и эту библиотеку импорта  сможет использовать только компилятор MS. Соответственно, без указания опции, сгенерится библиотека с соглашениями от Borland 
  

Как она использует компилятор Microsoft ?  Она же всего из dll-файла получает lib-файл...


Как по мне, компиляторы BCB и MSVC по разному реализуют name mangling как для соглашения C (_cdecl), так и для соглашения C++ (_stdcall)...


По-моему, мы об одном и том же...


Допустим, dll'ка сгенерирована в соответствии с соглашением BCB. implib'у указываем опцию -a. Он генерирует lib-файл по соглашению MS. Получаем: dll'ка - одни имена функций (BCB), lib - другие (MS). При этом, даже если вызов при неявном подключении dll будет происходить по номерам функций, то всё равно должны возникать конфликты при вызове функций с параметрами (вызов в соответствии с lib-файлом - по MS, фактическая организация бинарников в dll - по BCB)...

Хочу поправиться. _stdcall - это не C++ - ное соглашение (стандартное соглашение, где функция сама подтирает параметры), а _cdecl - не C-соглашение, а просто сишное соглашение (куда относится и C, и C++), где параметры подчищает вызывающая программа (ориентация на функции с переменным числом аргументов)

з.ы. Тут возникает вопрос: почему в _stdcall нельзя работать с функциями с переменным числом параметров, ведь в случае передачи (неявной) первым параметром числа аргументов (или их общего размера) функция без проблем может почистить все переданные ей параметры сама... (а вот если передавать аргументы такой функции иным образом, то да, никак...)

попробовал скомпилить Visual C++ 7.1-проект в 8-й версии (ну, естественно пришлось сконвертить файлы в 8-ю версию). Компилю - миллион ошибок в файле Version.rc (причём, только в нём)...