Am 13.11.2013 um 19:10 schrieb Till Oliver Knoll <till.oliver.kn...@gmail.com>:
> Am 13.11.2013 um 15:53 schrieb Emmanuel Bourgerie <m...@bourgerie.fr>:
>
>> Turns out those libraries are available in my instantclient folder,
>> which is aliased correctly (DYLD_LIBRARY_PATH).
>
> Ah, that reminds me: according to e.g.
> http://forums.macrumors.com/showthread.php?t=956258
>
> on OS X you do /not/ have a dynamic lookup of shared libs in the sense that a
> predefined order of paths is checked for the existence of a certain shared
> library.
Giving it another thought and some more google, this statement is probably not
correct. Yes, you can set DYLD_LIBRARY_PATH on OS X (there is even a "fallback"
variant) and hence it is evaluated. Probably the dynamic linker might even
check on /usr/lib, if everything else fails.
However especially on OS X setting that environment variable is heavily
discouraged and basically only useful for development, if you "temporarily"
want to "inject" another shared library.
> The path of a given library is always [1] "hard-coded" into the
> executable/dependent library - that's where the "install_name_tool" comes
> into play
However I still think that the problem is related to "hard-coded library
paths/identifiers". I suspect that the Qt Oracle SQL plugin was compiled with
some path like /usr/local/whatever/libOracle.dynlib, and if that library is not
found there, the linker simply freaks out.
Based on my assumption that only executables (libraries) *without* hard-coded
paths would go through the usual search path ($DYLB_LIBRARY_PATH, /usr/lib,
...).
Again, install_name_tool would be your friend which can both show and set those
library paths.
Hope that helps,
Oliver
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
