What Makes A Programming Language Good

[Steven Schveighoffer]

On Thu, 20 Jan 2011 09:58:17 -0500, Adam Ruppe <destructionator at 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