linker errors - unresolved external ___
Robert Leblanc
GetEnvironmentVariable. Anything else I have tried to use in Sysutils seems
to work okay - just this one function doesn't.
Does anybody have any idea what is going on?
[Linker Error] Unresolved external '__fastcall
Sysutils::GetEnvironmentVariableA(const System::AnsiString)' referenced from
C:\DOCUMENTS AND SETTINGS\ROB\LOCAL SETTINGS\TEMP\UNIT1.OBJ
Jeff Overcash (TeamB)
GetEnvironmentVariable to GetEnvironmentVariableA in winbase.h and the
GetEnvironmentVariable defined in SysUtils.hpp is picking up that macro and
replacing the GetEnvironmentVariable with the macro equivalent of
GetEnvironmentVariableA. You can use this alternative
AnsiString __fastcall MyGetEnvironmentVariable(const AnsiString Name)
{
int Len = GetEnvironmentVariable(Name.c_str(), NULL, 0);
AnsiString Result;
if (Len > 0)
{
Result.SetLength(Len - 1);
GetEnvironmentVariable(Name.c_str(), Result.c_str(), Len);
}
return Result;
}
Alternatively (not necessarily a good fix) you can modify Sysutils.hpp and add
#undef GetEnvironmentVariable
right before the GetEnvironmentVariable function definition. This though would
stop you from getting directly at the WinAPI call.
--
Jeff Overcash (TeamB)
(Please do not email me directly unless asked. Thank You)
This sad little lizard told me that he was a brontosaurus on his mother's
side. I did not laugh; people who boast of ancestry often have little else
to sustain them. Humoring them costs nothing and adds to happiness in
a world in which happiness is in short supply. (RAH)
Jonathan Arnold
> GetEnvironmentVariable to GetEnvironmentVariableA in winbase.h and the
Ahh jeez, not this again! It is (was?) the same with SetPort. I know Microsoft is
a 800 lb. gorilla when it comes to namespace (ie., where does an 800 pound
gorilla sleep? Anywhere it wants to.), so Borland just needs to be much
more careful with their header files. Microsoft wins any of these wars. And
I just don't know how they could release a header file with this problem. I
mean if they test the call *just once* they'll see it cannot compile.
--
Jonathan Arnold C/C++/CBuilder Keen Advice:
http://www.keen.com/categories/categorylist_expand.asp?sid=5156620
Comprehensive C++Builder link site:
http://www.buddydog.org/C++Builder/c++builder.html
Kendall Ferguson
I have experienced the SetPort problem myself, and I have never resolved
it. How does one resolve the problem?
Kendall
Jonathan Arnold
> it. How does one resolve the problem?
Same way as Jeff reported for GetEnvironmentVariable. Here's my posting
from all too long ago on it:
The problem is that the Scktcomp VCL class (which you must be including in some kind
of possibly nearly invisible way) has a member function called "SetPort".
This would be okay in a perfect world, but Win32 is not a perfect world - it is
Microsoft's world. And in that world, they decided to use SetPort as a Win32 api
entry point.
Okay, you say, but what is this SetPortA? When you compile a Win32 app, you can
compile it for ANSI or UNICODE character set. Normally, if you don't do anything
(ie., define UNICODE), you get the ANSI entry points. Here's the include file
lines in winspool.h:
#ifdef UNICODE
#define SetPort SetPortW
#else
#define SetPort SetPortA
#endif
You need 2 different entry points depending on whether you are using UNICODE (with
its 16bit characters) or ANSI, with its 8 bit characters. Of course, this sort
of code in a header file breaks anyone who tries to use their own SetPort, as you
can see in scktcomp.hpp in your VCL include directory.
What does all this mean? Borland has to fix their header file to not use SetPort
(remember, this is Microsoft's imperfect world). But until then, I think the
best way out of this is for you to personally edit scktcomp.hpp and, after all the
include files, add:
#undef SetPort
It's ugly, it'll get overwritten on an upgrade, and it isn't very fun, but I think
it is the easiest and most straightforward way to do it. Oh, and be sure to report
this "bug" to Borland on the web site so it'll get fixed next upgrade.