looking for localtime_r() or gmtime_r()

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

[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

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

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

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

[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()?

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

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