Re: [cc65] Chicken and Egg Problem (?)

Hi Uz,

>> No feedback at all on my posting above ?
>
> I'm sorry. I have been busy...

I was just wondering because the other threads went on...

> ...and it's difficult for me to comment on that
> without doing some lengthy checks. I have never seen a framework that loads
> main() from a library and I would need to check the standard to see if this is
> legal or triggers undefined behaviour.

I didn't find anything - but after all that doesn't mean too much ;-)

> And to understand, why there is no
> other way, than to have main() in the library, I would have to study Contiki
> to some extent.

Surely there are other ways. It's just the way it currently is. I
don't have issues at all finding workarounds - you even pointed out
one. I was just trying to discuss if I have to.

>> Just imagine forgetting or misspelling main(). Wouldn't you expect the
>> linker (called with -t <target>) to complain about not being able to
>> resolve the symbol '_main' ?
>
> It's not worse than what happened before the change. If someone forgot to link
> in the startup code (which in my eyes is a lot easier than having a typo in
> "main"), he got exactly the error messages you're complaining about. This is
> now fixed.

I can follow your reasoning.

> Yes, you're right, there are still things that could be improved.
> It's all a question of importance. For now, I can live with the described
> behaviour, because I know it was worse before.

I understand your perspective.

> Breaking Contiki is more important to me, but currently I cannot tell how to
> fix that problem most easily.

Never mind. I'll do :-)

> But I will definitely not go and start making
> changes to the linker before the changes to the compiler have been debugged
> and are stable to some extent.

I see.

Best, Oliver
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.