2006/9/15, Geir Magnusson Jr. <[EMAIL PROTECTED]>:
Alexey Varlamov wrote: > 2006/9/15, Gregory Shimansky <[EMAIL PROTECTED]>: >> 2006/9/15, Geir Magnusson Jr. <[EMAIL PROTECTED]>: >> > >> > >> > >> > Mikhail Fursov wrote: >> > > Testing WindowsXP build. >> > > Have to disable this assersion: >> > assert(is_name_lowercase(library_name)) in >> > > natives_support.cpp file to run Hello application. >> > >> > Yes, I was staring that that last night, trying to figure out why >> > lowercase stuff is so important. >> > >> > Any clue? >> > >> >> I am not sure why this assertion fails, but I think I know why it is >> important. On windows file paths may be different as strings but point to >> the same file. To detect duplications among native modules it is >> necessary >> to have unified form to compare names as strings. So it seems like all >> library names should be lowercase. I dunno why one of them doesn't >> satisfy >> this requirement. > I recall there is port_filepath_canonical() method specifically to > solve this, and at least classpath items were canonicalized during VM > startup. Maybe this step is just missing for libraries... But why it > started to fail only now? Because that was utterly insane to assume that all resources were in the same directory as the running executable, so I took that out at least for one thing and I'm going back now to solve. And I thought that method name was misleading, because it didn't return a canonical path for something, it returned the concatenation of the running executable's full path and whatever it was passed. Like the name of my cat.
Hmm, this is either exaggeration or bug: looking at implementation, it only appends current dir if an original path is relative. And supposed that port_filepath_canonical() is targeted for ordinary files, then it's behavior does not look insane, rather models general file access. But applying this method for dynamic library name indeed would produce queer result, which can drive you mad ;)
Which brings me to a good question I'll ask in a separate thread re APR string pools. geir >> >> I think this assertion failure needs investigation before we decide it >> should be removed. > Agree. > >> >> -- >> Gregory Shimansky, Intel Middleware Products Division >> >> > > --------------------------------------------------------------------- > 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]
