>>>> PS You could also try to use FileMon\ProcMon to trace application activity
>>>
>>> I see that icuin30.dll is tried to be loaded from various places
>>> (although excluding the embedded root path), but this fails.
>>>
>>> icuin30.dll is available in the embedded root directory. When I put the
>>> dll into the application sub-folder, then the trace output works.
>>>
>>> Can you please check from where icuin30.dll is loaded when running my
>>> test application?
>
> I have all three ICU libraries in system32 folder. And your application
> load icuin30.dll
> from system32 (even when i set PATH to empty string) and other two ICU dll's
> from
> embedded folder.
>
>> Btw, I now found: http://tracker.firebirdsql.org/browse/CORE-3183
>
> It finally points me to the source of the problem - fbtrace.dll have no
> idea that it works
> with embedded and load icuin30.dll not using LOAD_WITH_ALTERED_SEARCH_PATH
> flag. Will think how to fix it correctly.
Really, issue have a bit different source :) LOAD_WITH_ALTERED_SEARCH_PATH
is needed to search
for *dependent* dll's near the currently loading one. But it can't help to load
target library. My current idea is
that correct solution to the *icu issue* is to specify full path to the loading
library and, of course, this path
should be based on folder of embedded library (not on application's folder).
So, first part of the proposed fix is to make engine load icuin30.dll using
full path (not just a name as
currently) and it should be the path of the engine itself (fbembed.dll for
embedded case).
The second part of the patch is a bit tricky - in our case icuin30.dll is
loaded by fbtrace.dll which is reside in
different folder than fbembed.dll. I see two possible ways to solve it:
a) fbtrace.dll located at "plugins" sub-folder, so we can use path to the
current module (fbtrace.dll)
and cut last component from it ("plugins") to obtain correct path to the
embedded library, or
b) we can make engine preload icuin30.dll before it loads fbtrace.dll and in
this case engine knows
correct path to its own module (fbembed.dll). When fbtrace.dll later will
attempt to load icuin30.dll
it will use already loaded module.
So far i prefer (b) as it looks as more correct to me. Of course, i already
tried this patch and it works for me.
Here i want to make sure i didn't missed something important before commit.
Constructive objections are welcome :)
Regards,
Vlad
PS Note, fb3 have exactly the same issue but it is much more wide there. In
general it could be stated as:
- in fb3 engine always works in embedded mode (i.e. engine always in dll)
- when engine (or any other part of Firebird process, such as plugin) loads any
library it is
better to specify full path to avoid confusion, or even security risks
- this full path should be based on location of plugin manager (or dispatcher)
- fbclient.dll
The question is: should we always check for relative path of loading module
and try first to prefix it
with the fbclient's folder ?
PPS I have no idea if this issue is present on non-Windows platforms
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience. Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
