On Thu, 20 Jan 2011 09:58:17 -0500, Adam Ruppe <destructiona...@gmail.com>
wrote:
When you compile, you have to provide a path anyhow, less hostile to
user and you don't have to change the code.
One of the things implicit in the thread now is removing the
need to provide a path - the compiler can (usually) figure it
out on its own. Try dmd -v and search for import lines.
But requiring it on the user side just makes sense if versioning
is important. Your program won't compile with a different version -
you aren't importing a generic thing, you're depending on something
specific. It should be explicit.
(Btw, this is the big failure of Linux dynamic libraries. They
started with a decent idea of having version numbers in the filename.
But then they ruined it by having generic symlinks that people can
use. They start using libwhatever.so when they really wanted
libwhatever.so.4.2. It's a symlink on their system, so Works for Me,
but if they give that binary to someone with a different symlink, it
won't work. Gah.)
Hm... I thought the symlink was meant to point to binary-compatible
bug-fix releases. So for example, if you need libwhatever.so.4.2, you
have a symlink called libwhatever.so.4 which points to the latest point
revision that is binary compatible with all 4.x versions. I think you
still simply link with -lwhatever, but the binary requires the .so.4
version. I have seen a lot of libs where the symlink version seems to
have nothing to do with the linked-to version (e.g. /lib/libc.so.6 ->
libc-2.12.1.so), that doesn't really help matters.
Given that almost all Linux releases are compiled from source, it's quite
possible that one OS' libwhatever.so.4 is not compiled exactly the same as
your libwhatever.so.4 (and might be binary incompatible). This is
definitely an issue among linuxen.
-Steve
