Board index » cppbuilder » RAD2007 lib problem

2008-02-01 05:00:35 AM
cppbuilder112
My project links in several static libs. In one of the libs, I use a pragma
link: #pragma link "TeeJPEG", which is from Steema's TChart, which is
installed and it's include and lib paths are in RAD global paths
RAD builds the library without problem. However, when I build the project,
the linker says it can't find TeeJPEG.obj.
Is the project linker looking for the TeeJPG.obj file in the static lib, and
it is missing? Or is the project linker looking for it in the system path?
Both?
If I build a simple VCL project with a simple static lib (with the same
pragma link), it builds and links just fine. So there is something strange
going on in my project, or lib.
Any ideas?
Kevin
 

Just a guess but try changing
#pragma link "TeeJPEG"
To
#pragma link "TeeJPEG.obj"
Or do it right by deleting the pragma and add the object file to the
project. That way you not only have the project actually reflecting the
files list it needs, you also do not risk alteration in the files list from
edits on the source files.
. Ed

Kevin wrote:
#pragma link "[path]modulename[.ext]"
By default, the linker searches for modulename in the local directory and any path
specified by the -L option. You can use the path argument to specify a directory.
By default, the linker assumes a .obj extension.
</HELP>
So if TeeJPEG is actually a library, you would need to say so:
#pragma link "TeeJPEG.lib"
 

{smallsort}

Thanks, but I tried all those. I even tried adding TeeJPEG to the
Additional Options in the Linker, but this gives the same error.
The weird part is that the obj file is truly in one of the Steema libraries
(because it links in for a simple application), and I am using the same path
info in all cases.
K
"Ed Mulroy [TeamB]" < XXXX@XXXXX.COM >wrote in message

Thanks for your response.
TeeJPEG is an object file in one of Steema's libraries, which is in the
system path. The obj exists, because I can access it and use it in test
apps.
A static lib in my project group has the pragma link statement, not the main
project. There are no errors generated when the lib is built, so I assume
that TeeJPEG has been successfully linked during the lib build. Since this
is a static lib, is my assumption not correct that all obj files would be
included (including TeeJPEG) in the lib?
My confusion is that I only get the linker error when I build the main
project, and there are no references to TeeJPEG in any of the main project
files.
Kevin
"Bob Gonder" < XXXX@XXXXX.COM >wrote in message

"Kevin" < XXXX@XXXXX.COM >wrote in message
externals are resolved when linking the final executable. You would not want
any external object files to be included in your own static lib anyway -- it
would lead to a lot of problems if many different static libs all contained
the same code from some common lib (especially if they all included code
from different versions of said common lib), and also it would mean you'd
have to rebuild your static lib every time the lib you were using was
updated if you wanted to take advantage of new changes.
Static libs are just a collection of object files, all external references
are left unresolved. All references are collected and resolved when the
executable is built, so you must link your executable to any static libs
that other static libs are dependant on.
causes the linker to link to that lib when that header is included in your
project. No linking is done when building static libs, and the #pragma link
has no effect on the build of your static lib whatsoever.
All -your- object files are included in your library. External object files
are not -- the linker does not extract the object files from external libs
and then reinclude them in your own. The reason your library is a "static"
library is because -your- code is compiled into your library, and so all the
functions in your library are included in the final executable that links to
your static lib. This is opposed to a dynamic library, where your code is in
a DLL or some other file, rather than in your final executable, and that
other file must be present at run time. But, whether your lib is "static" or
"dynamic" has no bearing on whether or not other libs you use are also
static or dynamic, and again, all linking is done when the final executable
is built.
As for the file not being found, I don't know. But this is why you are only
seeing linker errors when building the executable.

"Jason Cipriani" < XXXX@XXXXX.COM >wrote in message
explicitly add some other .obj file to the project manager, is it then
compiled into your library? Or is adding libraries and objects to the
project manager exactly the same as specifying them to the linker?
Jason
 

Kevin,
I've got RAD2007, and I do quite a bit with TeeChart, and I looked, and
I don't have a TeeJPEG.obj file in my system. I'm using TeeChart Pro
version 7.12, which definitely supports RAD2007. When porting
applications from BDS2006 to RAD2007, I had a few instances where I had
to delete #pragma link statements that were referencing TeeChart files
that have been integrated into other libs. Have you tried simply
commenting out that #pragma link and seeing if your application builds?
Joe
Kevin wrote:

Thanks, but;
"Joe Pasquariello" < XXXX@XXXXX.COM >wrote in message
JPEGs in the Chart Editor. The same process is used for PNGs, PDFs, etc,
and is described in Steema's (rather hard to find) docs.
Note that the problem only appears in this particular project. If I build a
new VCL project with a TChart, the #pragma links work as expected without
error.
libraries, not as a separate obj file.
other TChart #pragma links --- maybe this is the source of the problem.
Kevin
 

"Jason Cipriani" < XXXX@XXXXX.COM >wrote in message
wall!
Kevin
 

Jason Cipriani wrote:
Static libraries are not compiled, they are assembled or aggregated
by the librarian from compiled parts.
So adding a .obj to your project will simply pass it to the librarian.
The librarian will then copy the .obj file into the .lib the next
time you make or build the .lib.
Another way to look at it is you can list 50 .obj files in the
linker command, or you can place those 50 .objs in a .lib and
only list the .lib in the linker command.
 

I said "compiled" but I really meant "archived", and I said "linker" but I
really meant ... well I guess you call it a librarian but I'm used to
calling it "ar"... because I'm a pirate at heart.
I definitely screwed up that question, but the root of it was this:
If I add -any- file to the "Requires" section of the project manager, is
that -exactly- the same as specifying it to the archiver for static libs (or
to the linker for executables / dynamic libs)? Or does specifying it in the
project manager add extra dependency info to the project that wouldn't be
there if you simply stuck it on the command line? (E.g. if I put some file
in the project manager "Requires" section, will my entire project be rebuilt
by the make command if that file's timestamp changes?)
I was wondering about the difference between adding files to the project
manager and specifying them on the link / librarian command line, rather
than the difference between specifying .obj files and .lib files.
But it was probably a dumb question now that I think about it.
Thanks for your reply, though. In any case, unrelated to this question, at
the end of the day I'm generally a very confused person.
Jason
"Bob Gonder" < XXXX@XXXXX.COM >wrote in message

Jason Cipriani wrote:
And would only relink if a project item changed.
 

Kevin Manuele wrote:
I don't know if you have resolved this or not, but I had a very similar
issue with CRS 2007 and a project that was migrated from BDS 2006.
I got a link error in my application for an object file that was not
installed in CRS 2007 when using a TSQLConnection component. A small
test project using the same component worked as expected.
The entire thread is here:
groups.google.ca/group/borland.public.cppbuilder.language.cpp/browse_frm/thread/ec1d504f9ca22e9e/35cab8749e5b53a0
Dennis Cote