Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] [long] not-so-static binaries on Mac OS X
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Stefano Zacchiroli <zack@b...>
Subject: [Caml-list] [long] not-so-static binaries on Mac OS X
I'm working on the Mac OS X porting of an OCaml (native code)
application.

I had no problem in making the application compile and run on Mac OS X
using additionally packages from the fink (http://fink.sourceforge.net)
project (like ocaml itself) and some other hand installed ocaml
libraries.

I only encountered problems while trying to distribute the resulting
binaries. Naively compile in native code results, as usual, in a
dynamically linked executable. Unfortunately most of those dependencies
are easily resolvable only using some fink packages, but I don't want to
force the final user of the application to install fink: is huge and I
think is a bit against the standard installation easyness of Mac OS X.

So I tried to compile passing "-static" to the C linker. This doesn't
work and his highly discouraged by Apple that additionally states that
"static linking of users binaries is not supported on Mac OS X"
(http://developer.apple.com/qa/qa2001/qa1118.html).

My next aim was therefore to statically link only certain libraries (in
my case all the ocaml related libraries) and dinamically link only
against the Mac OS X library: "/usr/lib/libSystem.B.dylib".

This turns out to be far from easy, the only working solution I've found
so far is as follow:
- execute the final ocamlopt linking run passing "-verbose" (this shows
  you the execution of an assembly pass on a /tmp/<caml ... .s>
  generating a /tmp/<caml ... .o> object and an execution of gcc linking
  all the objects including the .o in /tmp
- hit CTRL-C (!!!!) just after the .o in /tmp has been created (to avoid
  that it will be deleted [no, "-S" doesn't help here])
- manually execute the final gcc linking command replacing each
  undesired "-l" switch with the corresponding .a library

The result turns out to dynamically depends only on the desired system
libraries.

Ok, but this seems to me a bit tricky ... is not funny to do that for
all the needed executables and for each new release of the application
:-)

The problem is that there is no way to tell ocamlopt to _remove_ a
linker switch while invoking the linker. You can just _add_ switches
(with "-cclib"), but if the linker find both a "-l" switch and a static
".a" library it prefers the dynamic linking.

I've looked at the native code compiler code and is possible to
selectively remove some "-l" switches, but it's a bit tricky because
those switches could come from different "sources". I can try to add a
-rmccopt/-rmcclib switch to ocamlopt but before doing that I would like
to be sure that:
1) there is no other way to do what I'm trying to do
2) such a patch is welcome upstream

TIA,
Cheers.

-- 
Stefano Zacchiroli  --  Master in Computer Science @ Uni. Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it}  -  http://www.bononia.it/zack/
"  I know you believe you understood what you think I said, but I am not
sure you realize that what you heard is not what I meant!  " -- G.Romney

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners