C bindings problem on MacOSX #29

Closed
vbmithr opened this Issue Mar 20, 2013 · 15 comments

Comments

Projects
None yet
4 participants
Contributor

vbmithr commented Mar 20, 2013

Always git://github.com/vbmithr/ocaml-tuntap:

Analysing Tuntap
  Tuntap has mtime 1363801395.000000
  Tuntap has interface (mtime=1363801395.000000)
  [CMD]: /usr/local/bin/ocamldep.opt -I lib -I dist/build/autogen -modules lib/tuntap.ml
  Tuntap depends on Printf,String,Unix
  Tuntap internally depends on 
  [CMD]: /usr/bin/gcc -MM lib/tuntap_stubs.c
[1 of 3] Compiling C tuntap_stubs.c                
  [CMD]: cc -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -O3 -I lib -I /usr/local/lib/ocaml -I dist/build/autogen -o d
ist/build/lib-tuntap/tuntap_stubs.c.o -c lib/tuntap_stubs.c
[2 of 3] Intfing Tuntap                        
  [CMD]: /usr/local/bin/ocamlc.opt -I dist/build/lib-tuntap -I dist/build/autogen -I lib -bin-annot -o dist/build/lib-tuntap/tunta
p.cmi -c lib/tuntap.mli
[3 of 3] Compiling Tuntap                        
  [CMD]: /usr/local/bin/ocamlopt.opt -I dist/build/lib-tuntap -I dist/build/autogen -I lib -bin-annot -o dist/build/lib-tuntap/tun
tap.cmx -c lib/tuntap.ml
  [CMD]: /usr/local/bin/ocamlc.opt -I dist/build/lib-tuntap -I dist/build/autogen -I lib -bin-annot -o dist/build/lib-tuntap/tunta
p.cmo -c lib/tuntap.ml
clang: warning: argument unused during compilation: '-fno-defer-pop'
schedule finished: #processes=3 max_concurrency=2
  compilation order: Tuntap
  self deps: 
package deps: []
  [CMD]: /usr/bin/gcc -shared -o dist/build/lib-tuntap/dllstubs_tuntap.so dist/build/lib-tuntap/tuntap_stubs.c.o
Undefined symbols for architecture x86_64:
  "_caml_alloc_string", referenced from:
      _get_mac_addr in tuntap_stubs.c.o
  "_caml_local_roots", referenced from:
      _get_mac_addr in tuntap_stubs.c.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

On a MacOSX Mountain Lion with OCaml 4.00.1, opam install via brew, obuild last git version

Contributor

vbmithr commented Mar 22, 2013

Probably due to the missing -fPIC option on the compilation of the stubs.

Contributor

avsm commented Mar 22, 2013

Make sure this matches the -fPIC option to OCaml --- normally 64-bit platforms require it, but it's probably off by default on 32-bit

Owner

vincenthz commented Mar 25, 2013

It could that you can't reuse the same .o file in native/bytecomp. my native c compiler doesn't have any -fPIC option, whereas the bytecomp_c_compiler does. (ocamlc -config)

Contributor

vbmithr commented Mar 25, 2013

-fPIC does not solve the problem. It fails on that:

  [CMD]: cc -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -O3 -I lib -I /usr/local/lib/ocaml -I dist/build/autogen -o dist/build/lib-tuntap/tuntap_stubs.c.o -c lib/tuntap_stubs.c
...
[CMD]: /usr/bin/gcc -shared -o dist/build/lib-tuntap/dllstubs_tuntap.so dist/build/lib-tuntap/tuntap_stubs.c.o
Undefined symbols for architecture x86_64:
  "_caml_alloc_string", referenced from:
      _get_mac_addr in tuntap_stubs.c.o
  "_caml_local_roots", referenced from:
      _get_mac_addr in tuntap_stubs.c.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status

As you can see, OCaml is not involved at all here (apparently).

Contributor

avsm commented Mar 25, 2013

Try changing the link order on the command line for -lasmrun

On 25 Mar 2013, at 16:54, Vincent Bernardoff notifications@github.com wrote:

-fPIC does not solve the problem. It fails on that:

[CMD]: cc -fno-defer-pop -Wall -D_FILE_OFFSET_BITS=64 -D_REENTRANT -O3 -I lib -I /usr/local/lib/ocaml -I dist/build/autogen -o dist/build/lib-tuntap/tuntap_stubs.c.o -c lib/tuntap_stubs.c
...
[CMD]: /usr/bin/gcc -shared -o dist/build/lib-tuntap/dllstubs_tuntap.so dist/build/lib-tuntap/tuntap_stubs.c.o
Undefined symbols for architecture x86_64:
"_caml_alloc_string", referenced from:
_get_mac_addr in tuntap_stubs.c.o
"_caml_local_roots", referenced from:
_get_mac_addr in tuntap_stubs.c.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
As you can see, OCaml is not involved at all here (apparently).


Reply to this email directly or view it on GitHub.

Contributor

vbmithr commented Mar 26, 2013

ocamlmklib do that on mac:

MacBook-Pro-van-Harrie:_build vincent$ /usr/local/bin/ocamlmklib -o lib/tuntap_stubs lib/tuntap_stubs.o -v
+ cc -bundle -flat_namespace -undefined suppress -o lib/dlltuntap_stubs.so lib/tuntap_stubs.o    
+ ar rc lib/libtuntap_stubs.a  lib/tuntap_stubs.o; ranlib lib/libtuntap_stubs.a

I think the right command is system-dependant, maybe obuild should use ocamlmklib instead what do you think Vincent ?

Owner

vincenthz commented Mar 28, 2013

unfortunately, ocamlmklib has few problems, one being that it doesn't allow to put the output where you want. the -o option is not passed to gcc properly. Also it has shell escaping problem but that i guess that's just a minor issue here.

The right thing is probably to disable .so building on platform=mac, just like what ocamlmklib is doing in custom mode anyway.

Contributor

avsm commented Mar 28, 2013

What's the ocamlmklib output problem? It munges the output extension to add the right suffix (dll, for example), but it looks like it passes the option to gcc from reading the source.

On 28 Mar 2013, at 05:40, Vincent Hanquez notifications@github.com wrote:

unfortunately, ocamlmklib has few problems, one being that it doesn't allow to put the output where you want. the -o option is not passed to gcc properly. Also it has shell escaping problem but that i guess that's just a minor issue here.


Reply to this email directly or view it on GitHub.

Owner

vincenthz commented Mar 28, 2013

IIRC, it drops the path.

Contributor

avsm commented Mar 28, 2013

Can't repro this on the Mac with trunk:

$ cd _build
$ /Users/avsm/.opam/4.01.0dev+trunk/bin/ocamlmklib -o lib/tuntap_stubs lib/tuntap_stubs.o
$ ls -la lib/
total 248
drwxr-xr-x  20 avsm  staff    680 28 Mar 09:37 .
drwxr-xr-x  12 avsm  staff    408 28 Mar 09:37 ..
-rwxr-xr-x   1 avsm  staff   9880 28 Mar 09:37 dlltuntap_stubs.so
-rw-r--r--   1 avsm  staff   4904 28 Mar 09:37 libtuntap_stubs.a
-rw-r--r--   1 avsm  staff     99 28 Mar 09:37 libtuntap_stubs.clib
-rw-r--r--   1 avsm  staff   7824 28 Mar 09:37 tuntap.a
-rw-r--r--   1 avsm  staff   7959 28 Mar 09:37 tuntap.cma
-rw-r--r--   1 avsm  staff   1340 28 Mar 09:37 tuntap.cmi

Will try on a 4.00.1 compiler; rebuilding now.

Owner

vincenthz commented Mar 28, 2013

can't remember exactly, i need to try again, but it has to do with the destination path being different than the source path. try outputing with -o /tmp/abc.

Contributor

avsm commented Mar 28, 2013

Can't figure this out on either Linux or MacOS:

On Linux:

$ /home/avsm/.opam/4.00.1+bin-doc/bin/ocamlmklib -v -o /tmp/x/tuntap_stubs lib/tuntap_stubs.o                                                             
+ gcc -shared -o /tmp/x/dlltuntap_stubs.so lib/tuntap_stubs.o    
+ ar rc /tmp/x/libtuntap_stubs.a  lib/tuntap_stubs.o; ranlib /tmp/x/libtuntap_stubs.a
$ ls -la /tmp//x/
total 176
drwxr-xr-x 2 avsm avsm   4096 Mar 28 10:06 .
drwxrwxrwt 7 root root 151552 Mar 28 10:06 ..
-rwxr-xr-x 1 avsm avsm  11099 Mar 28 10:06 dlltuntap_stubs.so
-rw-r--r-- 1 avsm avsm   7284 Mar 28 10:06 libtuntap_stubs.a

And the same on MacOS but with different linker strings. The source code appears to to preserves the output directory... I wonder if you were running into the shell escaping issue and therefore getting truncated -o from that?

Contributor

vbmithr commented Apr 15, 2013

So, where are we on this issue ? I want to fix it, but I have to know what to do. There is two possibilities I see:

  • Use ocamlmklib if it works. Even if it works, we might want to not use it since we can reproduce its behaviour, and in the context of a fast/lib-oriented build system, relying on external tools might not be desirable.
  • The other possibility is then to replicate its behaviour. What I see feasible is:
  • Look in ocamlc -where/Makefile.config and import those variables in obuild, and use the MKDLL variable. ocamlmkfile uses a module Myocamlbuild_config that contains this information, which is generated by ocaml’s configure script.
  • The last possibility is to hardcode the correct options in obuild, one per architecture.

Please tell me what you think about all this!

Contributor

UnixJunkie commented Aug 23, 2016

@vbmithr Hi, if you want this to be fixed, a way to reproduce the problem is welcome.
Your project doesn't have an obuild file anymore ...

Contributor

vbmithr commented Aug 23, 2016

Haven't used this for 3 years, closing.

@vbmithr vbmithr closed this Aug 23, 2016

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