[EMAIL PROTECTED] wrote:
Log: #i69351#we now symbols containing wildcards will also be supported in the process of generating exported symbols lists on Mac OS X hence we do not need a Mac specific map file anymore
[...]
--- gcc3_linux_intel.map 13 Jan 2007 21:49:58 -0000 1.11.32.2 +++ gcc3_linux_intel.map 24 Jan 2007 15:38:10 -0000 1.11.32.3
[...]
- _ZN9jvmaccess14VirtualMachineC1EP10_Jv_JavaVMibP10_Jv_JNIEnv; # jvmaccess::VirtualMachine::VirtualMachine(JavaVM *, int, bool, JNIEnv *) - _ZN9jvmaccess14VirtualMachineC2EP10_Jv_JavaVMibP10_Jv_JNIEnv; # jvmaccess::VirtualMachine::VirtualMachine(JavaVM *, int, bool, JNIEnv *) + _ZN9jvmaccess14VirtualMachine*_Jv_JNIEnv; # jvmaccess::VirtualMachine::VirtualMachine(JavaVM *, int, bool, JNIEnv *) + _ZN9jvmaccess14VirtualMachine*_Jv_JNIEnv; # jvmaccess::VirtualMachine::VirtualMachine(JavaVM *, int, bool, JNIEnv *) } UDK_3.1;
Hm, rather fragile approach, I would say. Now, everything (i.e., every future symbol) that happens to match those wildcarded strings (e.g., every jvmaccess::VirtualMachine member function that takes a JNIEnv as last parameter) is exported labeled UDK_3.1. Not a very healthy approach to maintaining a stable API. :(
Also, the two "+" lines are identical, you can drop one. ;) -Stephan --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
