[Interest] Hiding a shared lib? Linux of course.

[Till Oliver Knoll]

Am 05.07.2013 um 07:50 schrieb Mandeep Sandhu <mandeepsandhu.chd at gmail.com>:

> On Fri, Jul 5, 2013 at 3:33 AM, Guido Seifert <wargand at gmx.de> wrote:
>> ... if I may translate a German proverb:
>> Better an end with pain than pain without end.
> 
> I like this proverb...will be good as an email signature! :P

The actual german proverb is: "Lieber ein Ende mit Schrecken als Schrecken ohne Ende."

The closest translation I found at

  http://www.phrasen.com/uebersetze,Better-an-end-with-terror-than-terror-without-an-end,2983,e.html

sais:

"Better an end with terror than terror without an end."

Der Schrecken (noun) = terror, horror, fright etc

But I agree that "pain" is a better fit in this context ;)



To bring it a little back ontopic:

If the whole purpose was to deploy a given application on Linux (rather than, say, compile Qt 5  and install it under /usr/lib "for general use"), then

A) I could compile Qt myself (-> make sure that no existing system plugins from e.g. KDE are pulled in, which on their turn could pull in an older/different Qt version)

B) Deploy that Qt compile with my application (/opt/MyApp/[bin|lib|resources|...] - or wherever would be the appropriate location for "application bundles" on Linux these days)

Yes, "duplicated /shared/ libs! Not the proper place to install!" - I hear you :) But I am really thinking "Mac Bundles" here (where the appropriate libraries to pick up are "hard-coded" after (during?) link time into each binary/shared lib with the "nametool" on OS X).

That should work on Linux, too - right?

Cheers,
  Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130705/a0a38727/attachment.html>