New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Name clashes #8395
Comments
Comment author: administrator see also #8356 |
Comment author: @damiendoligez done for otherlibs/bigarray (branch 3.10) 2006-01-27 |
Comment author: @stedolan Here's a list of the current offenders: |
Comment author: @lpw25 I attached a patch from Stephen Dolan that stops marshall_flags from being exported. |
Comment author: @damiendoligez Patch for marshall_flags applied to 4.03 (commit 5dbea03) and trunk (commit 044901b). The rest will wait till 4.04. |
Comment author: @xavierleroy Now that the runtime is clean name-wise, and that several offending "otherlibs" are on their way out (num, str) or are disused (vmthreads), maybe we could declare victory? |
Comment author: @stedolan Re-running the command at the top of https://gist.github.com/stedolan/6115403 indicates that there are now a few more offenders, such as invert_root in compact.c and process_debug_events in byterun/backtrace_prim.c. |
Comment author: @mshinwell @stedolan Could you produce a patch for those? |
Comment author: @mshinwell Consolidating this with another issue so we have a single place to keep track of namespacing problems: the runtime isn't clean yet because of macros and so forth, I suspect: All function in caml C headers are prefixed with caml_. |
Comment author: @stedolan Macros, typedefs and static functions are not an issue. The I've created a pull request (#973) that removes the current offenders, and adds a tool to detect them. |
#973 is merged now, and there are no more un-namespaced symbols exported by |
Original bug ID: 1956
Reporter: administrator
Assigned to: @damiendoligez
Status: acknowledged (set by @damiendoligez on 2007-11-19T18:09:46Z)
Resolution: open
Priority: high
Severity: minor
Category: runtime system and C interface
Related to: #8356 #4164 #4230 #4877 #5254 #6126
Monitored by: "Hendrik Tews"
Bug description
Hello Lars and caml-bugs,
There is a name clash between the libcrypto and libcamlrun on the symbol
create_string. This prevents from linking statically an OCaml program that
uses the ocurl library (bindings to the libcurl, which uses libcrypto), and
I guess that horrible things may happen at runtime with dynamic linking.
Similar issues have been raised recently on the caml-list (concerning
the libsamba, libperl, and graphviz libraries).
Any plan to address these issues?
OCaml is no more faulty than these libraries, but this is not a reason not
to fix the problem :-)
A natural solution would be to prefix all the common names like
create_string or get_string. To keep the compatibility with existing C
code that uses Caml C headers, there could be two versions of these
headers (the compatibility header would #DEFINE create_string as
ocaml_create_string and so on).
Alain
File attachments
The text was updated successfully, but these errors were encountered: