Crosscompiling 1.4 on linux for windows.
by Jerry Segler · in Torque Game Engine · 02/23/2006 (6:55 pm) · 8 replies
Is anyone crosscompiling 1.4 on linux?
I'm getting duplicate symbols between unicode.cc and winStrings.cc when I try.
Here are the problem functions:
const U32 dStrlen(const UTF16 *unistring)
vs
dsize_t dStrlen(const UTF16 *str)
UTF8 * convertUTF16toUTF8(const UTF16 *string, UTF8 *buffer, U32 bufsize)
vs
const U32 convertUTF16toUTF8( const UTF16 *unistring, UTF8 *outbuffer, U32 len)
UTF16 * convertUTF8toUTF16(const UTF8 *string, UTF16 *buffer, U32 bufsize)
vs
const U32 convertUTF8toUTF16(const UTF8 *unistring, UTF16 *outbuffer, U32 len)
-Jerry
I'm getting duplicate symbols between unicode.cc and winStrings.cc when I try.
Here are the problem functions:
const U32 dStrlen(const UTF16 *unistring)
vs
dsize_t dStrlen(const UTF16 *str)
UTF8 * convertUTF16toUTF8(const UTF16 *string, UTF8 *buffer, U32 bufsize)
vs
const U32 convertUTF16toUTF8( const UTF16 *unistring, UTF8 *outbuffer, U32 len)
UTF16 * convertUTF8toUTF16(const UTF8 *string, UTF16 *buffer, U32 bufsize)
vs
const U32 convertUTF8toUTF16(const UTF8 *unistring, UTF16 *outbuffer, U32 len)
-Jerry
#2
This is issue has more to do with naming collisions in the code.
I don't understand how/why MSVC is linking the code as-is.
Last I knew it wasn't valid to have 2 functions in the global namespace only differing by return type.
TGE has 3 sets of them.
02/24/2006 (10:42 am)
I believe I do, although I could be wrong.This is issue has more to do with naming collisions in the code.
I don't understand how/why MSVC is linking the code as-is.
Last I knew it wasn't valid to have 2 functions in the global namespace only differing by return type.
TGE has 3 sets of them.
#3
From a compiler theory level, having a different return type does uniquely identify an overloaded function, so in this particular circumstance I'd suggest that GCC is being over-protective. Yes, it might violate some rule that I'm not aware of, but then again like I said, from a theory perspective it doesn't have to--and doesn't based on MS compilers.
02/24/2006 (11:18 am)
GCC tends to be more restrictive than MS compilers in some cases, and it looks like this might be one of them.From a compiler theory level, having a different return type does uniquely identify an overloaded function, so in this particular circumstance I'd suggest that GCC is being over-protective. Yes, it might violate some rule that I'm not aware of, but then again like I said, from a theory perspective it doesn't have to--and doesn't based on MS compilers.
#4
It's also a non-trivial problem in compiler theory.
How would you resolve this:
void foo(int i);
void foo(double i);
int bar();
double bar();
int main()
{
foo(bar());
}
At link time MSVC is apparently just linking everyone to the first instance of the function it finds and ignoring the second.
I'll play with it under MSVC 7.0 this weekend to figure out which one to throw away (probably the winString.cc ones).
-Jerry
02/24/2006 (3:27 pm)
Actually I'm 99% certain it is forbidden in the standard..It's also a non-trivial problem in compiler theory.
How would you resolve this:
void foo(int i);
void foo(double i);
int bar();
double bar();
int main()
{
foo(bar());
}
At link time MSVC is apparently just linking everyone to the first instance of the function it finds and ignoring the second.
I'll play with it under MSVC 7.0 this weekend to figure out which one to throw away (probably the winString.cc ones).
-Jerry
#6
I'd really like a unattended compile every night on my linux server where I intend to dabble with some kind of source-control system next week.
02/24/2006 (5:39 pm)
Hmm, any chance of a cross-compiling-on-linux-for-noobs write up :)I'd really like a unattended compile every night on my linux server where I intend to dabble with some kind of source-control system next week.
#7
Both method overloading and operator overloading have been around for quite a while, and that was my point (and what it sounded like you were discussing).
02/25/2006 (7:37 am)
@Jerry: you can come up with a case that would break any compiler obviously...and a good compiler/linker would catch it.Both method overloading and operator overloading have been around for quite a while, and that was my point (and what it sounded like you were discussing).
#8
Although there is a bit of code in winWindow.cc that I had to fix up around line 1306 to make things work properly.
Here is what I changed it to:
gWindowCreated = true;
#ifdef UNICODE
windowName = (UTF16 *) malloc(256*sizeof(UTF16));
convertUTF8toUTF16((UTF8 *)name, windowName, sizeof(windowName));
#else
windowName = (char *) malloc(256*sizeof(char));
dStrcpy(windowName, name);
#endif
The original code was doing a copy into the global string table and causing a write access violation.
Technically my change is creating a small memory leak.
But I didn't feel like reworking the code to pass around the windowName.
As for cross compiling, there is already a resource and some forum posts on that. That is what I used to setup my cross compiling environment. Although I did recompile ogg/vorbis/theora rather than use the MSVC built lib's.
As for the comment on method overloading and operator overloading..
Since your pusing VC so much I'll quote the MSDN on it.
Although functions can be distinguished on the basis of return type, they cannot be overloaded on this basis.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_function_overloading.asp
-Jerry
02/27/2006 (1:07 pm)
Those 3 functions in winStrings.cc are cruft.Although there is a bit of code in winWindow.cc that I had to fix up around line 1306 to make things work properly.
Here is what I changed it to:
gWindowCreated = true;
#ifdef UNICODE
windowName = (UTF16 *) malloc(256*sizeof(UTF16));
convertUTF8toUTF16((UTF8 *)name, windowName, sizeof(windowName));
#else
windowName = (char *) malloc(256*sizeof(char));
dStrcpy(windowName, name);
#endif
The original code was doing a copy into the global string table and causing a write access violation.
Technically my change is creating a small memory leak.
But I didn't feel like reworking the code to pass around the windowName.
As for cross compiling, there is already a resource and some forum posts on that. That is what I used to setup my cross compiling environment. Although I did recompile ogg/vorbis/theora rather than use the MSVC built lib's.
As for the comment on method overloading and operator overloading..
Since your pusing VC so much I'll quote the MSDN on it.
Although functions can be distinguished on the basis of return type, they cannot be overloaded on this basis.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_function_overloading.asp
-Jerry
Torque 3D Owner Stephen Zepp