Re: [Caml-list] Error during partial linking

[Chris Hecker <checker@d6.com>]

>like that, so that List, Array, etc., become Std.List, Std.Array, etc, as we
>do now for the labeled modules.
>I suppose it's too late now for such a change, but I'm pretty sympathetic to
>people who grouse over the fact that lots of good names are taken.

It's not too late for a change.  The standard library should be packed 
(resulting in the namespaces you mention above), and then a deprecated 
backwards-compatibility switch can be added to the compiler that does an 
"open Std" before everything, and that should just work (it should be 
inserted before the open Pervasives that's currently there).  You'll have 
to recompile everything, but you have to do that with ocaml version changes 
anyway.  :)

The big problem is linking all the unused code.

Hey, I just had an idea (which just came to me when I thought of the way I 
first attempted to make pack work on win32):  The problem with not linking 
unused code happens at the final link stage and is the c linker's 
fault.  Instead of having -pack make a merged .o (object) to correspond to 
the merged .cmx, it can make a .a (library).  objcopy can rename symbols in 
a library just as easily as in an object (it makes a temp dir and renames 
all the objs, then relibs them, I think...there is one tiny complication 
with the startup code which is totally solveable and I can go into it if 
anybody besides Xavier cares :).  So, you'll have a library that has 
separate objects in it, and those objects will have the nested scope on 
their identifiers.  The final link will resolve only the symbols it needs, 
and the linker will throw out all the other object files like it normally 
does with a library.

I think this will work portably and give all the features we want: 1) 
packing code and interface, 2) namespace nesting, 3) not linking unused code.

If I'm right, we can just throw everything in the standard library, 
including unix and bigarray and str and whatever, into a huge pack file, 
and you'll still only get the things you need (I assume caml is smart 
enough not to link functions from its side of the puzzle (the cmx) if 
they're not used...this solution only solves the external linker obj/lib 
situation).

Chris


-------------------
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