On OSX, load-shared-object does not reload if the dylib contains an @implementation block

[rogual]

Docs state:
> On non-Windows platforms calling load-shared-object again with a pathname equal to the designated pathname of a previous call will replace the old definitions

This usually works as expected, but under some circumstances the reload behaviour doesn't happen. I tracked this down to the presence of an Objective-C @implementation block in the .dylib being loaded.

Here is a test case demonstrating this (also attached). You'll need the developer tools installed. Run “./test.lisp” to see the unexpected behaviour:

-- test.lisp: ------------------------------------------------------------

#!/usr/bin/env sbcl --script

(sb-ext:run-program
 "/usr/bin/gcc"
 '("-o" "lib.dylib" "-dynamiclib" "1.m" "-framework" "Foundation")
 :output t
 :error t
 )
(load-shared-object "lib.dylib")
(define-alien-routine "test" c-string)

(format t "Should be 1: ~A~%" (test))

(sb-ext:run-program
 "/usr/bin/gcc"
 '("-o" "lib.dylib" "-dynamiclib" "2.m" "-framework" "Foundation")
 :output t
 :error t
 )
(load-shared-object "lib.dylib")

(format t "Should be 2: ~A~%" (test))

-- 1.m: ------------------------------------------------------------------

#import <Foundation/Foundation.h>

@interface Test : NSObject
@end

@implementation Test
@end

const char *test()
{
  return "1";
}

-- 2.m: ------------------------------------------------------------------

#import <Foundation/Foundation.h>

@interface Test : NSObject
@end

@implementation Test
@end

const char *test()
{
  return "2";
}

-- System info -----------------------------------------------------------

$ sbcl --version
SBCL 1.3.6

$ uname -a
Darwin MBP 16.0.0 Darwin Kernel Version 16.0.0: Mon Aug 29 17:56:20 PDT 2016; root:xnu-3789.1.32~3/RELEASE_X86_64 x86_64

*FEAUTRES*
(:QUICKLISP :ASDF-PACKAGE-SYSTEM :ASDF3.1 :ASDF3 :ASDF2 :ASDF :OS-MACOSX
 :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE :64-BIT :64-BIT-REGISTERS
 :ALIEN-CALLBACKS :ANSI-CL :ASH-RIGHT-VOPS :BSD :C-STACK-IS-CONTROL-STACK
 :COMMON-LISP :COMPARE-AND-SWAP-VOPS :COMPLEX-FLOAT-VOPS :CYCLE-COUNTER :DARWIN
 :DARWIN9-OR-BETTER :FLOAT-EQL-VOPS :FP-AND-PC-STANDARD-SAVE :GENCGC
 :IEEE-FLOATING-POINT :INLINE-CONSTANTS :INODE64 :INTEGER-EQL-VOP
 :LINKAGE-TABLE :LITTLE-ENDIAN :MACH-EXCEPTION-HANDLER :MACH-O
 :MEMORY-BARRIER-VOPS :MULTIPLY-HIGH-VOPS :OS-PROVIDES-BLKSIZE-T
 :OS-PROVIDES-DLADDR :OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC
 :OS-PROVIDES-SUSECONDS-T :PACKAGE-LOCAL-NICKNAMES :PRECISE-ARG-COUNT-ERROR
 :RAW-INSTANCE-INIT-VOPS :SB-CORE-COMPRESSION :SB-DOC :SB-EVAL :SB-LDB
 :SB-PACKAGE-LOCKS :SB-SIMD-PACK :SB-SOURCE-LOCATIONS :SB-TEST :SB-THREAD
 :SB-UNICODE :SBCL :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-FIXED-OBJECTS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-VECTORS
 :STACK-GROWS-DOWNWARD-NOT-UPWARD :SYMBOL-INFO-VOPS :UD2-BREAKPOINTS :UNIX
 :UNWIND-TO-FRAME-AND-CALL-VOP :X86-64)

[rogual (rogual)]

It looks like this is an OSX limitation: http://stackoverflow.com/questions/8793099/unload-dynamic-library-needs-two-dlclose-calls

I think a good resolution for this would just be to put a note in the docs and close the issue.