Для сборки библиотеки XercesLib.dll вместе с сырцами имеются файл проекта .bpr и его .cpp. Файл .cpp следующий:

В отдельном каталоге (xercesc) лежат все исходники. Включаемые в библиотеку cpp-ники включены в проект. И всё. В .cpp файла проекта не указано, что подлежит экспорту (текст выше). По умолчанию ни один из включенных в проект cpp-ников не включается в dll-ку.
Причём нигде в сырцах ничего подобного (об экспорте) тоже не указано (но так и должно быть). Т.е. информация об экспорте должна быть именно в файле проекта...
1. Вопрос: где в файле проекта указывается, что в dll'ку нужно включить объектный код всех подключенных к проекту cpp-ников ?
(нигде явного указания с помощью __declspec (dllexport) или как-то иначе нет)

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

Для проверки создал dll'ку в Builder'е, как в случае с Xerces'ом, такой же cpp-ник (без указания, что нужно экспортировать) (текст выше). Включил в проект дополнительный cpp-ник с функцией, которую нужно экспортировать в dll. Собрал - объектного кода этой функции в dll нет, что очевидно. 

Вопрос не понятен. В dll включается весь объектный код всех подключенных к проекту cpp-ников. Другой вопрос, что только часть из представленных там классов достпупны для пользования из вне 
.

Счас  Практически большинство классов указаны, как экспортируемые
BorlandCDef.hpp


В параметрах проекта имееем



А Xercesdefs.hpp


Ну и возьмем любой класс


Объявление которого, если раскрыть макрос банально превратиться в

Насчёт макросов всё понятно.
Непонятно следующее:
1. Создал простую dll'ку, к проекту подключил модуль с несколькими экспортируемыми функциями. Собрал проект. Слежу за размером dll'ки (фактическим, не тем, сколько он занимает на диске): размер не изменяется при изменении числа разных функций в подключаемом cpp-файле, не изменяется также при изменении имплемента функций (размер постоянный - 11776 байт). Если убрать все функции из подключаемого cpp-файла (оставить его пустым), то размер получаем 11264 байта.
С размерами lib-файла и объектника подключаемого cpp-ника - всё нормально (меняются, как и положено)
В чём дело ?
2. Почему прога, использующая dll'ку, нормально компилится независимо от того, как объявлена импортируемая из dll функция: с __declspec(dllexport), с __declspec(dllimport) или вообще без этого keyword'а ?  Должна компилиться только в случае с import...

3. И такой вопрос по Builder'у:
На что влияет настройка проекта Advanced compiler -> calling convention ?
Если на способ вызова функций из dll ?  Если так, то при неявном подключении эта информация может извлекаться из соответствующей lib-библиотеки...
Или на способ компиляции функций программы ?

Я не понял сути. То есть вы подключаете dll и используете  несколько функций из нее? И при изменении  количества используемых функций размер не растет? А почему он будет расти? Реализация импортируемых из dll функций в ваш проет не переносится. Они как были так и остались в dll. А от того сколько Вы функций вызвали размер Вашего проекта будет расти весьма незаметно. Вы же понимаете, что для нормальной работы Вашей пргограммы Вам обязательно нужно поставлять и ту dll, функции из которой Вы используете.    


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