Board index » cppbuilder » BCB4 Linker Failing To Export Names To Import Library

BCB4 Linker Failing To Export Names To Import Library

I have an existing project which consists of a DLL built with BC5.
The project contains several LIBs each of which contains the result of
several CPP files.  These LIBs along with several 'stand-alone' OBJs
is linked into the DLL and an import library is created from the whole
process.  All of the functions, variables and classes which are marked
for export show up in the import library as they should.

Now onto BCB4.  Because of the number of source files involved, I
would like to retain the same basic structure that I used with BC5.
That is, each LIB will be its own project as will the DLL.  All of
these projects will belong to a project group.  The difficulty is with
exported functions and classes.  They are not showing up in the import
library because they are not marked for export (marked 'public') in
the DLL.  If I run TDUMP on one of the LIBs, all of the exported
objects are properly marked.  If I run IMPDEF on the DLL, none of them
show up.  How can I force the linker (or the project manager) to carry
along the items which were exported in the individual LIBs?

Any help would be appreciated!

 

Re:BCB4 Linker Failing To Export Names To Import Library


This isn't considered a bug in BCB 4. The basic rule is that the linker
treats libs differently. Unless there is a need the lib file may not
even be searched for functions. In other words if all EXTDEFS can be
satisfied before the lib would be searched then it is not. To do what
you want you must abandon the use of .lib files and link all .objs into
your DLL.

Optionally you can somehow force the linker to search for a function in
a lib... unfortunately the only easily accessible way to do this is to
call the function.

Anduin Withers

Quote
David Beauchesne wrote:

> I have an existing project which consists of a DLL built with BC5.
> The project contains several LIBs each of which contains the result of
> several CPP files.  These LIBs along with several 'stand-alone' OBJs
> is linked into the DLL and an import library is created from the whole
> process.  All of the functions, variables and classes which are marked
> for export show up in the import library as they should.

> Now onto BCB4.  Because of the number of source files involved, I
> would like to retain the same basic structure that I used with BC5.
> That is, each LIB will be its own project as will the DLL.  All of
> these projects will belong to a project group.  The difficulty is with
> exported functions and classes.  They are not showing up in the import
> library because they are not marked for export (marked 'public') in
> the DLL.  If I run TDUMP on one of the LIBs, all of the exported
> objects are properly marked.  If I run IMPDEF on the DLL, none of them
> show up.  How can I force the linker (or the project manager) to carry
> along the items which were exported in the individual LIBs?

> Any help would be appreciated!

Re:BCB4 Linker Failing To Export Names To Import Library


Thanks Anduin.  If I can't use LIBs, is there a way to build an OBJ
from a bunch of other OBJs?  (You used to be able to do this with
other linkers such as PLINK.)

David

Quote
Anduin Withers wrote in message <36F2E728.19532...@inprise.com>...
>This isn't considered a bug in BCB 4. The basic rule is that the
linker
>treats libs differently. Unless there is a need the lib file may not
>even be searched for functions. In other words if all EXTDEFS can be
>satisfied before the lib would be searched then it is not. To do what
>you want you must abandon the use of .lib files and link all .objs
into
>your DLL.

>Optionally you can somehow force the linker to search for a function
in
>a lib... unfortunately the only easily accessible way to do this is
to
>call the function.

>Anduin Withers

>David Beauchesne wrote:

>> I have an existing project which consists of a DLL built with BC5.
>> The project contains several LIBs each of which contains the result
of
>> several CPP files.  These LIBs along with several 'stand-alone'
OBJs
>> is linked into the DLL and an import library is created from the
whole
>> process.  All of the functions, variables and classes which are
marked
>> for export show up in the import library as they should.

>> Now onto BCB4.  Because of the number of source files involved, I
>> would like to retain the same basic structure that I used with BC5.
>> That is, each LIB will be its own project as will the DLL.  All of
>> these projects will belong to a project group.  The difficulty is
with
>> exported functions and classes.  They are not showing up in the
import
>> library because they are not marked for export (marked 'public') in
>> the DLL.  If I run TDUMP on one of the LIBs, all of the exported
>> objects are properly marked.  If I run IMPDEF on the DLL, none of
them
>> show up.  How can I force the linker (or the project manager) to
carry
>> along the items which were exported in the individual LIBs?

>> Any help would be appreciated!

Re:BCB4 Linker Failing To Export Names To Import Library


Quote
>>Thanks Anduin.  If I can't use LIBs, is there a way to build an OBJ
>>from a bunch of other OBJs?  (You used to be able to do this with
>>other linkers such as PLINK.)

While I admit it would be a nice feature it is one we do not currently
have (nor have we ever).

The best solution would be to change our linker so that .lib files found
in the .objs list would be treated as a collection of .objs. This isn't
a feature of the product yet (and I do not believe it is planned anytime
soon).

Apart from making each of your current .lib files into a DLL it is the
only solution.

Anduin Withers

Re:BCB4 Linker Failing To Export Names To Import Library


Anduin Withers

Quote
> While I admit it would be a nice feature it is one we do not currently
> have (nor have we ever).

That's strange it's always worked that way through BC5.02.

Re:BCB4 Linker Failing To Export Names To Import Library


No we never created a single .obj from multiple. The old behavior of
exports working from libs was present in BC 5.

Anduin Withers
borland.com

Quote
Howard Egan wrote:

> Anduin Withers

> > While I admit it would be a nice feature it is one we do not currently
> > have (nor have we ever).

> That's strange it's always worked that way through BC5.02.

Other Threads