> 12.02.2014 10:48, Vlad Khorsun wrote:
>> It is not about ICU only. It is about loading libraries using just file
>> name, without a path.
>
> Unix guys aren't afraid of hell and put all libraries or at least symlinks
> to
> /usr/lib/. On the other hand, they also have separate LD_LIBRARY_
12.02.2014 10:48, Vlad Khorsun wrote:
> It is not about ICU only. It is about loading libraries using just file
> name, without a path.
Unix guys aren't afraid of hell and put all libraries or at least symlinks
to
/usr/lib/. On the other hand, they also have separate LD_LIBRARY_PATH
envir
> 12.02.2014 10:11, Vlad Khorsun wrote:
>> PPS I have no idea if this issue is present on non-Windows platforms
>
> This issue is not present on non-Windows platform because ICU is considered
> a system
> library there and thus always is placed in well-known system library catalog.
It is
12.02.2014 10:11, Vlad Khorsun wrote:
> PPS I have no idea if this issue is present on non-Windows platforms
This issue is not present on non-Windows platform because ICU is considered
a system
library there and thus always is placed in well-known system library catalog.
May be on Windows
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
>
