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

Dynlink wrong symbol #6950

vicuna opened this issue Aug 3, 2015 · 1 comment


Copy link

commented Aug 3, 2015

Original bug ID: 6950
Reporter: tianyicui
Assigned to: @mshinwell
Status: resolved (set by @mshinwell on 2017-06-09T17:01:10Z)
Resolution: duplicate
Priority: normal
Severity: minor
Platform: Linux
Version: 4.02.3
Target version: later
Category: otherlibs
Related to: #4229 #4231 #4839 #6462 #6957
Monitored by: @hhugo @gasche @rixed @diml @hcarty

Bug description

I found a bug in dynlink, which sometimes resolve symbols incorrectly.

Steps to reproduce

$ cat
let () = Printf.printf "%s\n%s\n"
$ cat
let foo = "foo"
let bar = "bar"
$ cat
let () =
Dynlink.loadfile Sys.argv.(1)
$ cat

rm -f *.{cmi,cmx,o,cmxs}

-I +compiler-libs ocamlcommon.cmxa dynlink.cmxa -linkall -o loader.exe

-I .
-shared -o b.cmxs

./loader.exe b.cmxs
$ sh

Additional information

Note that if I didn't link ocamlcommon.cmxa this bug won't be reproduced. This because both ocamlcommon.cmxa and b.cmxs contain the symbol camlConfig__1 and dynlink/dlopen somehow chose to resolve to the one linked into loader.exe.

On Linux with glibc, this can be fixed by adding RTLD_DEEPBIND to the dlopen call. Not sure if this is the right fix though.

Possibly related (or duplicate) issues:



This comment has been minimized.

Copy link

commented Jun 9, 2017

Comment author: @mshinwell

This will be fixed by #1063

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
2 participants
You can’t perform that action at this time.