Page 1 of 1
looking for localtime_r() or gmtime_r()
Posted: Fri Sep 12, 2014 11:35 am
by heineckenb
Compiling into SBL2E and running out of space. If I #include <time.h> I get almost 1K bytes ram, and it exceeds the available ram space. So instead of the #include, I did a local struct definition of tm, and a local function prototype for localtime_r, and tried to build it. I get an error "undefined reference to localtime_r(long const *, tm *)" from the linker.
Why can't it find it? It's in libc.a.
If I change SBL2E.ld to make the linker think it has more ram, and do the #include instead of the local definitions, it compiles and links just fine (won't run, naturally, but that's not the point.) It finds localtime_r in libc.a, as it ought.
So why can't the linker find it without <time.h>?
Re: looking for localtime_r() or gmtime_r()
Posted: Fri Sep 12, 2014 10:13 pm
by pbreed
Probable a C/C++ linker problem...
The time stuff is not in the SBL2E.
Your best bet is to use the functions in nburn\includE_sc\nbtime.h
Paul
Re: looking for localtime_r() or gmtime_r()
Posted: Sun Sep 14, 2014 7:50 am
by heineckenb
>>The time stuff is not in the SBL2E.
On the contrary, it's all there, every bit of it, at least in the version I have. Like I said, if I arbitrarily increase the available ram space for the linker, it links just fine--if I #include <time.h>.
If I don't include time.h, but just provide the definition of the tm struct, and a prototype of the localtime (or gmtime, or localtime_r, or gmtime_r) function[s], it compiles fine, but then the linker cannot find localtime (or...) in any of the libraries it searches--and libc.a is searched, because it extracts other routines from there.
Re: looking for localtime_r() or gmtime_r()
Posted: Mon Sep 15, 2014 8:12 am
by pbreed
The system links in the whole libc...
Its rather large and inapproriate for a device with 32K or RAM.
We provide some alternate time functions in nbtime.h
I recommend using those if at all possible...
Re: looking for localtime_r() or gmtime_r()
Posted: Mon Sep 15, 2014 10:07 am
by heineckenb
Answering my own question...
Ok, something I probably will never understand. If I enclose the struct tm definition and the gmtime_r function prototype thusly:
Code: Select all
_BEGIN_STD_C
struct tm
{
int tm_sec;
int tm_min;
int tm_hour;
int tm_mday;
int tm_mon;
int tm_year;
int tm_wday;
int tm_yday;
int tm_isdst;
};
void gmtime_r(const time_t *,struct tm *);
_END_STD_C
then it links. I cannot find anything in the log that indicates the linker is invoked differently, but clearly, that _BEGIN_STD_C/_END_STD_C somehow causes the linker to scan or re-scan the standard C library libc.a.
Does anybody reading this KNOW (not surmise, not guess, not "looks like", but really, really KNOWS) why this happens or what's going on?
Now, it uses 31472 bytes out of 31488, so I have 16 bytes left to do something with the time I've finally gotten hold of....
Re: looking for localtime_r() or gmtime_r()
Posted: Mon Sep 15, 2014 10:14 am
by heineckenb
I am using the functions in nbtime.h. I don't see how those give me anything other than the time_t long that is the number of seconds since whenever, long time ago. I need it parsed into day of year, day of week, hour, minute, second, that kind of thing. Is there another way to get this other than localtime_r() and/or gmtime_r()?
Re: looking for localtime_r() or gmtime_r()
Posted: Mon Sep 15, 2014 3:13 pm
by pbreed
As I said in my first response...
Probable a C/C++ linker problem...
IE in c++ if you just define a function without the extern C
void gmtime_r(const time_t *,struct tm *);
This gets name mangled into something showing the parameters, in C this does not happen....
So if you want to write a C++ function callable by a C function (ie callable by the library)
or you want to call a C function from a C++ file then you need the extern "C" stuff google name mangeling and C/C++ linking.
Look at the nburn\examples\sbl2e\ntp for time management functions...
Re: looking for localtime_r() or gmtime_r()
Posted: Thu Sep 18, 2014 7:49 am
by heineckenb
I had forgotten about name mangling in C++, I guess that makes sense.
When you wrote "a linker problem", I thought you meant a bug either in
the linker or the linker script, not in just combining C and C++ modules
(and names) in one link.
Thanks.