Sorry reyalp, I have not enough time in this moment, so only a short comment.
I tested many options for two month ago (rev.1032 to 1033) to find the reason for return-fail. An easy way for gcc4 was to put $(OPT_OBJS) in core/Makefile to begin of line.
rudi
Thanks, this is very a good clue. I also don't have much time during the week, but this gives me something work on.
A little more on this: Just moving $(OPT_OBJS) to not be the last item is sufficient. Trying the order of things within $(OPT_OBJS) seems like the next step, to narrow it down to the smallest change.
I still don't see why this is happening. It seems too consistent to be just something like value of uninitialized memory being different.
gcc4 is more sensitive to link order than gcc3. It seems possible that the linker could be picking up a different function for something depending on order. My first guess was the ctype functions (isspace/iscntrl etc) seem like they might be related, based on the problem with numeric return and newline, but if this is the case I don't see where.
I thought the fact that iscntrl was always false might be related, but fixing that doesn't change anything. I'll fix that in the trunk anyway, since lua patterns use it.
Core makefile uses
--start-group $^ $(LDLIBS) --end-group
I wasn't able to find good documentation for --start-group and --end-group, but it seem to force the linker to repeatedly scan all the libs to resolve cyclic dependencies. $(LDLIBS) is only -lgcc which doesn't seem like it should have anything relevant.
edit:
good
... script.o console.o
bad
... console.o script.o
edit:
this seems specific to the order of script.o and console.o, putting other .o files later doesn't seem to change whether it works or not.
