Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 27 Apr 2018, 01:24
All times are UTC - 4

 Forum index » Off-Topic Area » Programming
Time & date & other - libc/dietlibc/uclibc/musl difference
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 2 [18 Posts]   Goto page: 1, 2 Next
Author Message
goingnuts

Joined: 07 Dec 2008
Posts: 904
PostPosted: Sat 29 Sep 2012, 08:43    Post subject:  Time & date & other - libc/dietlibc/uclibc/musl difference  
I have noticed that when I use uclibc or dietlibc I get a different time than when using normal libc. The below c-code can be compiled by:
"gcc show_time.c -o show_time" or "diet gcc show_time.c -o show_time"
Code:
//gcc show_time.c -o show_time
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main(void) {
  time_t now;
  time(&now);
  printf("%s", ctime(&now));
  return EXIT_SUCCESS;
}

When running the libc-compiled bin I get:
Sat Sep 29 14:39:24 2012
which is in many ways the result I want...but running the same bin linked with dietlibc or uclibc gives:
Sat Sep 29 06:40:38 2012
which is not the time I want...
How to fix this?
Last edited by goingnuts on Thu 07 Mar 2013, 15:46; edited 1 time in total
Back to top
View user's profile Send private message Visit poster's website 
Karl Godt


Joined: 20 Jun 2010
Posts: 4208
Location: Kiel,Germany
PostPosted: Sat 29 Sep 2012, 18:53    Post subject:  
No idea . It seems that the 8 hours difference might be related to the kernel compiled in GMT-8 (PERTH (actually is +8 ) -usual Puppy Bogus) back then . Dunno how the other compiles do work, but probably it is in the non-standard headers .
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 904
PostPosted: Sat 29 Sep 2012, 21:20    Post subject:  
Thanks Karl - you are right - normal libc build shows the systemtime (which I want) but the dietlibc and uclibc shows the adjusted time if timezone are chosen. If I set timezone to GMT they show the same (the /etc/localtime symlink). After changing timezone one has to reboot to get the new values from dietlibc/uclibc linked bin. Now the main issue is how to get uclibc/dietlibc to show systemtime always....
Back to top
View user's profile Send private message Visit poster's website 
Karl Godt


Joined: 20 Jun 2010
Posts: 4208
Location: Kiel,Germany
PostPosted: Sat 29 Sep 2012, 22:38    Post subject:  
bash-3.00#
Code:
diff /opt/diet/include/time.h /usr/include/time.h |wc -l

Quote:
488


I could think of replacing the header(s) ?

* BTW : This musl thread is quite good . I followed the simple instructions and was able to build a working guess_fstype for my kernel, that diet could not .
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 904
PostPosted: Sun 30 Sep 2012, 03:35    Post subject:  
musl is looking very promising! I still havent been able to compile a working gtk1.2 so not using it intensive yet...
I can compile "guess_fstype_withext4_test1" with diet gcc by the following command:
diet gcc -D_BSD_SOURCE -s -Os guess_fstype.c main.c -o guess_fstype
ends up in a 17K bin.

As for the time issue I havent made progress. I thought that maybe the uclibc/dietlibc was using the global variable $TZ but they are not.

Did a strace on the bins - this indicate that they use the same value for the calculation. Btw. looking at the output of strace is quite interesting: The libc linked bin is doing a lot of things that seems irrelevant:
Code:
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/i686/sse2", 0xbf9607dc) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/i686", 0xbf9607dc)     = -1 ENOENT (No such file or directory)
open("/lib/tls/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/sse2", 0xbf9607dc)     = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY)    = -1 ENOENT (No such file or directory)
stat64("/lib/tls", 0xbf9607dc)          = -1 ENOENT (No such file or directory)
open("/lib/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/i686/sse2", 0xbf9607dc)    = -1 ENOENT (No such file or directory)
open("/lib/i686/libc.so.6", O_RDONLY)   = -1 ENOENT (No such file or directory)
stat64("/lib/i686", 0xbf9607dc)         = -1 ENOENT (No such file or directory)
open("/lib/sse2/libc.so.6", O_RDONLY)   = -1 ENOENT (No such file or directory)
stat64("/lib/sse2", 0xbf9607dc)         = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3

Why does it have to sort of "guess" the location of libc.so.6? Must slow down every binary we start...
Back to top
View user's profile Send private message Visit poster's website 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson
PostPosted: Fri 19 Oct 2012, 14:41    Post subject:  
goingnuts wrote:
musl is looking very promising! I still havent been able to compile a working gtk1.2 so not using it intensive yet...

IIRC, it was basically just that __(u)int{,8,16,32}_t needs to be defined/changed to (u)int{,8,16,32}_t.
-D__uint32_t=uint32_t -D__int32_t=int32_t or
Code:
sed -e 's/__\(u*int[123468]*_t\)/\1/g' -i <filename>


The issue is that someone didn't bother setting the right feature test macros/standards and just used the internal aliases instead.

Quote:
I can compile "guess_fstype_withext4_test1" with diet gcc by the following command:
diet gcc -D_BSD_SOURCE -s -Os guess_fstype.c main.c -o guess_fstype
ends up in a 17K bin.

As for the time issue I havent made progress. I thought that maybe the uclibc/dietlibc was using the global variable $TZ but they are not.

How'd you find this out?
note that TZ=XXX only affects timezone displayed; you need to set at least
TZ=XSTn[XDT(n-1)]
POSIX specifies the "n" as the value that needs to be added to localtime to get UTC.
In other words, for Perth you should use
TZ=WST-8
and California/PDT:
TZ=PST8PDT7

Quote:

Did a strace on the bins - this indicate that they use the same value for the calculation. Btw. looking at the output of strace is quite interesting: The libc linked bin is doing a lot of things that seems irrelevant:
Code:
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/i686/sse2", 0xbf9607dc) = -1 ENOENT (No such file or directory)
open("/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/i686", 0xbf9607dc)     = -1 ENOENT (No such file or directory)
open("/lib/tls/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/tls/sse2", 0xbf9607dc)     = -1 ENOENT (No such file or directory)
open("/lib/tls/libc.so.6", O_RDONLY)    = -1 ENOENT (No such file or directory)
stat64("/lib/tls", 0xbf9607dc)          = -1 ENOENT (No such file or directory)
open("/lib/i686/sse2/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat64("/lib/i686/sse2", 0xbf9607dc)    = -1 ENOENT (No such file or directory)
open("/lib/i686/libc.so.6", O_RDONLY)   = -1 ENOENT (No such file or directory)
stat64("/lib/i686", 0xbf9607dc)         = -1 ENOENT (No such file or directory)
open("/lib/sse2/libc.so.6", O_RDONLY)   = -1 ENOENT (No such file or directory)
stat64("/lib/sse2", 0xbf9607dc)         = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3

Why does it have to sort of "guess" the location of libc.so.6? Must slow down every binary we start...

The theory is ostensibly that you can get an "optimized" libc for your system; as usual with glibc, it slows everything down Cool
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4787
Location: Kingwood, TX
PostPosted: Fri 19 Oct 2012, 22:22    Post subject:  
to fix time warps when compiling

Code:
for x in `find .`; do touch $x;done


Bonus: here is some C to give you elapsed time (replace sleep with your commands) ... because you can't time part of your code with the time command

Code:
#include <sys/time.h>
#include <stdlib.h>
#include <stdio.h>
#include <math.h>
 
int main(void){
struct timeval tim;
double started, stopped;
gettimeofday(&tim, NULL);
   started = (double) (tim.tv_sec * 1000000 + tim.tv_usec);
sleep(1);
gettimeofday(&tim, NULL);
   stopped = (double) (tim.tv_sec * 1000000 + tim.tv_usec);
return (printf("DELTA=%.6lf", (float) (stopped - started)/1000000));
}

_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
goingnuts

Joined: 07 Dec 2008
Posts: 904
PostPosted: Tue 23 Oct 2012, 12:30    Post subject:  
Ibidem: The gtk1.2 build ok but exits when trying to run bins linked against the libs with the error:
Quote:
GLib-ERROR **: could not allocate -1 bytes
aborting...
Aborted

valgrind/gdb gives no clue (to me) but the error seems to come from function g_malloc0 in gmem.c (glib-1.2.10) at:
Code:
p = (gpointer) calloc (size, 1);
  if (!p)
    g_error ("could not allocate %ld bytes", size);
which tells me ...nothing...

As for the thought that TZ was used it was just a wild guess as the difference matched the last digits in TZ. Found that dietlibc, uclibc and musllibc all gives the same time running the show_time program (the timezone modified time) whereas libc gives the system time...

technosaurus: thx for the elapsed time coding.
Back to top
View user's profile Send private message Visit poster's website 
technosaurus


Joined: 18 May 2008
Posts: 4787
Location: Kingwood, TX
PostPosted: Tue 23 Oct 2012, 23:49    Post subject:  
Quote:
GLib-ERROR **: could not allocate -1 bytes
aborting...
Aborted
I ran into that problem when I was building my musl+gtk1 toolchain - eventually got it to build, but I don't remember how, just that it involved a lot of google... then again I ended up commenting out a lot of stuff until the title bar always ended up empty on localized programs.
_________________
Check out my github repositories. I may eventually get around to updating my blogspot.
Back to top
View user's profile Send private message Visit poster's website 
goingnuts

Joined: 07 Dec 2008
Posts: 904
PostPosted: Mon 04 Mar 2013, 15:35    Post subject:  
Just a follow up on musl/glib-1.2.10 problem: Compiled musl-0.9.9 and glib-1.2.10 with -g and run the testglib binary coming with glib. glib is compiled with -DENABLE_MEM_CHECK to get it a little further than
Code:
GLib-ERROR **: could not allocate -1 bytes
aborting...
Aborted


With gdb I get:
Code:
Starting program: /mnt/sdc3/musl-toolchain/build/glib-1.2.10/testglib
TestGLib v1.2.10 (i:10 b:10)
cwd: /mnt/sdc3/musl-toolchain/build/glib-1.2.10

Program received signal SIGSEGV, Segmentation fault.
0xb7eefc95 in memset (dest=0x805d128, c=0, n=4294881575)
    at src/string/memset.c:17
17                      for (w = (void *)s; n>=SS; n-=SS, w++) *w = k;
(gdb) backtrace
#0  0xb7eefc95 in memset (dest=0x805d128, c=0, n=4294881575)
    at src/string/memset.c:17
#1  0x0804f27a in g_free (mem=0x805d120) at gmem.c:409
#2  0x0805916e in g_get_any_init () at gutils.c:549
#3  0x0805925e in g_get_user_name () at gutils.c:595
#4  0x08049d4f in main () at testglib.c:352


I guess its not memset but maybe the value passed to it?
If I change the code in testglib.c like below
Code:

//g_print ("user: %s\n", g_get_user_name ());
char *p=getenv("USER");
g_print ("user: %s\n", p);

then it works but fail at next call with same error:
Code:

TestGLib v1.2.10 (i:10 b:10)
cwd: /mnt/sdc3/musl-toolchain/build/glib-1.2.10
user: root

Program received signal SIGSEGV, Segmentation fault.
0xb7f01c95 in memset (dest=0x805d148, c=0, n=4294881607)
    at src/string/memset.c:17
17                      for (w = (void *)s; n>=SS; n-=SS, w++) *w = k;
(gdb) backtrace
#0  0xb7f01c95 in memset (dest=0x805d148, c=0, n=4294881607)
    at src/string/memset.c:17
#1  0x0804f288 in g_free (mem=0x805d140) at gmem.c:409
#2  0x0805917e in g_get_any_init () at gutils.c:549
#3  0x0805930d in g_get_real_name () at gutils.c:606
#4  0x08049d75 in main () at testglib.c:356

...what is wrong in there?
Update: Kind of knew posting here would help...
So went into the g_get_any_init function and commented along the way. Configure sets #define HAVE_PWD_H 1 in config.h which seem to get g_get_any_init off the track. If eliminated after configure it just - runs Very Happy
Back to top
View user's profile Send private message Visit poster's website 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson
PostPosted: Tue 05 Mar 2013, 02:44    Post subject:  
FYI, you can avoid the edit after configure by setting the environment variable ac_cv_header_pwd_h=0 before you run configure.

Also, a note: original glib 1.2.10 needs G_GNUC_PRETTY_FUNCTION to not be set to __PRETTY_FUNCTION__ for gcc 4.x; this is because gcc 4.x defines this to a variable not a string constant. There are probably patches that address this already.

Another note: I'm finding that gtk 1.2 needs X_EXTRA_LIBS="-lXext" here, or the libX11 test will fail.
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 904
PostPosted: Tue 05 Mar 2013, 11:23    Post subject:  
After further testing I found that it is actually the HAVE_GETPWUID_R that needs to be disabled - then "user/real user" is correctly "root/root" and not "somebody/Unknown".
And setting "ac_cv_func_getpwuid_r=0" works - thanks for the tip!

Debian has a patch for gtk (glib1.2_1.2.10-19build1.diff) that handles the G_GNUC_PRETTY_FUNCTION.

Having a working musl-glib-1.2.10 wont give an error free musl-gtk-1.2.10 - I still have issues with menus being micro-sized and without label and the fileselect segfaults somewhere in strcmp. But its a start!
Back to top
View user's profile Send private message Visit poster's website 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson
PostPosted: Wed 06 Mar 2013, 02:23    Post subject:  
goingnuts wrote:
After further testing I found that it is actually the HAVE_GETPWUID_R that needs to be disabled - then "user/real user" is correctly "root/root" and not "somebody/Unknown".
And setting "ac_cv_func_getpwuid_r=0" works - thanks for the tip!

Debian has a patch for gtk (glib1.2_1.2.10-19build1.diff) that handles the G_GNUC_PRETTY_FUNCTION.

Having a working musl-glib-1.2.10 wont give an error free musl-gtk-1.2.10 - I still have issues with menus being micro-sized and without label and the fileselect segfaults somewhere in strcmp. But its a start!

Any chance of a testcase for getpwuid_r? If there's a bug, it needs fixing; but "an ancient version of glib doesn't work right" is pretty bad for tracking it down.
Also the strcmp segfault sounds like a problem.
Back to top
View user's profile Send private message 
goingnuts

Joined: 07 Dec 2008
Posts: 904
PostPosted: Wed 06 Mar 2013, 15:31    Post subject:  
Further test: Seems that the below hack (setting bufsize = 64) in gutils.c enable build without the disabled ac_cv_func_getpwuid_r. So for some reason the sysconf(_SC_GETPW_R_SIZE_MAX) fails...seems to be set to 70...so is it the sysconf who is failing?

Debug is (kind of) fun...

in function g_get_any_init:
Code:
ifdef _SC_GETPW_R_SIZE_MAX 
        /* This reurns the maximum length */
      //  guint bufsize = sysconf (_SC_GETPW_R_SIZE_MAX);
        guint bufsize = 64;
#    else /* _SC_GETPW_R_SIZE_MAX */
        guint bufsize = 64;
#    endif /* _SC_GETPW_R_SIZE_MAX */
Back to top
View user's profile Send private message Visit poster's website 
Ibidem

Joined: 25 May 2010
Posts: 553
Location: State of Jefferson
PostPosted: Wed 06 Mar 2013, 20:46    Post subject:  
goingnuts wrote:
Further test: Seems that the below hack (setting bufsize = 64) in gutils.c enable build without the disabled ac_cv_func_getpwuid_r. So for some reason the sysconf(_SC_GETPW_R_SIZE_MAX) fails...seems to be set to 70...so is it the sysconf who is failing?

It actually returns -1, which explains the errors.
See http://git.musl-libc.org/cgit/musl/tree/src/conf/sysconf.c, line 85.

This actually is mentioned in the standard:
http://pubs.opengroup.org/onlinepubs/9699919799/functions/getpwnam.html
Quote:

Debug is (kind of) fun...

in function g_get_any_init:
Code:
ifdef _SC_GETPW_R_SIZE_MAX 
        /* This reurns the maximum length */
      //  guint bufsize = sysconf (_SC_GETPW_R_SIZE_MAX);
        guint bufsize = 64;
#    else /* _SC_GETPW_R_SIZE_MAX */
        guint bufsize = 64;
#    endif /* _SC_GETPW_R_SIZE_MAX */

The proper fix would be to change bufsize (to 1024, per the standard's example; or to _SC_GETPW_R_SIZE_MAX) if it is -1.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 2 [18 Posts]   Goto page: 1, 2 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group

[ Time: 0.0874s ][ Queries: 12 (0.0221s) ][ GZIP on ]