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

ocamlrun/libcamlrun_shared fails to link with gcc 10.0 develop version #9144

Closed
Romendakil opened this issue Nov 26, 2019 · 12 comments
Closed

ocamlrun/libcamlrun_shared fails to link with gcc 10.0 develop version #9144

Romendakil opened this issue Nov 26, 2019 · 12 comments

Comments

@Romendakil
Copy link

@Romendakil Romendakil commented Nov 26, 2019

I tested both OCaml 4.02.3 and 4.09.0. For both, linking with gcc 10.0, their development version r278668 svn://gcc.gnu.org/svn/gcc fails (cf. below). This problem was observed both on Debian Linux as well as on MacOSX. I don't know whether this is a regression on the side of the linker of gcc, or the linker has become stricter, and there is some sloppyness in the build/link system of OCaml. I will report this also to gcc.

4.02.3:
gcc -Wl,-no_compact_unwind -o ocamlrun
prims.o libcamlrun.a -lcurses -lpthread
duplicate symbol '_caml_code_fragments_table' in:
libcamlrun.a(backtrace.o)
libcamlrun.a(fix_code.o)
duplicate symbol '_caml_code_fragments_table' in:
libcamlrun.a(backtrace.o)
libcamlrun.a(startup.o)
duplicate symbol '_caml_code_fragments_table' in:
libcamlrun.a(backtrace.o)
libcamlrun.a(ints.o)
duplicate symbol '_caml_code_fragments_table' in:
libcamlrun.a(backtrace.o)
libcamlrun.a(extern.o)
duplicate symbol '_caml_code_fragments_table' in:
libcamlrun.a(backtrace.o)
libcamlrun.a(intern.o)
duplicate symbol '_caml_code_fragments_table' in:
libcamlrun.a(backtrace.o)
libcamlrun.a(meta.o)
duplicate symbol '_caml_code_fragments_table' in:
libcamlrun.a(backtrace.o)
libcamlrun.a(debugger.o)
ld: 7 duplicate symbols for architecture x86_64
collect2: error: ld returned 1 exit status

4.09.0:
gcc -shared -flat_namespace -undefined suppress -Wl,-no_compact_unwind -o libcamlrun_shared.so interp_bpic.o misc_bpic.o stacks_bpic.o fix_code_bpic.o startup_aux_bpic.o startup_byt_bpic.o freelist_bpic.o major_gc_bpic.o minor_gc_bpic.o memory_bpic.o alloc_bpic.o roots_byt_bpic.o globroots_bpic.o fail_byt_bpic.o signals_bpic.o signals_byt_bpic.o printexc_bpic.o backtrace_byt_bpic.o backtrace_bpic.o compare_bpic.o ints_bpic.o floats_bpic.o str_bpic.o array_bpic.o io_bpic.o extern_bpic.o intern_bpic.o hash_bpic.o sys_bpic.o meta_bpic.o parsing_bpic.o gc_ctrl_bpic.o md5_bpic.o obj_bpic.o lexing_bpic.o callback_bpic.o debugger_bpic.o weak_bpic.o compact_bpic.o finalise_bpic.o custom_bpic.o dynlink_bpic.o spacetime_byt_bpic.o afl_bpic.o unix_bpic.o bigarray_bpic.o main_bpic.o -lm -lpthread
duplicate symbol '_caml_debug_info' in:
backtrace_byt_bpic.o
backtrace_bpic.o
ld: 1 duplicate symbol for architecture x86_64
collect2: error: ld returned 1 exit status

@Romendakil

This comment has been minimized.

Copy link
Author

@Romendakil Romendakil commented Nov 26, 2019

@mshinwell

This comment has been minimized.

Copy link
Contributor

@mshinwell mshinwell commented Nov 26, 2019

If you add "extern" at the start of line 47, runtime/backtrace_byt.c (before "struct ext_table caml_debug_info;"), on the 4.09 branch does it still fail?

@Romendakil

This comment has been minimized.

Copy link
Author

@Romendakil Romendakil commented Nov 26, 2019

It manages to get ahead a whole lot further, but then fails with a similar issue when linking libasmrun_shared.so
duplicate symbol '_caml_atom_table' in:
startup_aux_npic.o
startup_nat_npic.o
ld: 1 duplicate symbol for architecture x86_64

@mshinwell

This comment has been minimized.

Copy link
Contributor

@mshinwell mshinwell commented Nov 26, 2019

On line 47 (again!) of runtime/startup_nat.c, change CAMLexport to extern. Does that fix it?

@Romendakil

This comment has been minimized.

Copy link
Author

@Romendakil Romendakil commented Nov 26, 2019

Yes, then compilation works. When running the testsuite, I get some failures, but they might be unrelated:
Summary:
2178 tests passed
32 tests skipped
280 tests failed
108 tests not started (parent test skipped or failed)
Richard Biener from gcc commented (and closed by report as invalid) with the remark:
"Try -fcommon, it's default recently was swapped to -fno-common."
I guess, 'it' here refers to OCaml (resp. the OCaml flags / build system)?

@mshinwell

This comment has been minimized.

Copy link
Contributor

@mshinwell mshinwell commented Nov 26, 2019

Can you provide some of the output from the testsuite failures? It's possible they are link-time failures as well, perhaps?

@Romendakil

This comment has been minimized.

Copy link
Author

@Romendakil Romendakil commented Nov 26, 2019

Yes, I could. How do you comment the remark from the gcc team: did you change your default, or did gcc change it's default?

@mshinwell

This comment has been minimized.

Copy link
Contributor

@mshinwell mshinwell commented Nov 26, 2019

I don't think we should be relying on the behaviour of gcc as to -fcommon. We can modify the OCaml sources to fix this.

@xavierleroy

This comment has been minimized.

Copy link
Contributor

@xavierleroy xavierleroy commented Nov 26, 2019

"Try -fcommon, it's default recently was swapped to -fno-common."
I guess, 'it' here refers to OCaml (resp. the OCaml flags / build system)?

I think "it" refers to gcc. This change of default in gcc is going to break a tremendous amount of C code...

@Romendakil

This comment has been minimized.

Copy link
Author

@Romendakil Romendakil commented Nov 26, 2019

Yes, indeed, here it is, a quite interesting discussion:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
The change was made in gcc trunk on Nov 20, 2019:
2019-11-20 Wilco Dijkstra wdijkstr@arm.com

    PR85678
    * common.opt (fcommon): Change init to 1.
    * doc/invoke.texi (-fcommon): Update documentation.
@jhjourdan

This comment has been minimized.

Copy link
Contributor

@jhjourdan jhjourdan commented Nov 27, 2019

On line 47 (again!) of runtime/startup_nat.c, change CAMLexport to extern. Does that fix it?

That one should be fixed when #9128 will be merged.

xavierleroy added a commit to xavierleroy/ocaml that referenced this issue Dec 12, 2019
So that problems with multiple definitions of global C variables
are detected early during development (see ocaml#9144 and ocaml#9176 for examples).
@xavierleroy

This comment has been minimized.

Copy link
Contributor

@xavierleroy xavierleroy commented Dec 12, 2019

This is fixed in commit 53327d7 and should not happen again, because we'll compile with -fno-common from now on.

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

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.