Skip to content
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

Closed
vicuna opened this issue Dec 3, 2003 · 11 comments
Closed

Name clashes #8395

vicuna opened this issue Dec 3, 2003 · 11 comments

Comments

@vicuna
Copy link

vicuna commented Dec 3, 2003

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

@vicuna
Copy link
Author

vicuna commented Jan 7, 2004

Comment author: administrator

see also #8356
fixed for byterun and asmrun 2004-01-07 -DD
still needs to be done for otherlibs (?)

@vicuna
Copy link
Author

vicuna commented Jan 27, 2006

Comment author: @damiendoligez

done for otherlibs/bigarray (branch 3.10) 2006-01-27

@vicuna
Copy link
Author

vicuna commented Jul 30, 2013

Comment author: @stedolan

Here's a list of the current offenders:
https://gist.github.com/stedolan/6115403

@vicuna
Copy link
Author

vicuna commented Sep 16, 2013

Comment author: @lpw25

I attached a patch from Stephen Dolan that stops marshall_flags from being exported.

@vicuna
Copy link
Author

vicuna commented Mar 3, 2016

Comment author: @damiendoligez

Patch for marshall_flags applied to 4.03 (commit 5dbea03) and trunk (commit 044901b).

The rest will wait till 4.04.

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

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?

@vicuna
Copy link
Author

vicuna commented Dec 7, 2016

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.

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

Comment author: @mshinwell

@stedolan Could you produce a patch for those?

@vicuna
Copy link
Author

vicuna commented Dec 8, 2016

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_.
This is not the case for typedef nor macros in mlvalues.h.
See mlvalues.h for example:
typedef intnat value;
typedef uintnat header_t;
typedef uintnat mlsize_t;
typedef unsigned int tag_t; /* Actually, an unsigned char */
typedef uintnat color_t;
typedef uintnat mark_t;
#define Is_long(x) (((x) & 1) != 0)
#define Is_block(x) (((x) & 1) == 0)
#define Val_long(x) (((intnat)(x) << 1) + 1)
#define Long_val(x) ((x) >> 1)

@vicuna
Copy link
Author

vicuna commented Dec 14, 2016

Comment author: @stedolan

Macros, typedefs and static functions are not an issue.

The caml_ prefix is only necessary for functions and globals which have external linkage. Things like value can only conflict with code that explicitly does #include <mlvalues.h> and is presumably aware of the OCaml API. Externally-linked symbols like marshall_flags will break other code that defines the same symbol regardless of header files.

I've created a pull request (#973) that removes the current offenders, and adds a tool to detect them.

@stedolan
Copy link
Contributor

#973 is merged now, and there are no more un-namespaced symbols exported by libcamlrun.a or libasmrun.a.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants