SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi, I don't know if this happens only in my system, but after last updates, GIMP crashes due a segmentation fault when quitting the application. It works fine, the crash happens only closing the program.
It is possible that a rebuild is needed to solve it, I'll try to rebuild from sources tomorrow.
No, the error still occurs even after the recompilation
Hi, I don't know if this happens only in my system, but after last updates, GIMP crashes due a segmentation fault when quitting the application. It works fine, the crash happens only closing the program.
It's crashing here, too, but only when I have unsaved changes, select "Close All" or "Quit" and then confirm with "Discard Changes" → crash. Closing unsaved files one by one works. I also tried a recompiled GIMP but without success.
My latest update is from Wed Mar 20 21:10:30 UTC 2024.
It's crashing here, too, but only when I have unsaved changes, select "Close All" or "Quit" and then confirm with "Discard Changes" → crash. Closing unsaved files one by one works. I also tried a recompiled GIMP but without success.
My latest update is from Wed Mar 20 21:10:30 UTC 2024.
I just changed the time in the bios 23-03-2040, I stay offline, I reboot Slackware64 2 times.
"date" give a good answer.
But at the boot I have the message "last login: tue 'feb 16 16:30:07 +009 1904 on dev/tty1."
There is still 32-bit ???
My guess is that you get that message at login rather than boot. I would also guess that time is taken from the wtmp functionality and not the kernel. According to the man page of wtmp it does indeed have 32 bit time entries on x68_64:
Code:
/* The ut_session and ut_tv fields must be the same size when
compiled 32- and 64-bit. This allows data files and shared
memory to be shared between 32- and 64-bit applications. */
#if __WORDSIZE == 64 && defined __WORDSIZE_COMPAT32
int32_t ut_session; /* Session ID (getsid(2)),
used for windowing */
struct {
int32_t tv_sec; /* Seconds */
int32_t tv_usec; /* Microseconds */
} ut_tv; /* Time entry was made */
#else
long ut_session; /* Session ID */
struct timeval ut_tv; /* Time entry was made */
#endif
Code:
Note that on biarch platforms, that is, systems which can run both
32-bit and 64-bit applications (x86-64, ppc64, s390x, etc.), ut_tv is
the same size in 32-bit mode as in 64-bit mode. The same goes for
ut_session and ut_time if they are present. This allows data files and
shared memory to be shared between 32-bit and 64-bit applications.
This is achieved by changing the type of ut_session to int32_t, and
that of ut_tv to a struct with two int32_t fields tv_sec and tv_usec.
Since ut_tv may not be the same as struct timeval, then instead of the
call:
gettimeofday((struct timeval *) &ut.ut_tv, NULL);
the following method of setting this field is recommended:
struct utmp ut;
struct timeval tv;
gettimeofday(&tv, NULL);
ut.ut_tv.tv_sec = tv.tv_sec;
ut.ut_tv.tv_usec = tv.tv_usec;
With the ‘year2038-recommended’ module, configure by default should work on the following 32-bit platforms (or 32-bit ABIs in bi-arch systems):
Linux kernel 5.1 (2019) and later with glibc 2.34 (2021) and later on x86, arm, mips (o32 or n32 ABI), powerpc32, sparc32, s390, hppa, m68k, sh, csky, microblaze, nios2,
I run on franken-Slackware64 not 32-bit but I restart the test with a 5.4 kernel, I always have the same message "last login 1904".
*Henca wrote her message while I was writing mine.
mystery resolved thank you very much Henca.
Last edited by bigbadaboum; 03-24-2024 at 08:48 AM.
My guess is that you get that message at login rather than boot. I would also guess that time is taken from the wtmp functionality and not the kernel. According to the man page of wtmp it does indeed have 32 bit time entries on x68_64:
regards Henrik
Well then, it looks like a '2038 fix' is needed for wtmp
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.