Alexey Varlamov wrote:
Geir,
The DRLVM build is broken now on gcc3.3.3 (SUSE9):
build.native.cpp:
[cc] 135 total files to be compiled.
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp: In
[cc] function `apr_dso_handle_t* natives_load_library(const
char*, bool*,
[cc] NativeLoadStatus*)':
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:287: error: jump
[cc] to label `NATIVES_LOAD_LIBRARY_EXIT'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:268: error:
[cc] from here
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:281: error:
[cc] crosses initialization of `jint res'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:273: error:
[cc] crosses initialization of `Global_Env*ge'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:287: error: jump
[cc] to label `NATIVES_LOAD_LIBRARY_EXIT'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:255: error:
[cc] from here
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:281: error:
[cc] crosses initialization of `jint res'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:273: error:
[cc] crosses initialization of `Global_Env*ge'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:258: error:
[cc] crosses initialization of `NativeLibInfo*pinfo'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:287: error: jump
[cc] to label `NATIVES_LOAD_LIBRARY_EXIT'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:234: error:
[cc] from here
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:281: error:
[cc] crosses initialization of `jint res'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:273: error:
[cc] crosses initialization of `Global_Env*ge'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:258: error:
[cc] crosses initialization of `NativeLibInfo*pinfo'
[cc] drlvm/vm/vmcore/src/util/natives_support.cpp:241: error:
[cc] crosses initialization of `apr_status_t apr_status'
BUILD FAILED
How bizarre. Propose a fix then. All I was trying to do was localize
the free() under windows.
Besides, you introduced inconsistency in names, ones registered inside
of ClassLoader::LoadNativeLibrary and those actually loaded in
natives_load_library().
So, if one will try loading the same lib with different names on
Windows via j.l.System.loadLibrary(), there will be unexpected
UnsatisfiedLinkError.
I guess that awkward usage of port_filepath_canonical() was intended
to solve exactly this problem.
I can't see how. Seems like port_filepath_canonical() was being used in
LoadNativeLibrary() was to create a full path, and would PREPEND THE
CURRENT DIRECTORY to it. So in our case, where we are wanting to let
apr_dso_load() get a dll/so, it *can't* presume current directory.
That said, I do agree that we should move the lower-casing done in
natives_load_library() and just demand that callers get their path right
as part of the API for natives_load_library()
If you want to add that to your fix above, that would be great.
Sorry for the trouble. I'll do it if you want.
geir
So we still need better solution.
--
Alexey
2006/9/15, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Looking at things, yes, it's the ICU dll, which has uppercase letters in
the filename.
My plan is to just convert all paths to lowercase.
Any problems people can see?
geir
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
