lt_cv_sys_cmd_len=8192

[Silvan Scherrer]

if a link command is longer than the max_cmd_len from libtool, libtool tries to execute several commands. this leads to a emxomfld problem. see also: ​http://trac.netlabs.org/libc/ticket/301

[dmik]

I confirm that overriding the maximum cmd length with lt_cv_sys_max_cmd_len=-1 fixes emxomf: type_size: cannot compute size for tag 4 in my case as well (the build of gio DLL in glib). The only change this setting does is set max_cmd_len to -1 in the generated libtool instead of 8192 as it normally is on OS/2.

We should check the algorithm used by libtool to split the command line when its greater than max_cmd_len (when it's not -1) to see why it breaks our emxomfld.

[dmik]

I think I now know exactly what is going on there. When max_cmd_len is not -1, libtool does the following: it gathers as much .o files as possible until the length of the resulting command line reaches the given number and then combines these .o files into a single intermediate .o file using ld.exe. However, ld.exe (part of the EMX toolchain AFAIR) is known to be broken since long and in this particular case it produces the output .o file which is corrupt.

I see three possible solutions:

1. Make lt_cv_sys_max_cmd_len always set to -1 on OS/2. This will not involve ld.exe invocation and, given that sh.exe is used as a shell, it will (almost) always work since sh.exe has a very huge limit on the command line length (up to the limit of DosExecPgm? which is about 32 KB IIRC, or may be even 64 KB). This is the easiest option.

2. Use ar.exe (emxomfar.exe) instead of ld for such a job (ar is known to work well). This requires some tailoring of libtool. Not as fast as #1 but looks more clever to me (since it is guaranteed to never hit any command line limit).

3. Fix ld.exe. The hardest option and I don't think we want to do it within this ticket.

I will try #2 for now and will fallback to #1 if it turns out to be too complex.

[dmik]

libtool calls ld.exe with the -r option (which merges object files to produce another object), to be exact.

And I also forgot to mention another option which I discussed with Silvan:

4. Use @response.lst files with gcc.exe. It's more native to OS/2 and requires no intermediate file creation. This is the best choice (besides and along with fixing ld.exe) but it's harder than #1 or #2. I will try to quickly estimate how hard it is, though, now.

[dmik]

I'm attaching libtool --debug output for reference. These logs are from the making of glib's gio.dll: .log.1 is the session with max_cmd_len=-1, .log.2 — with max_cmd_len=8192. It may be seen there when and how ld/gcc is called.

[dmik]

There is actually support for response files already which is used on Cygwin in native linker mode (quite expected). So I had to do as little as r955 in order to get option 4 working. Tested it in manual mode — works fine (the produced DLL doesn't differ from the one built in max_cmd_len=-1 mode). The next step is to cook the libtool RPM and retest it from the proper install.

The defect of ld.exe itself is tracked in ​http://trac.netlabs.org/libc/ticket/301 for now (it may get a new libc ticket in the future though).

[dmik]

The libtool 2.4.2-8 RPM is released. Please update and test.