LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 03-16-2015, 02:29 PM   #1
neutrino-pl
LQ Newbie
 
Registered: Nov 2013
Posts: 11

Rep: Reputation: Disabled
64bit time_t in Linux Kernel


I have compiled kernel 3.19.1 but still have a problem with time_t. Just simple program with cout << sizeof (time_t); gives size of 4 bytes, not 8 bytes as was my intention. Should I switch on a particular option during make menuconfig?
 
Old 03-16-2015, 05:30 PM   #2
Pearlseattle
Member
 
Registered: Aug 2007
Location: Zurich, Switzerland
Distribution: Gentoo
Posts: 999

Rep: Reputation: 141Reputation: 141
Weird.

My code (some garbage around):
Code:
#include <stdio.h>
#include <stdlib.h>
#include <iostream>
#include <string>

using namespace std;

int main(int argc, char **argv)
{
        cout << sizeof (time_t);
}
Compilation:
g++ test.cpp -o test

Result:
8

You're sure that you're using a 64bit OS?
What's the output of "uname -a"?
 
Old 03-17-2015, 12:01 PM   #3
neutrino-pl
LQ Newbie
 
Registered: Nov 2013
Posts: 11

Original Poster
Rep: Reputation: Disabled
Yes, that is true. I have tested it with 32bit Linux and 32bit CPU.
Is it possible to patch the kernel and have long and time_t types with size of 8 bytes on 32bit CPU?
Maybe '64-bit kernel' option during make menuconfig should solve that issue?
 
Old 03-17-2015, 01:21 PM   #4
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora
Posts: 3,998

Rep: Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218
Why would changing the kernel affect a user-space program? Are you specifying -m32 or -m64?
 
Old 03-17-2015, 01:35 PM   #5
273
LQ Addict
 
Registered: Dec 2011
Location: UK
Distribution: Debian Sid AMD64, Raspbian Wheezy, various VMs
Posts: 7,672

Rep: Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371Reputation: 2371
I'm probably typing out of turn as I'm out of my depth here but a memory of trying to learn C and a google makes me think that time_t will be defined in the C libraries you link to so is that clib[or whatever]?
Please ignore, and sorry, if I am obviously ignorant.
 
Old 03-17-2015, 01:51 PM   #6
neutrino-pl
LQ Newbie
 
Registered: Nov 2013
Posts: 11

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by smallpond View Post
Why would changing the kernel affect a user-space program? Are you specifying -m32 or -m64?
http://git.rocketboards.org/?p=linux...d0fd8a9f10e8aa
 
Old 03-17-2015, 05:54 PM   #7
smallpond
Senior Member
 
Registered: Feb 2011
Location: Massachusetts, USA
Distribution: Fedora
Posts: 3,998

Rep: Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218Reputation: 1218
Quote:
Originally Posted by neutrino-pl View Post

What does code for a system-on-chip FPGA have to do with this discussion?
 
Old 03-17-2015, 07:55 PM   #8
ljb643
Member
 
Registered: Nov 2003
Posts: 517

Rep: Reputation: Disabled
Quote:
Originally Posted by smallpond View Post
Why would changing the kernel affect a user-space program? Are you specifying -m32 or -m64?
Not the kernel, but the architecture? My understanding is that on a 64 bit system, time_t is defined as 64 bits; on a 32 bit system it is 32 bits. That is how I read <bits/types.h> and <bits/typesizes.h>, but I could be wrong.

From another point of view, I've always read that the solution to the Unix/Linux "year 2037 problem" when the old time_t wraps around is the 64 bit architecture which has a bigger time_t.
 
1 members found this post helpful.
Old 03-18-2015, 02:25 PM   #9
Pearlseattle
Member
 
Registered: Aug 2007
Location: Zurich, Switzerland
Distribution: Gentoo
Posts: 999

Rep: Reputation: 141Reputation: 141
Maybe there is a workaround, depending on what you want want to do / what the reason is for you to get time_t as 64bit or bigger.
 
Old 03-18-2015, 05:19 PM   #10
neutrino-pl
LQ Newbie
 
Registered: Nov 2013
Posts: 11

Original Poster
Rep: Reputation: Disabled
I have decided to use boost:: posix_time:: ptime instead of time_t and related functions like mktime().

Last edited by neutrino-pl; 03-18-2015 at 05:22 PM.
 
1 members found this post helpful.
Old 03-18-2015, 05:44 PM   #11
Pearlseattle
Member
 
Registered: Aug 2007
Location: Zurich, Switzerland
Distribution: Gentoo
Posts: 999

Rep: Reputation: 141Reputation: 141
Thx - and I agree, most probably the best alternative.
 
Old 03-19-2015, 02:39 AM   #12
neutrino-pl
LQ Newbie
 
Registered: Nov 2013
Posts: 11

Original Poster
Rep: Reputation: Disabled
Well, it is indeed a good alternative. Right now I have to make some software for x86 embedded platform which is of course 32bit architecture. It's only a little chance it will still run on 2038, but who knows... better to be prepared
 
Old 03-19-2015, 08:46 AM   #13
mina86
Member
 
Registered: Aug 2008
Distribution: Debian
Posts: 517

Rep: Reputation: 229Reputation: 229Reputation: 229
Kernel defines what time_t is, standard C library just obeys, because it has no other choice.

You cannot patch a kernel to change time_t to 64-bit on x86 because that would change the ABI of a time syscall and in turn all of your user-space. To make that work youd have to rebuild your whole system starting from C library. And of course hunt all the bugs in applications where author assumed sizeof(time_t) == sizeof(long) or something similar.

Using Boost (or anything else) does not solve the problem of system time wrapping around 2038 on 32-bit systems.

PS. This might be a better fit for Programming forum.

Last edited by mina86; 03-19-2015 at 12:32 PM.
 
Old 03-19-2015, 12:35 PM   #14
neutrino-pl
LQ Newbie
 
Registered: Nov 2013
Posts: 11

Original Poster
Rep: Reputation: Disabled
Boost does not affect the system date and time_t of course, but solves the y2038 problem in my piece of code. That's enough for me.
In case of system time maybe here's a little hope:
http://lwn.net/Articles/607741/

Last edited by neutrino-pl; 03-19-2015 at 12:39 PM.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Linux Mint Debian - Kernel 3.6.6 - 64bit NotAComputerGuy Linux - Newbie 1 11-16-2012 01:11 PM
[SOLVED] 64bit Linux versions write they are for amd64. Combatible for Intel 64bit also? esgol Linux - Newbie 2 07-13-2012 02:07 AM
Source code for the time_t time( time_t *timer ) function bidur Programming 2 09-06-2011 06:07 AM
Kernel Panic in 64bit Arch Linux after Kernel Recompile: 2.6.35-rc3 jackerybakery Linux - General 3 06-16-2010 10:21 AM
[SOLVED] Get the number of leap seconds in time ( time_t) minimol Linux - Newbie 5 07-07-2009 11:52 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 05:25 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration