Syncmgr.h was, as I understand the process, accessed while the program was compiling, not linking, and my problem was with a linker error. I don't understand the need to refer to "imperfect knowledge". A linker problem must develop from fairly well known causes, to which professional programmers must be sensitive, and thus able to recognize even without the code in front of them. If the linker can't fill in a reference, it produces a linker error. If a compiler can't find a header file containing a function or a specific function not contained within a dll, it produces completely different errors.
I originally had Builder set to look in the directories containing the .lib and .dll files you have referenced, the linker error persisted as my list of directories associated with linking and compiling within Builder grew even larger in an attempt to insure that any possible shred of code that I had was available. The IMPDEF program's .def file based on sync20.dll caused a problem with specific, unknown function names. (Why were they unknown if the dll was self-contained?) Had the .def file generated by IMPDEF not produced multiple unknown function names, I would probably be considering the source as possibly containing MFC references that were the sole origin of the problem, although MFC references derived from a header file reference should have been caught, I would have thought, by the compiler. (Granted, I presume that MFC classes are based in header files, like OWL classes.) The original source may well contain MFC function calls. The party who recommended the source indicated that he believed, but was not absolutely certain, that it did not. Shouldn't the compiler have complained about unknown function calls explicitly referenced and used within the source, before it reached the linking stage if the cause was not with a dll file? I saw nothing that suggested that any header files not included in either Borland's include directory or the CDK include directories were required. The restriction to a linker error suggests that the problem was in external code references that the linker could not fill in. I'm probably not the only one whose grown a little tired of this, so I'll stop here, even if I must remain uncertain of the specific cause. Thanks for the response. ----- Original Message ----- From: "Jim Cooper" <[EMAIL PROTECTED]> Newsgroups: palm-dev-forum To: "Palm Developer Forum" <[email protected]> Sent: Thursday, December 08, 2005 10:50 AM Subject: Re: Linker Error > > > I note that recompiling the dll for C and not C++ was recommended > > at the Borland user group site. > > Yes, but they had imperfect knowledge of the problem. Sync20.dll does not use > C++ (at least in presenting anything externally) or it would not be callable > from anything but C++. It uses straight C calling conventions, which is how I am > able to call things in it from Delphi. There are no classes in anything to do > with exported functions from that DLL, only structs. These are all defined in a > header file (syncmgr.h IIRC). > > However, there is other code in many C++ conduit examples which does rely on > MFC, but it is all the conduit code, not the calls to sync20.dll routines. > Whether or not you had one of those examples, I have no idea. Just because you > asked for one without doesn't mean you got it :-) > > > The fine points of linking, in terms of linking with code within dll' > > You should not be linking with a DLL at compile time. That's why they are > dynamic link libraries - the calls to them only happen at runtime. > > It's been a long time since I did any C programming in Windows, but I didn't > think running IMPDEF was required in this case. All the definitions are in > syncmgr.h (including the fact that the functions are obtained from a DLL), and > there is a sync20.lib file already in the CDK. I thought that was all you needed. > > > I don't want to drag this out, as I seem to have found a solution using COM > > and VB 5.0, which didn't prove to be the nightmare I had begun to anticipate > > given the way in which COM seems to be perceived by some. > > It's COM in general, not those COM components in particular that I was > commenting about. It just sucks as a technology. > > As long as you have something working, that's the main thing. > > Cheers, > Jim Cooper > > __________________________________________ > > Jim Cooper [EMAIL PROTECTED] > Skype : jim.cooper > Tabdee Ltd http://www.tabdee.ltd.uk > > TurboSync - Connecting Delphi to your Palm > __________________________________________ > > -- > For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/ > -- For information on using the PalmSource Developer Forums, or to unsubscribe, please see http://www.palmos.com/dev/support/forums/
