Opened 10 years ago
Closed 10 years ago
#49 closed defect (fixed)
lt_cv_sys_cmd_len=8192
Reported by: | Silvan Scherrer | Owned by: | dmik |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | libtool | Version: | |
Severity: | Keywords: | ||
Cc: |
Description
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
Attachments (1)
Change History (8)
comment:1 by , 10 years ago
comment:2 by , 10 years ago
Owner: | set to |
---|---|
Status: | new → assigned |
comment:3 by , 10 years ago
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:
- Make
lt_cv_sys_max_cmd_len
always set to -1 on OS/2. This will not involveld.exe
invocation and, given thatsh.exe
is used as a shell, it will (almost) always work sincesh.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.
- Use
ar.exe
(emxomfar.exe
) instead ofld
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).
- 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.
comment:4 by , 10 years ago
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:
- Use
@response.lst
files withgcc.exe
. It's more native to OS/2 and requires no intermediate file creation. This is the best choice (besides and along with fixingld.exe
) but it's harder than #1 or #2. I will try to quickly estimate how hard it is, though, now.
comment:5 by , 10 years ago
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.
by , 10 years ago
Attachment: | libtool-debug.zip added |
---|
comment:6 by , 10 years ago
There is actually support for response files 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 now.
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).
comment:7 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
The libtool 2.4.2-8 RPM is released. Please update and test.
I confirm that overriding the maximum cmd length with
lt_cv_sys_max_cmd_len=-1
fixesemxomf: 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 setmax_cmd_len
to -1 in the generatedlibtool
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.