Sure! Unfortunately I don't have a mac available, but I just read mac c++ doesn't support '-shared' and uses '-dynamiclib' instead. I just pushed a change to the Makefile for that, could you give it another go?

Still the same error :(

c++ -fPIC -D__LITTLE_ENDIAN__ -c -o sfklCoding.o sfklCoding.cpp
sfklCoding.cpp:551:8: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare]
if (n < 0 || n > ZBUF_SIZE) // Check for valid block length
~ ^ ~
sfklCoding.cpp:553:78: warning: format specifies type 'long' but the argument has type 'uint32_t' (aka 'unsigned int') [-Wformat]
sprintf(MsgTxt, "ERROR - Invalid length for Non-audio Block (apparently %ld bytes) %s", n, CorruptedMsg);
~~^ ~
%d
2 warnings generated.
c++ -fPIC -D__LITTLE_ENDIAN__ -c -o sfklDiff.o sfklDiff.cpp
c++ -fPIC -D__LITTLE_ENDIAN__ -c -o sfklLPC.o sfklLPC.cpp
c++ -fPIC -D__LITTLE_ENDIAN__ -c -o sfklZip.o sfklZip.cpp
c++ -fPIC -D__LITTLE_ENDIAN__ -c -o sfklCrunch.o sfklCrunch.cpp
c++ -fPIC -D__LITTLE_ENDIAN__ -c -o sfklFile.o sfklFile.cpp
c++ -fPIC -D__LITTLE_ENDIAN__ -c -o sfklString.o sfklString.cpp
c++ -shared -dynamiclib sfklCoding.o sfklDiff.o sfklLPC.o sfklZip.o sfklCrunch.o sfklFile.o sfklString.o -o libsfark.so
Undefined symbols for architecture x86_64:
"sfkl_DisplayNotes(char const_, char const_)", referenced from:
ExtractTextFile(BLOCK_DATA_, unsigned long) in sfklCoding.o
"sfkl_UpdateProgress(int)", referenced from:
sfkl_Decode(char const_, char const_) in sfklCoding.o
"sfkl_GetLicenseAgreement(char const_, char const_)", referenced from:
ExtractTextFile(BLOCK_DATA_, unsigned long) in sfklCoding.o
"sfkl_msg(char const_, int)", referenced from:
ReadHeader(V2_FILEHEADER_, unsigned char_, int) in sfklCoding.o
InvalidEncodeCount(int, int) in sfklCoding.o
DecompressTurbo(BLOCK_DATA_, unsigned short) in sfklCoding.o
CheckShift(short_, unsigned short, short_, short_) in sfklCoding.o
DecompressFast(BLOCK_DATA_, unsigned short) in sfklCoding.o
ProcessNextBlock(BLOCK_DATA_) in sfklCoding.o
ExtractTextFile(BLOCK_DATA_, unsigned long) in sfklCoding.o
...
"adler32", referenced from:
ReadHeader(V2_FILEHEADER, unsigned char_, int) in sfklCoding.o
ProcessNextBlock(BLOCK_DATA_) in sfklCoding.o
ExtractTextFile(BLOCK_DATA_, unsigned long) in sfklCoding.o
"uncompress", referenced from:
UnMemcomp(unsigned char const, int, unsigned char_, int) in sfklZip.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libsfark.so] Error 1

BTW, Mac OS X 10.8 is using clang.

Using clang on linux doesn't report any linker errors:

arnouten@jaga:~/dev/sfArkLib$ CXX=clang make 
clang -fPIC -D__LITTLE_ENDIAN__   -c -o sfklCoding.o sfklCoding.cpp
sfklCoding.cpp:551:8: warning: comparison of unsigned expression < 0 is always false
      [-Wtautological-compare]
        if (n < 0  ||  n > ZBUF_SIZE)   // Check for valid block length
            ~ ^ ~
sfklCoding.cpp:553:78: warning: conversion specifies type 'long' but the argument has type
      'uint32_t' (aka 'unsigned int') [-Wformat]
  ..."ERROR - Invalid length for Non-audio Block (apparently %ld bytes) %s", n, CorruptedMsg);
                                                             ~~^             ~
                                                             %u                               
2 warnings generated.
clang -fPIC -D__LITTLE_ENDIAN__   -c -o sfklDiff.o sfklDiff.cpp
clang -fPIC -D__LITTLE_ENDIAN__   -c -o sfklLPC.o sfklLPC.cpp
clang -fPIC -D__LITTLE_ENDIAN__   -c -o sfklZip.o sfklZip.cpp
clang -fPIC -D__LITTLE_ENDIAN__   -c -o sfklCrunch.o sfklCrunch.cpp
clang -fPIC -D__LITTLE_ENDIAN__   -c -o sfklFile.o sfklFile.cpp
clang -fPIC -D__LITTLE_ENDIAN__   -c -o sfklString.o sfklString.cpp
clang -shared -dynamiclib sfklCoding.o sfklDiff.o sfklLPC.o sfklZip.o sfklCrunch.o sfklFile.o sfklString.o -o libsfark.so
clang: warning: argument unused during compilation: '-dynamiclib'
arnouten@jaga:~/dev/sfArkLib$ 

I'd have to google around a bit for more ideas on how to solve this for you.

Ok raboof! I just instaled some sfark utility on a windows vm... but it would be cool to have this app running natively! :) Have a nice day.

change the compiler line to $(CXX) -lz -shared -dynamiclib $(OBJECTS) -o libsfark.so it seems to solve the things related to zlib! :)

OK. As I don't own a Mac I won't work on this for now. If anyone has a suggestion/solution be sure to chime in.

Was able to get this going by adding "-flat_namespace -undefined suppress" to the linker flags.

Basically, by default Mac OS X uses the concept of a 'two-level namespace', which allows one to specify at link time which dynamic library should be used to bind any particular symbol. https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/Xcode-3.2.5/man1/ld_classic.1.html contains a fairly useful description of this feature.

This library assumes the existence of symbols which the application that links to it will provide; the only way that I can see to allow this circular dependency is to disable this 'two-level namespace' functionality.

OK, added this (commented-out) to the Makefile.

Is this the right place to add the options? Can you verify it works like this?

Is this the best we can do or is there a way to add them in a way that doesn't break building on Linux? Some kind of autodetect?

Nope, this change doesn't work -- the options need to go in the libsfark.so rule.

According to http://stackoverflow.com/questions/714100/os-detecting-makefile, the generally-accepted way of detecting which platform you're building on is to parse the output of uname. I kind of like the "gcc -dumpmachine" method, although even then, your build target isn't what you're really after -- your goal for this change specifically is to figure out which compiler you're dealing with. Probably only the Apple-supplied clang compiler has these options. Realistically, though, if anyone's doing cross-compiling from a Mac for some reason -- I can't think of very many reasons -- they are already likely to be tweaking the makefile themselves, so fixing up the compiler flags too is not a big hurdle.

In case you're interested, though, output of gcc --version on my machine:

Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

Can you propose how to modify the Makefile to make it as easy for Mac users to build the library as possible, without breaking it for the linux users?

Pull request submitted which corrects build. tested on OSX Mavericks and Linux Mint 15. Install command not fixed.

I also have a CMake build almost correct - still learning OSX builds myself, and this type of lib is a bit of an oddball.