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"

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

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 .

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

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:

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:

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

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.

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

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

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.

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!

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.

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?

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

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