Clean up the makefile

[kousu]

• use := with $(shell), because = is lazily evaluated
• build the lib by default, not just the programs (the Windows version already did this, it must have been an oversight)
• follow the Windows naming conventions (this is important to me because I'm trying to write a cross-platform build which depends partially on libsvm and partially on other cross-platform libraries, and I want to be able to use a single declaration in my Makefile)
• use make's features to get the platform detection out of the shell script
• make the library file a real target and properly mark lib as a .PHONY one. Now make knows when it has already built libsvm.so.2.
• don't explicitly embed -soname (Linux) or -install_name (OS X); rather, let the platform decide.
  Because of this, the target is built with its final name and then linked to its versioned name, instead of the other way around.
• build the static library

OS X auto-embeds -install_name:

sasgradmac:libsvm nguenthe$ otool -L libsvm.dylib
libsvm.dylib:
    libsvm.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 56.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)

Linux doesn't embed -soname (but maybe it should??):

[kousu@galleon libsvm]$ readelf -d libsvm.so

Dynamic section at offset 0x103d8 contains 27 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000c (INIT)               0x2f18
 0x000000000000000d (FINI)               0xe728
 0x0000000000000019 (INIT_ARRAY)         0x2100c0
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
 0x000000000000001a (FINI_ARRAY)         0x2100c8
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
 0x000000006ffffef5 (GNU_HASH)           0x1b8
 0x0000000000000005 (STRTAB)             0x13c0
 0x0000000000000006 (SYMTAB)             0x568
 0x000000000000000a (STRSZ)              2742 (bytes)
 0x000000000000000b (SYMENT)             24 (bytes)
 0x0000000000000003 (PLTGOT)             0x210658
 0x0000000000000002 (PLTRELSZ)           1632 (bytes)
 0x0000000000000014 (PLTREL)             RELA
 0x0000000000000017 (JMPREL)             0x28b8
 0x0000000000000007 (RELA)               0x2048
 0x0000000000000008 (RELASZ)             2160 (bytes)
 0x0000000000000009 (RELAENT)            24 (bytes)
 0x000000006ffffffe (VERNEED)            0x1fa8
 0x000000006fffffff (VERNEEDNUM)         4
 0x000000006ffffff0 (VERSYM)             0x1e76
 0x000000006ffffff9 (RELACOUNT)          14
 0x0000000000000000 (NULL)               0x0

But this is inconsistent with what I've observed the system libraries on my Linux. Hence, I am not entirely sold on the idea of removing -soname, and if you think it is important I can easily revert it.

[kousu]

Also, please investigate what downstream is doing to your package. You can get clues from them, or you need to beat them over the head with a cluestick. I am not familiar enough to judge which.

macports added .dylib-specific flags: -current_version and -compatibility_version. I am not sure how important these are to OS X. The .dylib works without them, but it might be worthwhile to play by Apple's rules.

Debian/Ubuntu thinks LVER=3 and packages libsvm as "libsvm3", but your SHVER=2; what gives?

In good news, libsvm installs almost unmodified on ArchLinux. All they had to add was make lib and where files get finally installed.

[kousu]

Closing in favour of #35 , which is on a feature branch in my repo.