Linking fails for native version of 3.11 under MinGW when using large number of modules

Linking fails for native version of 3.11 under MinGW when using large number of modules

[Hans Ole Rafaelsen]

[-- 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 --]

Re: [Caml-list] Linking fails for native version of 3.11 under MinGW when using large number of modules

[Matthieu Dubuget]

Hans Ole Rafaelsen a écrit :
> 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:

Can you check the version of flexlink you are using? I had some problem
when the command line was too long.

I'm not sure what the error message where, though.

Hoping this helps

Salutations

Matt

Re: [Caml-list] Linking fails for native version of 3.11 under MinGW when using large number of modules

[Hans Ole Rafaelsen]

Matthieu Dubuget wrote:
> Hans Ole Rafaelsen a écrit :
>   
>> 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:
>>     
>
> Can you check the version of flexlink you are using? I had some problem
> when the command line was too long.
>
> I'm not sure what the error message where, though.
>
> Hoping this helps
>
> Salutations
>
> Matt
>   

It's version 0.15 (that comes with current version of GODI). There is a 
version 0.17 now, but according to the change log, your fix is already 
in version 0.15. I could give it a try with version 0.17 (if it's just 
to change flexlink without having to recompile the whole installation).

Thanks,

Hans Ole

Re: [Caml-list] Linking fails for native version of 3.11 under MinGW when using large number of modules

[Matthieu Dubuget]

Hans Ole Rafaelsen a écrit :
> Matthieu Dubuget wrote:
>> Hans Ole Rafaelsen a écrit :
>>  
>>> 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.
>>>

Oups. Sorry: I did not read your first post carefully before answering...

Salutations

Matt

Re: [Caml-list] Linking fails for native version of 3.11 under MinGW when using large number of modules

[Hans Ole Rafaelsen]

Matthieu Dubuget wrote:
> Hans Ole Rafaelsen a écrit :
>   
>> Matthieu Dubuget wrote:
>>     
>>> Hans Ole Rafaelsen a écrit :
>>>  
>>>       
>>>> 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.
>>>>
>>>>         
>
> Oups. Sorry: I did not read your first post carefully before answering...
>
> Salutations
>
> Matt
>   
Thanks for the tip anyway. I had forgotten that flexlink is involved and 
might be another suspect. Anyway, I upgraded this to version 0.18, but 
the problem remains.

-- 
Hans Ole