[Caml-list] Error during partial linking

[Caml-list] Error during partial linking

[Yang Shouxun]

Hi,

I'm trying to compile "baire" data structures library and package it as a 
.deb. I have a problem when try to pack all the modules as a single "baire" 
module to avoid name clash with stdlibs. The error message is shown as the 
title.

Both byte compile and native compile work. Using "-pack" option for byte 
compiler also works as expected. The following is the line in my Makefile 
that gives the error.
---8<---
$(CAMLOPT) -pack -o $(RESULT:.cmo=.cmx) $(SOURCES:.ml=.cmx) $(SOURCES:.ml=.o)
---8<---

What can be likely reasons for this error?

TIA!
shouxun
-------------------
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

Re: [Caml-list] Error during partial linking

[Xavier Leroy]

> I'm trying to compile "baire" data structures library and package it
> as a .deb. I have a problem when try to pack all the modules as a
> single "baire" module to avoid name clash with stdlibs. The error
> message is shown as the title.

If you want help, you should provide more context for the error,
i.e. the command that fails and all error messages it prints.
Adding the "-verbose" option to ocamlopt will give even more useful
context.  At any rate:

> $(CAMLOPT) -pack -o $(RESULT:.cmo=.cmx) $(SOURCES:.ml=.cmx) $(SOURCES:.ml=.o)

The -o $(RESULT:.cmo=.cmx) might be wrong, since $(RESULT) is
(apparently) "baire", not "baire.cmo".

The $(SOURCES:.ml=.o) is wrong too, you should just pass the .cmx
files to ocamlopt, it will deal with the underlying .o files all by
itself.

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

Re: [Caml-list] Error during partial linking

[Sven Luther]

On Tue, Oct 22, 2002 at 10:42:15AM +0200, Xavier Leroy wrote:
> > I'm trying to compile "baire" data structures library and package it
> > as a .deb. I have a problem when try to pack all the modules as a
> > single "baire" module to avoid name clash with stdlibs. The error
> > message is shown as the title.
> 
> If you want help, you should provide more context for the error,
> i.e. the command that fails and all error messages it prints.
> Adding the "-verbose" option to ocamlopt will give even more useful
> context.  At any rate:
> 
> > $(CAMLOPT) -pack -o $(RESULT:.cmo=.cmx) $(SOURCES:.ml=.cmx) $(SOURCES:.ml=.o)
> 
> The -o $(RESULT:.cmo=.cmx) might be wrong, since $(RESULT) is
> (apparently) "baire", not "baire.cmo".
> 
> The $(SOURCES:.ml=.o) is wrong too, you should just pass the .cmx
> files to ocamlopt, it will deal with the underlying .o files all by
> itself.

Xavier,

Is there a particular reason why ocamlmklib does not support the pack
option ?

$ cat a.ml
let z = 0
$ cat b.ml
let z = 1
$ ocamlc -c a.ml 
$ ocamlc -c b.ml 
$ ocamlc -a -pack -o lib.cma a.cmo b.cmo
$ cat c.ml
let z = 18
let () = Printf.printf "z = %d, A.z = %d, B.z = %d\n" z A.z B.z
$ ocamlc -o test lib.cma c.cmo
$ ./test
z = 18, A.z = 1, B.z = 0

But ...

$ ocamlmklib -pack -o lib a.cmo b.cmo
Unknown option -pack

Is this because the pack option is not supported on all arches ?

Also, i have the feeling that the correct way of distributing a bunch of
.cmo is to create a .cma, not to cram them together in a super .cmo
thanks to the pack option, i may be wrong about this though.

The current documentation only gives an example of using the -pack
option to build .cmos, not to build a .cma. Maybe such an example could
be added, or at least a little notice about it ?

BTW, advi build fails on ia64, i think ocamlopt on ia64 does not like the
big array in dvicolor.ml, since removing some of the entries will make
the build work (you have to cut them after grey50 or somethign such). Is
this a bug in ocamlopt/ia64, or a normal restriction on array size ?

Friendly,

Sven Luther






I have a question about this selfsame behavior, but then i admit, i did
not have time to test this myself.

My impression of the way to use the pack option is that you should use
it to create libraries, not super object files like it is done here.

I think the natural way of distributing a bunch of .cmo is to provide a
.cma, like it was done before, not have people 
-------------------
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

Re: [Caml-list] Error during partial linking

[Chris Hecker]

>Also, i have the feeling that the correct way of distributing a bunch of
>.cmo is to create a .cma, not to cram them together in a super .cmo
>thanks to the pack option, i may be wrong about this though.

No, if I understand the situation correctly, you actually want a packed 
cm[ox] (a new object), not a cmx?a (a library).  This is because the 
libraries still require the discrete cmi files, while the packed object 
puts all the interfaces into a single cmi and scopes the names inside the 
packed namespace, which is obviously vastly superior for distribution.

However, the issue with objects is whether the linker does the right thing 
with regards to throwing away unused code.  In other words, if I have a 
library with a.cmo and b.cmo, and I only use module A, you won't get any of 
b.cmo in your app.  However, if I use a packed object, c.cmo which has both 
as submodules, I don't know if it just includes everything or not.  We 
should test this.  The potential badness is even worse with the native code 
objects, becuase they're so much bigger.

The right thing is obviously to have a "library" (quoted because it could 
be a packed object or a library) that allows merged code and interface 
files, nested namespaces, and also supports not linking unused 
code.  However, -pack is still _way_ better than nothing, so I think we 
should all use it until the perfect solution comes along.  Hopefully it'll 
be working on win32/msvc soon (I patched the compiler and sent the info to 
Xavier).

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

Re: [Caml-list] Error during partial linking

[Sven Luther]

On Tue, Oct 22, 2002 at 09:17:53AM -0700, Chris Hecker wrote:
> The right thing is obviously to have a "library" (quoted because it could 
> be a packed object or a library) that allows merged code and interface 
> files, nested namespaces, and also supports not linking unused 
> code.  However, -pack is still _way_ better than nothing, so I think we 
> should all use it until the perfect solution comes along.  Hopefully it'll 
> be working on win32/msvc soon (I patched the compiler and sent the info to 
> Xavier).

Well, i was asking this thing, not for now, but as a future direction.

BTW, if you pack the .cmos into a single .cmo and then put this one in a
.cma, you should get the same benefit as what you describe, isn't it ?

Or maybe using -pack with -a should do this.

Friendly,

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

Re: [Caml-list] on the -pack option

[Xavier Leroy]

> Is there a particular reason why ocamlmklib does not support the pack
> option ?

Well, basically because I think it wouldn't make much sense.
The job of ocamlmklib is to build a mixed C/Caml library, that is:
- a ".cma" Caml library
- a ".a" and/or ".so" C library
- the necessary annotations in the ".cma" so that the C part is
  automatically linked.

I feel that packing a set of Caml object files (.cmo) into
substructures of a single Caml object file (which is what -pack does)
is best done by a separate invocation of ocamlc -pack.  That is,
you can always do
        ocamlc -pack -o mylib.cmo a.cmo b.cmo c.cmo
        ocamlmklib -o mylib ... mylib.cmo

> Also, i have the feeling that the correct way of distributing a bunch of
> .cmo is to create a .cma, not to cram them together in a super .cmo
> thanks to the pack option, i may be wrong about this though.
> 
> The current documentation only gives an example of using the -pack
> option to build .cmos, not to build a .cma. Maybe such an example could
> be added, or at least a little notice about it ?

I agre with Chris' reply.  Maybe the docs should be clearer about
this, but basically a .cma is a set of .cmo, while -pack builds a
single .cmo from other .cmo.  Nothing prevents you from packing cmo's
into lib.cmo (ocamlc -pack -o lib.cmo ...), then building
lib.cma containing only lib.cmo (ocamlc -a -o lib.cma lib.cmo).
That might be useful if your lib also needs C code, as shown above.

> [about not linking unused code]
> BTW, if you pack the .cmos into a single .cmo and then put this one in a
> .cma, you should get the same benefit as what you describe, isn't it ?

Unfortunately not.  The .cma contains only one .cmo, which is either
not linked at all or linked in full.  For the bytecode compiler, it
could be possible to eliminate unused code with a finer grain.  But
for the native-code, we are severely constrained by what the Unix and
Win32 linkers know how to do, and they can only eliminate whole object
files, not parts of them.

For some libraries, this isn't really a problem: by design, you'll
generally use most of their modules.  For other libraries (e.g. Baire :-)
it's more problematic.  There is a delicate trade-off here between
selective linking and avoiding compilation unit namespace pollution.
I can't say I'm completely happy about this, but I'm afraid this is
the best we can do with the limited abilities of today's linkers.

> BTW, advi build fails on ia64

Yes, your bug report is in the database and will be addressed in due time.

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

Re: [Caml-list] on the -pack option

[Sven Luther]

On Tue, Oct 22, 2002 at 07:14:24PM +0200, Xavier Leroy wrote:
> > Is there a particular reason why ocamlmklib does not support the pack
> > option ?
> 
> Well, basically because I think it wouldn't make much sense.
> The job of ocamlmklib is to build a mixed C/Caml library, that is:
> - a ".cma" Caml library
> - a ".a" and/or ".so" C library
> - the necessary annotations in the ".cma" so that the C part is
>   automatically linked.
> 
> I feel that packing a set of Caml object files (.cmo) into
> substructures of a single Caml object file (which is what -pack does)
> is best done by a separate invocation of ocamlc -pack.  That is,
> you can always do
>         ocamlc -pack -o mylib.cmo a.cmo b.cmo c.cmo
>         ocamlmklib -o mylib ... mylib.cmo

Well, one more step in the makefile, it would be no problem, but since
ocamlmklib is a wrapper anyway, what about making :

ocamlmklib -pack -o mylib a.cmo b.cmo c.cmo 

To just be a shortcut for the above two ?

This would seem more logical from a user perspective point, and you
would be able to simply use ocamlmklib for doing libraries, and to
simply specify -pack if you want the .cmos packed.

> > [about not linking unused code]
> > BTW, if you pack the .cmos into a single .cmo and then put this one in a
> > .cma, you should get the same benefit as what you describe, isn't it ?
> 
> Unfortunately not.  The .cma contains only one .cmo, which is either
> not linked at all or linked in full.  For the bytecode compiler, it
> could be possible to eliminate unused code with a finer grain.  But

Would it make sense doing this for bytecode and not native code ?

> for the native-code, we are severely constrained by what the Unix and
> Win32 linkers know how to do, and they can only eliminate whole object
> files, not parts of them.
> 
> For some libraries, this isn't really a problem: by design, you'll
> generally use most of their modules.  For other libraries (e.g. Baire :-)

So you suggest Shouxun should better forget about using -pack in the
Baire makefile ?

> > BTW, advi build fails on ia64
> 
> Yes, your bug report is in the database and will be addressed in due time.

Err, sorry, i forgot i had filled a bugreport.

BTW, like i said, maybe i am spoiled by the debian BTS, but should the
ocaml BTS not give some feedback when a bug report you submit is being
processed ? Maybe you could request this feature by setting a flag that
your bug report processor will recognize and trigger feedback mails ?

Friendly,

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

Re: [Caml-list] Error during partial linking

[Yang Shouxun]

On Tuesday 22 October 2002 16:42, you wrote:
> If you want help, you should provide more context for the error,
> i.e. the command that fails and all error messages it prints.
> Adding the "-verbose" option to ocamlopt will give even more useful

There's no other error message. Yes, I should have add the "-verbose" option.

> context.  At any rate:
> > $(CAMLOPT) -pack -o $(RESULT:.cmo=.cmx) $(SOURCES:.ml=.cmx)
> > $(SOURCES:.ml=.o)
> The -o $(RESULT:.cmo=.cmx) might be wrong, since $(RESULT) is
> (apparently) "baire", not "baire.cmo".

I've set $(RESULT) to "baire.cmo" -- seemingly unconventional.

> The $(SOURCES:.ml=.o) is wrong too, you should just pass the .cmx
> files to ocamlopt, it will deal with the underlying .o files all by
> itself.

My fault. At first I follow other examples (that is, without 
$(SOURCES:.ml=.o). When I cannot find out what's the cause of the error, I 
add it in desperation. And this does not make a change at all.

Now I remove that redundant part and add the verbose option, I get the 
following spit out:
---8<---
ocamlopt -pack -verbose -o baire.cmx bairePervasives.cmx [...] 
weightBalancedMap.cmx 
+ as -o '/tmp/camlpackagef06eb8.o' '/tmp/camlpackage2ad2ef.s'
+ ld -r  -o 'baire.o' '/tmp/camlpackagef06eb8.o' 'bairePervasives.o' [...] 
'weightBalancedMap.o'
+ /usr/bin/nm 'baire.o' > '/tmp/camlsymbolse063ad'
+ /usr/bin/objcopy --redefine-sym 
'WeightBalancedSet__zero_227=Baire__WeightBalancedSet__zero_227' [...] 
--redefine-sym 'AmortizedQueue=Baire__AmortizedQueue' 'baire.o'
Error during partial linking
make[1]: *** [nativepack] Error 2
---8<---

To make the list short, I use [...] to elide what come between. The problem is 
it's ok to "-pack" the byte-compiled .cmo files, but not to "-pack" the 
native-compiled .cmx files. 

I can now use the packed baire library in the toplevel and bytecode modes, but 
not the native-code mode. Besides the "-pack" problem, baire provides modules 
that have name clash with the stdlibs modules. I'm wondering whether it's 
possible to use the those of baire instead of the stdlibs. I don't know how 
so far. When compile and link in the native-code mode, it complains there is 
such a name clash and aborts.

Thanks!
shouxun
-------------------
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

Re: [Caml-list] Error during partial linking

[Chris Hecker]

>+ /usr/bin/objcopy --redefine-sym
>'WeightBalancedSet__zero_227=Baire__WeightBalancedSet__zero_227' [...]
>--redefine-sym 'AmortizedQueue=Baire__AmortizedQueue' 'baire.o'
>Error during partial linking
>make[1]: *** [nativepack] Error 2

I think this is the command line length limit problem, for which there is a 
FIXME comment in the asmcomp/asmpackager.ml.  The fix is really simple and 
localized (fold over the symbols_to_rename and break them up into smaller 
chunks, and then iter over that list of lists calling objcopy), but you'll 
have to patch the compiler to do it.

I don't know of a workaround except building multiple smaller packed files.

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

Re: [Caml-list] Error during partial linking

[Xavier Leroy]

> >+ /usr/bin/objcopy --redefine-sym
> >'WeightBalancedSet__zero_227=Baire__WeightBalancedSet__zero_227' [...]
> >--redefine-sym 'AmortizedQueue=Baire__AmortizedQueue' 'baire.o'
> >Error during partial linking
> >make[1]: *** [nativepack] Error 2
> 
> I think this is the command line length limit problem, for which there is a 
> FIXME comment in the asmcomp/asmpackager.ml.

This is also my guess, although I was expecting an error message to be
printed by the shell (but then it's perhaps system() itself that
fails).  I'll fix this length limit issue soon in the CVS version.
Too bad objcopy cannot take its symbol redefinitions from a file...

Coming back to your initial desire to "pack" Baire (if I may say so),
I would very strong advise Diego to name his "List" module something
else, to avoid conflict with the standard library module of the same
name.  The hypothesis that compilation units are identified by unique
names is really essential to the way the OCaml compilers work.  I know
it's sometimes an annoyance (all cool names are already taken by the
standard lib :-), but you're really going to run into trouble with
name conflicts.

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

Re: [Caml-list] Error during partial linking

[Chris Hecker]

> > >Error during partial linking
> > I think this is the command line length limit problem, for which there 
> is a
> > FIXME comment in the asmcomp/asmpackager.ml.
>This is also my guess, although I was expecting an error message to be
>printed by the shell (but then it's perhaps system() itself that
>fails).

Yes, it failed anonymously for me as well (on freebsd, when I was testing 
my win32 patch...this is a reminder to reply to my mail to you about that, 
too :).

>I'll fix this length limit issue soon in the CVS version.
>Too bad objcopy cannot take its symbol redefinitions from a file...

Yep, all programs should be able to take a response file for arguments.

>Coming back to your initial desire to "pack" Baire (if I may say so),
>I would very strong advise Diego to name his "List" module something
>else, to avoid conflict with the standard library module of the same
>name.  The hypothesis that compilation units are identified by unique
>names is really essential to the way the OCaml compilers work.  I know
>it's sometimes an annoyance (all cool names are already taken by the
>standard lib :-), but you're really going to run into trouble with
>name conflicts.

We just need to pack the standard library and be done with it, and then it 
will finally liberate all of those common names for user programs!  It's 
the Right Thing.  :)

Hmm, now that I think about it, the native code pack could just shove any 
dependent C obj/lib files into the packed object as well, truly doing away 
with any external files.  Maybe it already does this...

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

Re: [Caml-list] Error during partial linking

[brogoff]

On Tue, 22 Oct 2002, Xavier Leroy wrote:
> Coming back to your initial desire to "pack" Baire (if I may say so),
> I would very strong advise Diego to name his "List" module something
> else, to avoid conflict with the standard library module of the same
> name.  The hypothesis that compilation units are identified by unique
> names is really essential to the way the OCaml compilers work.  I know
> it's sometimes an annoyance (all cool names are already taken by the
> standard lib :-), but you're really going to run into trouble with
> name conflicts.

This is one of those things that's always troubled me (perhaps there's another 
petty complaint coming up) about OCaml. In a language with a hierarchical 
module system, it seems that we should be able to avoid such problems by 
having the standard library packages nested under a "Std" module, or something 
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. 

-- Brian


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

Re: [Caml-list] Error during partial linking

[Dmitry Bely]

brogoff@speakeasy.net writes:

>> Coming back to your initial desire to "pack" Baire (if I may say so),
>> I would very strong advise Diego to name his "List" module something
>> else, to avoid conflict with the standard library module of the same
>> name.  The hypothesis that compilation units are identified by unique
>> names is really essential to the way the OCaml compilers work.  I know
>> it's sometimes an annoyance (all cool names are already taken by the
>> standard lib :-), but you're really going to run into trouble with
>> name conflicts.
>
> This is one of those things that's always troubled me (perhaps there's another 
> petty complaint coming up) about OCaml. In a language with a hierarchical 
> module system, it seems that we should be able to avoid such problems by 
> having the standard library packages nested under a "Std" module, or something 
> like that, so that List, Array, etc., become Std.List, Std.Array, etc, as we 
> do now for the labeled modules.

That was exactly my proposal some time ago:

http://caml.inria.fr/archives/200208/msg00432.html

> I suppose it's too late now for such a change,

No way! It would only require adding "open Std" to the existing
sources. But we can even introduce it transparately (although I think it is
really not necessary): open Std by default (like Pervasives) and having a
compiler flag "-nostd" (like "-nopervasives") to disable this auto open.

> but I'm pretty sympathetic to 
> people who grouse over the fact that lots of good names are taken. 

Everybody except Ocaml developers seems to agree that the standard library
in Std module is a good idea :-)

- Dmitry Bely


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

Re: [Caml-list] Error during partial linking

[Alain Frisch]

On Wed, 23 Oct 2002, Dmitry Bely wrote:

> No way! It would only require adding "open Std" to the existing
> sources. But we can even introduce it transparately (although I think it is
> really not necessary): open Std by default (like Pervasives) and having a
> compiler flag "-nostd" (like "-nopervasives") to disable this auto open.

In which cases would we need -nostd ?  The only harm an "open" statement
can do is to hide previous definitions, but if it is inserted
automatically at the beginning, what's the problem ?

-- Alain

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

Re: [Caml-list] Error during partial linking

[Dmitry Bely]

Alain Frisch <frisch@clipper.ens.fr> writes:

>> No way! It would only require adding "open Std" to the existing
>> sources. But we can even introduce it transparately (although I think it is
>> really not necessary): open Std by default (like Pervasives) and having a
>> compiler flag "-nostd" (like "-nopervasives") to disable this auto open.
>
> In which cases would we need -nostd ?  The only harm an "open" statement
> can do is to hide previous definitions, but if it is inserted
> automatically at the beginning, what's the problem ?

I meant programmers should manually add "open Std" to the existing sources
using a text editor. I would prefer no auto open of Std (old C++ habits
:-)), buf of course I can live with it. BTW, if you think "-nostd" is not
necessary, why we have "-nopervasives" option?

- Dmitry Bely


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

Re: [Caml-list] Error during partial linking

[Alain Frisch]

On Wed, 23 Oct 2002, Dmitry Bely wrote:

> I meant programmers should manually add "open Std" to the existing sources
> using a text editor. I would prefer no auto open of Std (old C++ habits
> :-))

I think I have understood your position; what I don't understand in the
technical motivation. The only case I can see where you wouln't want to
have an automatic "open Std" is if you want to use, say, a custom
List module which is not itself -packaged.

>, buf of course I can live with it. BTW, if you think "-nostd" is not
> necessary, why we have "-nopervasives" option?

Is this option used, except for compiling the stdlib itself ?


-- Alain

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

Re: [Caml-list] Error during partial linking

[Dmitry Bely]

Alain Frisch <frisch@clipper.ens.fr> writes:

>> I meant programmers should manually add "open Std" to the existing sources
>> using a text editor. I would prefer no auto open of Std (old C++ habits
>> :-))
>
> I think I have understood your position; what I don't understand in the
> technical motivation. The only case I can see where you wouln't want to
> have an automatic "open Std" is if you want to use, say, a custom
> List module which is not itself -packaged.

Exactly. I would like to have the global namespace not polluted by default,
so that I could create any custom module (List, Array or whatever) not
thinking of the possible name clash.

- Dmitry Bely


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

Re: [Caml-list] Error during partial linking

[Alessandro Baretta]

Dmitry Bely wrote:
> Alain Frisch <frisch@clipper.ens.fr> writes:
> 
>>In which cases would we need -nostd ?  The only harm an "open" statement
>>can do is to hide previous definitions, but if it is inserted
>>automatically at the beginning, what's the problem ?
> 
> 
> I meant programmers should manually add "open Std" to the existing sources
> using a text editor. I would prefer no auto open of Std (old C++ habits
> :-)), buf of course I can live with it. BTW, if you think "-nostd" is not
> necessary, why we have "-nopervasives" option?
> 
> - Dmitry Bely

The -nostd should be implicit with -nopervasives. You do not 
want to open a module that is not linked (compile time 
error). So, if you do not want Pervasives, you do not want 
an "open Std".

Alex

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

Re: [Caml-list] Error during partial linking

[Chris Hecker]

>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

Re: [Caml-list] Error during partial linking

[Sven Luther]

On Tue, Oct 22, 2002 at 07:00:56PM +0200, Xavier Leroy wrote:
> Coming back to your initial desire to "pack" Baire (if I may say so),
> I would very strong advise Diego to name his "List" module something
> else, to avoid conflict with the standard library module of the same
> name.  The hypothesis that compilation units are identified by unique
> names is really essential to the way the OCaml compilers work.  I know
> it's sometimes an annoyance (all cool names are already taken by the
> standard lib :-), but you're really going to run into trouble with
> name conflicts.

That is what -pack is for, isn't it ?

Friendly,

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

Re: [Caml-list] Error during partial linking

[Chris Hecker]

> > names is really essential to the way the OCaml compilers work.  I know
> > it's sometimes an annoyance (all cool names are already taken by the
> > standard lib :-), but you're really going to run into trouble with
> > name conflicts.
>That is what -pack is for, isn't it ?

Sort of, but Xavier's point is that during compiling of the submodules of 
the packed final product, you'll have a list.* in your project, and that's 
bad because it will screw up with the standard library one.  However, this 
will not happen if the standard library is packed, because then there's no 
list.* sitting around to confuse the compiler.

This is the real reason to pack the library, because no only does it 
pollute the namespace (rude), but it also simply doesn't allow you to have 
modules named the same even if you don't use the standard ones if I 
understand Xavier's warning correctly (which is more than rude).

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

Re: [Caml-list] Error during partial linking

[David Brown]

On Tue, Oct 22, 2002 at 04:38:48PM -0700, Chris Hecker wrote:

> >That is what -pack is for, isn't it ?

Has anyone though of a way to actually put submodules in separate files.
Ada allows this by placing the modules in separate files (you can still
code the submodule (package) in the one file).  The GNU Ada compiler
uses naming conventions to resolve this.

For example:

A file   std-list.ml

would be the module Std.List

We have to figure out how this interacts with the std.ml module, but
this is the general idea.

This is actually the single feature I've wished the ocaml module system
had.  The Ada approach also allows you to add submodules after the fact.

One proposal would be that before compiling std-list.ml, you have to
compile std.ml.  When std-list.cmo is linked, the new module (List) is
added to the std's names.  There is a possibility of duplicate names,
but camls seems to handle that normally by just replacing the previous
definition.

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

Re: [Caml-list] Error during partial linking

[Diego Olivier Fernandez Pons]

    Bonjour,

On Tue, Oct 22, 2002 at 07:00:56PM +0200, Xavier Leroy wrote:

> Coming back to your initial desire to "pack" Baire (if I may say
> so), I would very strong advise Diego to name his "List" module
> something else, to avoid conflict with the standard library module
> of the same name.  The hypothesis that compilation units are
> identified by unique names is really essential to the way the OCaml
> compilers work.  I know it's sometimes an annoyance (all cool names
> are already taken by the standard lib :-), but you're really going
> to run into trouble with name conflicts.

I do not follow all the discussions of the caml-list so I hadn't seen
this message before.

Baire [List] has been moved to [BaireList] (in the same way
BairePervasives worked before)  to avoid conflicts and all "cool"
names have been liberated for standard library compatibility

All this of course in Baire 0.1 (not yet avaible for downloading)

>
> That is what -pack is for, isn't it ?
>

I tried that but it didn't work (I do not know why), and I gave up
mostly because the second solution seemed cleaner to me.

The Caml-team should feel free to take whatever they want in Baire
anyway and include it in the standard library, without any restriction
(I can send you a more official authorisation if you need)

        Diego Olivier

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

Re: [Caml-list] Error during partial linking

[Sven Luther]

On Wed, Oct 23, 2002 at 12:01:42PM +0200, Diego Olivier Fernandez Pons wrote:
>     Bonjour,
> 
> On Tue, Oct 22, 2002 at 07:00:56PM +0200, Xavier Leroy wrote:
> 
> > Coming back to your initial desire to "pack" Baire (if I may say
> > so), I would very strong advise Diego to name his "List" module
> > something else, to avoid conflict with the standard library module
> > of the same name.  The hypothesis that compilation units are
> > identified by unique names is really essential to the way the OCaml
> > compilers work.  I know it's sometimes an annoyance (all cool names
> > are already taken by the standard lib :-), but you're really going
> > to run into trouble with name conflicts.
> 
> I do not follow all the discussions of the caml-list so I hadn't seen
> this message before.
> 
> Baire [List] has been moved to [BaireList] (in the same way

:(((

It should be in Baire.List, i think.

> > That is what -pack is for, isn't it ?
> >
> 
> I tried that but it didn't work (I do not know why), and I gave up
> mostly because the second solution seemed cleaner to me.

Well, Shouxun is trying to make packing of baire work. But then, he
redid the makefile, and you use ocammakefile. Maybe ocamlmakefile is not
-pack aware ?

> The Caml-team should feel free to take whatever they want in Baire
> anyway and include it in the standard library, without any restriction
> (I can send you a more official authorisation if you need)

:)))

Friendly,

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

Re: [Caml-list] Error during partial linking

[Alessandro Baretta]

Sven Luther wrote:

> 
> Well, Shouxun is trying to make packing of baire work. But then, he
> redid the makefile, and you use ocammakefile. Maybe ocamlmakefile is not
> -pack aware ?
> 

The OCamlMakefile is now both -pack and ocamlfind aware.

Alex

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