[Interest] Use Oracle 11g with Qt5.1 on MacOS

[Till Oliver Knoll]

Am 13.11.2013 um 19:10 schrieb Till Oliver Knoll <till.oliver.knoll at gmail.com>:

> Am 13.11.2013 um 15:53 schrieb Emmanuel Bourgerie <manu at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20131114/5d1868cc/attachment.html>