Re: [ECOS] Link error: relocation truncated to fit: R_MIPS_GPREL16 time

["Rosimildo daSilva" <rosimildo at hotmail dot com>]

>From: Bart Veer <bartv@redhat.com>
>Reply-To: bartv@redhat.com
>To: rosimildo@hotmail.com, gthomas@redhat.com
>CC: ecos-discuss@sourceware.cygnus.com
>Subject: Re: [ECOS] Link error: relocation truncated to fit: R_MIPS_GPREL16 
>time
>Date: Tue, 18 Apr 2000 15:44:05 +0100
>
>     <snip>
>
>     Rosimildo> I guess I have found the problem. I do not understand
>     Rosimildo> it yet.
>
>     Rosimildo> After trying many things, I discovered that if the
>     Rosimildo> application code uses the function call "time()", and
>     Rosimildo> it gets linked in, it does trigger the problem.
>
>     Rosimildo> The problem seems to be that the TCP/IP stack has a
>     Rosimildo> global variable called "time". I could not find where
>     Rosimildo> it is instantiated. So, I added it to ?
>     Rosimildo> src/ecos/support.c. It did not solve the problem, got
>     Rosimildo> the same error.
>
>     Rosimildo> Next thing I did was to replace the global variable
>     Rosimildo> "time" to "k_time". It does work if I do that.
>
>     Rosimildo> Now I am totally puzzled. GCC should be able to detect
>     Rosimildo> that one time is code, and the other one is data. Also,
>     Rosimildo> this has worked to all other platforms.
>
>     Rosimildo> I have this workaround, but I still not understand it.
>
>I am not a C language lawyer, but I suspect that having both a global
>variable and a function with the same name is disallowed. Consider
>code such as:
>
>    void* x = (void*) &time;
>
>Should x be given the address of the "time" function or the "time"
>variable?



You are right. I would recommend to change it.



>In the context of the BSD kernel, having a global variable "time" is
>not a problem because the function "time" is in the C library and the
>kernel is not linked with that library. In eCos we do not have that
>separation.
>
>Gary (and other interested parties), could you have a look at the
>TCP/IP stack and see what it is going on here? We may need to think
>about namespace pollution in the stack generally.
>

Thanks guys for assisting me on this issue.

I'll be waiting for the final resolution that you might
consider. Do not rush, I have a workaround for the time being.

Rosimildo.




______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com