caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
* [Caml-list] [long] not-so-static binaries on Mac OS X
@ 2003-07-08 14:11 Stefano Zacchiroli
  2003-07-08 15:10 ` Xavier Leroy
  0 siblings, 1 reply; 4+ messages in thread
From: Stefano Zacchiroli @ 2003-07-08 14:11 UTC (permalink / raw)
  To: Inria Ocaml Mailing List

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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-07-09  0:35 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-07-08 14:11 [Caml-list] [long] not-so-static binaries on Mac OS X Stefano Zacchiroli
2003-07-08 15:10 ` Xavier Leroy
2003-07-08 16:02   ` Stefano Zacchiroli
2003-07-09  0:35     ` Jacques Garrigue

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).