caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Hans Ole Rafaelsen <hans@simula.no>
To: caml-list@inria.fr
Subject: Linking fails for native version of 3.11 under MinGW when using large number of modules
Date: Sun, 24 May 2009 16:23:19 +0200	[thread overview]
Message-ID: <4A195857.9050306@simula.no> (raw)

[-- Attachment #1: Type: text/plain, Size: 3859 bytes --]

Hi,

I have problems linking my application with MinGW version of OCaml 3.11. 
I'm using GODI for my installation, thus my build environment is cygwin. 
I'm not sure if this is a cygwin, mingw, godi, findlib or ocaml problem. 
I'm using the cygwin version 1.7 under 32bit WinXP.

In a simplified example, during the link stage, the linker fails with 
this message:

** Fatal error: Error during linking

File "caml_startup", line 1, characters 0-1:
Error: Error during linking
Exit code 2 while executing this command:
  ocamlfind ocamlopt -g -linkpkg -package json-wheel -package str 
-package extlib -package netsys -package rpc -package unix -package 
netplex -package xstr -package ocamlgraph -package bitstring -package 
num -package pop -package netstring src/foo/bar100.cmx 
src/foo/bar101.cmx src/foo/bar102.cmx src/foo/bar103.cmx 
src/foo/bar104.cmx src/foo/bar105.cmx src/foo/bar106.cmx 
src/foo/bar107.cmx src/foo/bar108.cmx src/foo/bar109.cmx 
src/foo/bar110.cmx src/foo/bar111.cmx src/foo/bar112.cmx 
src/foo/bar113.cmx src/foo/bar114.cmx src/foo/bar115.cmx 
src/tests/foo.cmx -o src/tests/foo.native

test/foo.ml
is just:

open Bar100
...
open Bar115

let () =
  Printf.printf "foo\n";
  flush stdout


And the baxXXX.ml files are just:
$ cat src/foo/bar100.ml
let () = ()

By reducing the number of bars opened in foo.ml to Bar114 as the last, 
it builds and produces the following working file:

$ ./_build/src/tests/foo.native
foo

$ file _build/src/tests/foo.native
_build/src/tests/foo.native: PE32 executable for MS Windows (console) 
Intel 80386 32-bit

By removing some of the packages from the link stage, it builds easily 
with more BarXXX modules included. Some of the packages seems to high a 
higher impact than others. By instead opening BXXX modules, which do the 
same as BarXXX modules, but have shorter names, I'm able to include a 
few more, when linking against the same packages. Including up to B116 
works, and it fails when trying B117. So it looks like it is impacted of 
both the number of symbols and their length. By not linking against any 
packages, I'm able to include a large number of my own modules (tested 
with long names), so it does not seem to be the length of the command 
line arguments that is causing the problems.

Some info about the various versions of programs being used:

$ gcc -v
Reading specs from /bin/../lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with: 
/managed/gcc-build/final-v3-bootstrap/gcc-3.4.4-999/configure --verbose 
--program-suffix=-3 --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc 
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man 
--infodir=/usr/share/info 
--enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls 
--without-included-gettext --enable-version-specific-runtime-libs 
--without-x --enable-libgcj --disable-java-awt --with-system-zlib 
--enable-interpreter --disable-libgcj-debug --enable-threads=posix 
--enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions 
--enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
$ ld -v
GNU ld (GNU Binutils) 2.18.50.20080625

$ ocamlopt -v
The Objective Caml native-code compiler, version 3.11.0
Standard library directory: C:/cygwin/work/godi-3.11-mingw/lib/ocaml/std-lib

$ file `which ocamlopt`
/work/godi-3.11-mingw/bin/ocamlopt: PE32 executable for MS Windows 
(console) Intel 80386 32-bit

Any idea of what is the problem? Is there some options that will enable 
more info of what fails during linking, than just the "** Fatal error: 
Error during linking" message? Any suggestions for possible workarounds?

Under Linux linking these works just fine. Also byte version seems to 
link fine under MinGW.

Attached is the files used to demonstrate the problem.

Regards,

Hans Ole Rafaelsen


[-- Attachment #2: link_bug.tgz --]
[-- Type: application/x-compressed-tar, Size: 5290 bytes --]

             reply	other threads:[~2009-05-24 14:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-24 14:23 Hans Ole Rafaelsen [this message]
2009-05-24 18:44 ` [Caml-list] " Matthieu Dubuget
2009-05-24 19:03   ` Hans Ole Rafaelsen
2009-05-24 19:58     ` Matthieu Dubuget
2009-05-24 20:15       ` Hans Ole Rafaelsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4A195857.9050306@simula.no \
    --to=hans@simula.no \
    --cc=caml-list@inria.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).