You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
as a pragmatic solution to the problem that -pack does not work for every
platform, I have the following suggestion: Currently, the symbols are renamed
after machine-code generation, and this is why objcopy is needed. To work around
this, I suggest to rename the symbols before machine-code generation. This
does not need any further tools.
ocamlopt could be called as follows:
ocamlopt -c module.ml -for-pack
This would already generate a module.o where the symbols are renamed. In
module.cmx, a special flag would be included indicating that this happened.
Later, when
ocamlopt -pack ...
is called, only these specially prepared modules are accepted. Conversely, it is
forbidden to use these modules for anything else.
I hope that this change helps that -pack is widely adopted. I don't see any
other way to handle name clashes in an intelligent way. You know that there are
some library authors who are unwilling to rename their modules (i.e. the
cooperative social solution), and I also think it is not the task of O'Caml
distributions to make pressure on the authors in this respect. All other
solutions to the problem are somehow dumb, e.g. a registry of module names, or
something like this.
In the hope the cathedral understands what is going on on the bazaar,
Gerd Stolpmann
The text was updated successfully, but these errors were encountered:
as a pragmatic solution to the problem that -pack does not work for every
platform,
Well, GNU binutils are available for all platforms supported by ocamlopt,
so ocamlopt -pack does work for every platform, in a way. But it is
true that installing binutils (when they are not installed by default)
is a bit of a pain, and the code in ocamlopt that performs the symbol
renaming is somewhat ugly.
I have the following suggestion: Currently, the symbols are renamed
after machine-code generation, and this is why objcopy is needed. To
work around this, I suggest to rename the symbols before
machine-code generation. This does not need any further tools.
It's a highly reasonable suggestion. I cannot say offhand how easy
it is to implement (it looks like one of those "small" changes that
can impact many little things in the compiler), but will try to look
at this when I have a bit more time.
Original bug ID: 2500
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Bug description
Full_Name: Gerd Stolpmann
Version: 3.07pl2
OS: All
Submission from: p508170d8.dip0.t-ipconnect.de (80.129.112.216)
Hello cathedral,
as a pragmatic solution to the problem that -pack does not work for every
platform, I have the following suggestion: Currently, the symbols are renamed
after machine-code generation, and this is why objcopy is needed. To work around
this, I suggest to rename the symbols before machine-code generation. This
does not need any further tools.
ocamlopt could be called as follows:
ocamlopt -c module.ml -for-pack
This would already generate a module.o where the symbols are renamed. In
module.cmx, a special flag would be included indicating that this happened.
Later, when
ocamlopt -pack ...
is called, only these specially prepared modules are accepted. Conversely, it is
forbidden to use these modules for anything else.
I hope that this change helps that -pack is widely adopted. I don't see any
other way to handle name clashes in an intelligent way. You know that there are
some library authors who are unwilling to rename their modules (i.e. the
cooperative social solution), and I also think it is not the task of O'Caml
distributions to make pressure on the authors in this respect. All other
solutions to the problem are somehow dumb, e.g. a registry of module names, or
something like this.
In the hope the cathedral understands what is going on on the bazaar,
Gerd Stolpmann
The text was updated successfully, but these errors were encountered: