Board index » cppbuilder » Two packages can't link against the same lib file

Two packages can't link against the same lib file

I have a problem.

All our 'ANSI' C++ (library) code is compiled into .LIBs for sharing
among our applications.  Likewise, all our VCL components are compiled
into packages to plug into the IDE.  Obviously, some of those packages
are going to want to use features from some of our other libraries.
This is where the fun begins.

When I try to load the second package into the IDE, it complains about
all the functions from the shared library already present in the first
package, and refuses to install.

The only solution we have that works at the moment is to include *all*
our components in a single package.  This causes more
maintenance/source-sharing issues than we like to deal with.

Is there some obvious solution we are missing?  Is this problem soluble
as a feature request for BCB6?

All our applications are deployed as 'mononlithic' .EXEs without
run-time packages or dynamic RTL.

--
AlisdairM
Team Mongolian Wok

 

Re:Two packages can't link against the same lib file


"Alisdair Meredith" <alisdair.no.spam.please.mered...@benettonformula.com>
wrote in message news:3B4DA811.B93EEAF1@benettonformula.com...

Quote

> The only solution we have that works at the moment is to include *all*
> our components in a single package.  This causes more
> maintenance/source-sharing issues than we like to deal with.

> Is there some obvious solution we are missing?  Is this problem soluble
> as a feature request for BCB6?

I don't know if this'll help (I don't have much to do with packages etc) but
Developer Express (ExpressBars etc) install 2 packages.  the Express Common
library, and the Express Bars library.  The common library is shared between
the ExpressBars and there other components (e.g. Express Quantum Grid etc).
Maybe you could build your shared library code into another package and have
that installed also?

Or have I just missed the point.  If so, sorry.

Russell

Re:Two packages can't link against the same lib file


Quote
Russell Hind wrote:
> Or have I just missed the point.  If so, sorry.

Kind of....

If we want to build as a package we have to insert all those BCB #pragma
(smart_init) lines or we getting missing symbols when our apps link.
There are a couple more VCLisms that come along for the ride too.

I was hoping to keep our ANSI code completely separate from our VCL
code, hence the static libs rather than packages.  Although the lib is
still confined to BCB (compiled formats are not cross-compiler
compatible) the source code can still be used to compile libs under
different platforms.

--
AlisdairM
Team Mongolian Wok

Re:Two packages can't link against the same lib file


Alisdair Meredith <alisdair.no.spam.please.mered...@benettonformula.com>
wrote in message news:3B4DBF4D.5BDB5E60@benettonformula.com...

Quote
> Russell Hind wrote:

> > Or have I just missed the point.  If so, sorry.

> Kind of....

> If we want to build as a package we have to insert all those BCB #pragma
> (smart_init) lines or we getting missing symbols when our apps link.
> There are a couple more VCLisms that come along for the ride too.

> I was hoping to keep our ANSI code completely separate from our VCL
> code, hence the static libs rather than packages.  Although the lib is
> still confined to BCB (compiled formats are not cross-compiler
> compatible) the source code can still be used to compile libs under
> different platforms.

The problem here is that your components are statically linked to your ANSI
libs, which means that each package that uses them has a whole new copy of
the code, and a whole swag of duplicate entry points.  You'll need to find a
way to dynamically link to the library - either as a package or a DLL.

And I wouldn't worry too much about sprinkling foreign #pragma statements
through your source... according to the standard any unknown #pragma should
be ignored by the preprocessor.  It's the other VCL-dependant stuff that you
have to watch out for :)

--
Corey Murtagh
The Electric Monk
"Quidquid latine dictum sit, altum viditur."

Re:Two packages can't link against the same lib file


Quote
> I have a problem.

> All our 'ANSI' C++ (library) code is compiled into .LIBs for sharing
> among our applications.  Likewise, all our VCL components are compiled
> into packages to plug into the IDE.  Obviously, some of those packages
> are going to want to use features from some of our other libraries.
> This is where the fun begins.

> When I try to load the second package into the IDE, it complains about
> all the functions from the shared library already present in the first
> package, and refuses to install.

Are the routines from the ANSI C++ lib being exported from the package? I
suggest that you give this a try:

1- run tdump -ee -m on the BPL file, look for function names from the ANSI
libs.
2- run tlib xxx.lib, xxx.lib.lst on the package lib file, if there is one.
Look in the resulting .lst file for function names that were pulled in from
the ansi libs
3- run tlib xxx.bpi, xxx.bpi.lst and look at the output (this is essentially
a repeat of step one, since the BPI corresponds to the bpl.

How does the IDE package installer know anything about your C++ libs? How
can it know about those function names? That's what I want to know.

Compiling a package produces two things: a bpl/bpi combination for dynamic
linking, and a lib file (or just plain OBJs) for static linking. The BPL,
since it is a DLL, must be fully resolved. In other words, if your package
calls something from the C++ lib, the code for the C++ lib routine must be
present right inside the BPL. Now, the C++ routine should not be exported
from the BPL, but the code for it will be in the BPL somewhere. When the
dynamic package calls a C++ lib routine, it will jump to some code that is
inside the BPL itself.

The static lib file for the package is different. It need not have the code
for your C++ routines inside of it. Those can be resolved later. However, I
don't think it actually works this way. I have a similiar setup to yours. I
have a library I build called util.lib. Util.lib contains several OBJs
(dbutil.obj, vclutil.obj, stringutile.obj, etc). I use util.lib from a
package. When I tlib the package LIB file, I see dbutil, vclutil,
stringutil, etc. This means that the object code for your Ansi C++ library
is replicated in the LIB file for your package (but hopefully, only one copy
of each routine makes it into the final executable).

All of that aside, I tried to reproduce your problem, but could not. I'm not
sure why. I installed two different packages that both call the same
library, and neither of them complained. How are you linking with the C++
library: with a USELIB, a #pragma, or right in the BPR file?

PS: Is your ANSI library completely void of any VCL use? Or does the lib
contain forms and stuff? If it contain a form or a component, then I can see
how there might be problems.

Harold Howe [TeamB]
http://www.bcbdev.com

Re:Two packages can't link against the same lib file


Quote
"Harold Howe (TeamB)" wrote:
> All of that aside, I tried to reproduce your problem, but could not. I'm not
> sure why. I installed two different packages that both call the same
> library, and neither of them complained. How are you linking with the C++
> library: with a USELIB, a #pragma, or right in the BPR file?
> PS: Is your ANSI library completely void of any VCL use? Or does the lib
> contain forms and stuff? If it contain a form or a component, then I can see
> how there might be problems.

Nailed it, my silly!

My lib is completely devoid of any VCLisms, right down to not even
#including <vcl.h>

However, I discovered it was best to leave #pragma hdrstop around (I
tend to avoid precompiled header, despite the speed advantage, to retain
'locality of scope' for my declarations) even if there is nothing above
it!

My problem was I was initially converting an from an older BPL, and some
of the cpp files also contained #pragma package(smart_init).  Removing
these pragmas solves most of the problems.

Thanks for the help

--
AlisdairM
Team Mongolian Wok

Other Threads