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

ocamlc -c and ocamlopt -c differ for C files #7678

Closed
vicuna opened this issue Nov 22, 2017 · 6 comments · Fixed by #8631
Closed

ocamlc -c and ocamlopt -c differ for C files #7678

vicuna opened this issue Nov 22, 2017 · 6 comments · Fixed by #8631
Assignees
Milestone

Comments

@vicuna
Copy link

vicuna commented Nov 22, 2017

Original bug ID: 7678
Reporter: @dbuenzli
Status: acknowledged (set by @xavierleroy on 2017-11-26T16:21:45Z)
Resolution: open
Priority: normal
Severity: minor
OS: Linux
Version: 4.06.0
Target version: 4.07.0+dev/beta2/rc1/rc2
Category: compiler driver
Monitored by: @gasche @yallop @dra27 @dbuenzli

Bug description

I don't know if that is intended but it seems that -fPIC is not passed in the second case.

This makes ocamlmklib to fail to produce libraries for C object files generated with ocamlopt -c.

Steps to reproduce

Our C file

cat a.c
#include <stdlib.h>
char *get_editor (void) { return getenv("EDITOR"); }

Here all is well

ocamlc -verbose -c a.c

  • gcc -std=gnu99 -O2 -fno-strict-aliasing -fwrapv -fno-builtin-memcmp -fPIC -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -I'/home/dbuenzli/.opam/default/lib/ocaml' 'a.c'

ocamlmklib a.o

Here we fail note the missing -fPIC w.r.t above invocation

ocamlopt -verbose -c a.c

  • gcc -std=gnu99 -O2 -fno-strict-aliasing -fwrapv -fno-builtin-memcmp -D_FILE_OFFSET_BITS=64 -D_REENTRANT -c -I'/home/dbuenzli/.opam/default/lib/ocaml' 'a.c'

Additional information

cat /etc/system-release
CentOS Linux release 7.4.1708 (Core)

ocamlc -config
ocamlc -config
version: 4.06.0
standard_library_default: /home/dbuenzli/.opam/default/lib/ocaml
standard_library: /home/dbuenzli/.opam/default/lib/ocaml
standard_runtime: /home/dbuenzli/.opam/default/bin/ocamlrun
ccomp_type: cc
c_compiler: gcc
ocamlc_cflags: -std=gnu99 -O2 -fno-strict-aliasing -fwrapv -fno-builtin-memcmp -fPIC
ocamlc_cppflags: -D_FILE_OFFSET_BITS=64 -D_REENTRANT
ocamlopt_cflags: -std=gnu99 -O2 -fno-strict-aliasing -fwrapv -fno-builtin-memcmp
ocamlopt_cppflags: -D_FILE_OFFSET_BITS=64 -D_REENTRANT
bytecomp_c_compiler: gcc -std=gnu99 -O2 -fno-strict-aliasing -fwrapv -fno-builtin-memcmp -fPIC -D_FILE_OFFSET_BITS=64 -D_REENTRANT
native_c_compiler: gcc -std=gnu99 -O2 -fno-strict-aliasing -fwrapv -fno-builtin-memcmp -D_FILE_OFFSET_BITS=64 -D_REENTRANT
bytecomp_c_libraries: -lm -ldl -lcurses -lpthread
native_c_libraries: -lm -ldl
native_pack_linker: ld -r -o
ranlib: ranlib
cc_profile: -pg
architecture: amd64
model: default
int_size: 63
word_size: 64
system: linux
asm: as
asm_cfi_supported: true
with_frame_pointers: false
ext_exe:
ext_obj: .o
ext_asm: .s
ext_lib: .a
ext_dll: .so
os_type: Unix
default_executable_name: a.out
systhread_supported: true
host: x86_64-unknown-linux-gnu
target: x86_64-unknown-linux-gnu
profiling: true
flambda: false
spacetime: false
safe_string: false
default_safe_string: true
flat_float_array: true
afl_instrument: false
windows_unicode: false
exec_magic_number: Caml1999X011
cmi_magic_number: Caml1999I022
cmo_magic_number: Caml1999O022
cma_magic_number: Caml1999A022
cmx_magic_number: Caml1999Y022
cmxa_magic_number: Caml1999Z022
ast_impl_magic_number: Caml1999M022
ast_intf_magic_number: Caml1999N022
cmxs_magic_number: Caml1999D022
cmt_magic_number: Caml1999T022

@vicuna
Copy link
Author

vicuna commented Nov 22, 2017

Comment author: @dbuenzli

Forgot to add the failing ocamlmklib but you get the idea:

ocamlmklib a.o
/usr/bin/ld: a.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -fPIC
a.o: error adding symbols: Bad value
collect2: error: ld returned 1 exit status

@vicuna
Copy link
Author

vicuna commented Nov 22, 2017

Comment author: @dbuenzli

Also AFAIK macOS is no affected by this.

@vicuna
Copy link
Author

vicuna commented Nov 26, 2017

Comment author: @xavierleroy

That's not intended and something we need to fix.

What happens currently (I guess) is that ocamlopt uses the C compiler and flags used to compile asmrun/ and ocamlc uses the C compiler and flags used to compile byterun/. One has -fPIC and not the other, but it should not show up this way.

We should also all agree that ocamlc -c and ocamlopt -c should both produce PIC code by default. For me that's clearly a "yes" because they are commonly used to compile Caml-C stub code that ends up in DLLs.

@vicuna vicuna added this to the 4.07.0 milestone Mar 14, 2019
@vicuna vicuna added the bug label Mar 20, 2019
@dbuenzli
Copy link
Contributor

dbuenzli commented Apr 19, 2019

I was hoping maybe the switch to autoconf would have resolved that but it doesn't seem to be the case in 4.08+beta3.

Is there anything I can do so that we resolve this discrepancy for the next release (4.09) ?

I'm not sure exactly which bit should be poked but configureing with --with-pic which triggers this logic on common_cflags actually makes the discrepancy go away and everything seems to compile fine (except ocamlc then puts -fPIC twice on the command line...).

So is it a matter of simply adding $sharedlib_cflags on this line. Or rather remove $sharedlib_cflags from that line and let the with-pic option do that and default to have it enabled (I'm not sure about the effect on asflags though) ?

@dra27
Copy link
Member

dra27 commented Apr 20, 2019

In general, the autoconf work aimed to produce identical output files to the build system, so it's worth pinging issues as a reminder - in some ways, fixing this would have been regarded as a regression!

@shindere
Copy link
Contributor

shindere commented Feb 18, 2020 via email

@damiendoligez damiendoligez modified the milestones: 4.10, 4.11 Feb 20, 2020
dra27 added a commit that referenced this issue Apr 21, 2020
Use same cflags and cppflags for ocamlc -c and ocamlopt -c (#7678)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants