Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#301 closed defect (invalid)

emxomf: type_size: cannot compute size for tag 4

Reported by: komh Owned by:
Priority: normal Milestone: libc-0.7
Component: emx Version: 0.6.5
Severity: normal Keywords:
Cc:

Description

Hi/2.

When I make a debug build of qt4 plugin of VLC, emxomf failed to due to the subject.

Change History (16)

comment:1 Changed 5 years ago by bird

  • Resolution set to needsmoreinput
  • Status changed from new to closed

Not enough input to fix anything here.

comment:2 Changed 5 years ago by diver

  • Resolution needsmoreinput deleted
  • Status changed from closed to reopened

I see exactly the same error when I build gettext. What info would you need? I could send or upload the falling .a file.

comment:3 Changed 5 years ago by diver

comment:4 Changed 5 years ago by bird

Diver says he is is using gcc 4.7.3. I assume that is the case for komh too. So, this is really something the gcc porter should care about, since kLibC and thereby emx is still shipping the ancient gcc 3.3.5, not 4.7.3.

A workaround would be to not compile the problematic code with debug info (-s option with gcc/g++) enabled.

comment:5 Changed 5 years ago by diver

I tried that and then got: emxomf: write_seg: Invalid relocation type (0x02)

comment:6 Changed 5 years ago by komh

How about setting lt_cv_sys_max_cmd_len=-1 before configure ?

For examples,

lt_cv_sys_max_cmd_len=-1 \
  ./configure

comment:7 Changed 5 years ago by diver

this configure setting seems to help.

comment:8 Changed 5 years ago by dmik

http://trac.netlabs.org/ports/ticket/49 is dedicated to the max_cmd_len problem in libtool.

comment:9 Changed 5 years ago by dmik

Knut, I think ld.exe (involved by libtool in this case) is simply broken (and it is known to fail in some other cases). Please check http://trac.netlabs.org/ports/ticket/49#comment:3. Do you remember ld internals? How hard is it to bring ld.exe up-to-date (which implies this particular fix for it)?

Last edited 5 years ago by dmik (previous) (diff)

comment:10 Changed 5 years ago by bird

So, if I read dmik's analysis correctly the problem is that ld is used to create intermediate objects files to shorten the command line, that linking several relocatable objects into a single relocatable object. That scenario rings a bell, and I think linking to a relocatable output was known to be broken, or something...

Anyway, if the problem is just the command line length, a much more efficient solution to the issue would be to use a response file. The first call made from main() in ld.c is to check for response files.

Regarding fixing ld, we need to fix the binutil ld so it does its job correctly instead. The one I ship is known to be unusable. I've no idea how well the ld from a more recent binutils port would works.

comment:11 Changed 5 years ago by dmik

Yes, you get me right, ld is called with -r there. Yes we were thinking about the response file option, I forgot to mention it (did it now).

comment:12 Changed 5 years ago by dmik

The libtool fix was rather easy: http://trac.netlabs.org/ports/ticket/49#comment:6. No lt_cv_sys_max_cmd_len=-1 workaround is necessary now.

I think the ld.exe problems deserve their own tickets and this one may be closed.

comment:13 Changed 5 years ago by diver

  • Resolution set to invalid
  • Status changed from reopened to closed

Yes I also think that ld needs a separate ticket. But imho this ticket would belong to the ports section. As Knut stated, we should fix the binutils ld.

And as I reopened the ticket, I also close it again and mark it as invalid, as it had nothing to do with libc :) Thanks for all who worked on that.

comment:14 Changed 5 years ago by komh

ld relates to this problem. But ld itself seems not to be a problem. Because both .exe and .dll which ld built with relocatable objects generated by ld -r work well.

BTW why do you think this has nothing to do with libc ? A solution of libtool is to avoid this. A problem is still somewhere in binutils/emx/gcc although this problem hardly happens except libtool.

Anyway there is no need to reopen this.

comment:15 Changed 5 years ago by dmik

I think that until we have binutils in our ports repo (and move all Knut's patches from here to there), the ld tickets belong here.

comment:16 Changed 5 years ago by psmedley

binutils is now in ports repo. afaik the ld in there works the same as knut's binutils 2.13 that's in the libc repo

Note: See TracTickets for help on using tickets.