emxomf: type_size: cannot compute size for tag 4

[KO Myung-Hun]

Hi/2.

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

[bird]

Not enough input to fix anything here.

[Silvan Scherrer]

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

[Silvan Scherrer]

I uploaded the .a zipped to ​ftp://ftp.netlabs.org/pub/qtapps/temp/zip.zip

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

[Silvan Scherrer]

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

[KO Myung-Hun]

How about setting lt_cv_sys_max_cmd_len=-1 before configure ?

For examples,

lt_cv_sys_max_cmd_len=-1 \
  ./configure

[Silvan Scherrer]

this configure setting seems to help.

[dmik]

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

[dmik]

Knut, I think ld.exe (involved by libtool) is simply broken (and it is know 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).

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

[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).

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

[Silvan Scherrer]

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.

[KO Myung-Hun]

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.

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

[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