gmane.os.netbsd.devel.userlevel

Re: de_DE.UFT-8 LC issues

Joerg Sonnenberger — 2013-06-17T11:29:21

Try running /usr/bin/locale, it tells you what effective locale settings
are used. The short version is that no entry in /usr/share/locale exists
for de_DE.UTF-8.

Joerg

de_DE.UFT-8 LC issues

Sebastian Thadewald — 2013-06-17T09:49:27

Hello together,

i have a strange problem with LC_ALL from PHP.

When i set "setlocale(LC_ALL, 'de_DE.UTF-8');" in PHP, my date appears 
in english. But when i set the LC_ALL to "de_DE.ISO8859-15", date 
appears in correct Language.

I saw, when i set "export LC_ALL="de_DE.UTF-8"" that some entries are 
empty. If i set "export LC_ALL="de_DE.ISO8859-15"" the most common 
entries are filled with the charset.

Now i have a workaround for such problem, but in my phpscript. When i 
set the LC_ALL to "de_DE.ISO8859-15" the LC's are correct filled up. 
Later in the script i set "de_DE.UTF-8" as LC_ALL and it will fill up 
only some entries, rest of them are still "de_DE.ISO8859-15".

But i think, this workaround is not a good solution at all.

Im using NetBSD6.1.

For each answer, I am very thankful.


Greetings Sebastian

Re: [PATCH] Support for mbsnrtowcs and wcsnrtomb

Joerg Sonnenberger — 2013-05-21T18:12:21

Attached is an updated and simplified version.

Joerg
Index: distrib/sets/lists/debug/mi
===================================================================
RCS file: /home/joerg/repo/netbsd/src/distrib/sets/lists/debug/mi,v
retrieving revision 1.22
diff -u -p -r1.22 mi
--- distrib/sets/lists/debug/mi8 May 2013 17:41:31 -00001.22
+++ distrib/sets/lists/debug/mi17 May 2013 13:08:32 -0000
< at >< at > -1543,6 +1543,7 < at >< at >
 ./usr/libdata/debug/usr/tests/lib/libc/locale/t_io.debugtests-lib-debugdebug,atf
 ./usr/libdata/debug/usr/tests/lib/libc/locale/t_mbrtowc.debugtests-lib-debugdebug,atf
 ./usr/libdata/debug/usr/tests/lib/libc/locale/t_mbstowcs.debugtests-lib-debugdebug,atf
+./usr/libdata/debug/usr/tests/lib/libc/locale/t_mbsnrtowcs.debugtests-lib-debugdebug,atf
 ./usr/libdata/debug/usr/tests/lib/libc/locale/t_mbtowc.debugtests-lib-debugdebug,atf
 ./usr/libdata/debug/usr/tests/lib/libc/locale/t_wcscspn.debugtests-lib-debugdebug,atf
 ./usr/libdata/debug/usr/tests/lib/libc/locale/t_wcspbrk.debug

libldap/libldap_r confusion

Edgar Fuß — 2013-05-21T14:26:59

The more I think about it, the more fundamental the problem appears to be.

If a library uses LDAP, i.e. libldap{,_r}, it can't know whether it will be
used in a threaded or non-threaded world. Should it link to libldap or to
libldap_r?

Re: Forcing PLT resolution (was: libldap/libldap_r confusion)

David Laight — 2013-05-20T21:22:54

I wouldn't have thought it caused that much grief - unless someone
is using RTLD_GLOBAL...

David

Re: Incompat change (6 weeks ago) in stdio breaks formail (from procmail)

Robert Elz — 2013-05-19T11:18:58

    Date:        Sun, 19 May 2013 02:56:06 +0000
    From:        David Holland <dholland-tech< at >NetBSD.org>
    Message-ID:  <20130519025606.GA3700< at >netbsd.org>

  | I'd vote for explicitly testing for ESPIPE; it's the Right Thing (tm).

When I started sending the previous message, that was how I had expected
it to end - I even had a patch prepared which does that, which I had
intended including.   By the time I finished the message, I had pretty
much convinced myself that the simplicity of just ignoring the error
(and leaving the code the way it has been for a long long time) was
better, so, I didn't bother including the patch in the message.

But, here it is, in case others decide this is the better way.   I think
the problem needs to be fixed, one way or the other - I am not a developer,
so I don't get a vote, and either change works OK for me.

kre

Index: stdio.c
===================================================================
RCS file: /cvsroot/NetBSD/src/lib/libc/stdio/stdio.c,v
retrieving revision 1

Re: Incompat change (6 weeks ago) in stdio breaks formail (from procmail)

David Holland — 2013-05-19T02:56:06

 > A seemingly inoccuous change in the latest version of lib;libc/stdio/stdio.c
 > made in late March ...
 > [snip]

I'd vote for explicitly testing for ESPIPE; it's the Right Thing (tm).

Incompat change (6 weeks ago) in stdio breaks formail (from procmail)

Robert Elz — 2013-05-19T02:11:30

A seemingly inoccuous change in the latest version of lib;libc/stdio/stdio.c
made in late March ...

--- stdio.c2012/03/20 01:42:591.20
+++ stdio.c2012/03/27 15:05:421.21

-(void) lseek(__sfileno(fp), (off_t)0, SEEK_END);
+if (lseek(__sfileno(fp), (off_t)0, SEEK_END) == (off_t)-1)
+return -1;

which looks like it should obviously be the correct thing to do
(as after all, we should always check syscall errors...) but turns
out to cause problems.

This seek is done only if the (internal) __SAPP flag is set, which is
only ever set in the case of fdopen(fd, "a").   The problem for formail
is that it does this precise operation on a fd that (in the way I use
it anyway) had fd being the (write half of) the result from pipe(2).

I am not sure why formail is using "a" mode, rather than "w" but it might
be that the same fdopen() is also used where the fd came from different
origins, and append mode is actually wanted (formail is absurdly difficult
to decipher...).   In any case, this code has worked (and s

Re: Forcing PLT resolution

Nick Hudson — 2013-05-16T15:40:49

Look for LD_BIND_NOW in ld.elf_so(1).

Nick

Forcing PLT resolution (was: libldap/libldap_r confusion)

Edgar Fuß — 2013-05-16T14:21:07

Is there a method of forcing resolution of a PLT entry other then calling the
function in question?

As stated earlier in this thread, my problem is that pam_ldap loads libldap,
doesn't resolve ldap_ld_free until libldap_r has been loaded, causing havoc.

Re: libldap/libldap_r confusion

Edgar Fuß — 2013-05-14T10:25:28

Do we have something a la nscd so one can confine the dynamic linking
to just one process?

libldap/libldap_r confusion (was: radiusd: Error detected by libpthread: Invalid mutex.)

Edgar Fuß — 2013-05-13T16:55:37

Yes, the problem is the following:

radiusd calls initgroups() from the C library.
That, by /etc/nsswitch.conf, dynamically loads nss_ldap.
nss_ldap pulls in libldap (not libldap_r).
Later, radiusd dynamically loads rlm_ldap.
rlm_ldap pulls in libldap_r.
Later, nss_ldap, via PLT, calls ldap_ld_free(). Being linked against libldap,
it expects to call the libldap version of ldap_ld_free().
However, since the dynamic linker, in the meantime, has loaded libldap_r,
it resolves that PLT entry to the libldap_r version of ldap_ld_free().

My impression is that this is fundamentally broken and cannot easily be fixed.
We can link nss_ldap against libldap_r, but then some program may later pull in
libldap, and we get the same mess the other way round.

Re: Alternative access for C locale

Joerg Sonnenberger — 2013-05-10T16:51:01

Cleaned up version that merges storage used by global default locale and
the C locale as much as possible.

Joerg
Index: common/lib/libc/stdlib/_strtol.h
===================================================================
RCS file: /home/joerg/repo/netbsd/src/common/lib/libc/stdlib/_strtol.h,v
retrieving revision 1.6
diff -u -p -r1.6 _strtol.h
--- common/lib/libc/stdlib/_strtol.h26 Apr 2013 21:20:48 -00001.6
+++ common/lib/libc/stdlib/_strtol.h7 May 2013 11:16:04 -0000
< at >< at > -192,14 +192,14 < at >< at > INT_FUNCNAME(_int_, _FUNCNAME, _l)(const
 __INT
 _FUNCNAME(const char *nptr, char **endptr, int base)
 {
-return INT_FUNCNAME(_int_, _FUNCNAME, _l)(nptr, endptr, base, *_current_locale());
+return INT_FUNCNAME(_int_, _FUNCNAME, _l)(nptr, endptr, base,
+    LC_GLOBAL_LOCALE);
 }
 
 __INT
-INT_FUNCNAME(, _FUNCNAME, _l)(const char *nptr, char **endptr, int base, locale_t loc)
+INT_FUNCNAME(, _FUNCNAME, _l)(const char *nptr, char **endptr, int base,
+    locale_t loc)
 {
-if (loc == NULL)
-loc = _C_locale;
 return

Re: radiusd: Error detected by libpthread: Invalid mutex.

Edgar Fuß — 2013-05-10T21:01:51

But it does use the system ldap, doesn't it? Only nss uses libldap while rlm_ldap uses libldap_r.

Re: radiusd: Error detected by libpthread: Invalid mutex.

Christos Zoulas — 2013-05-10T20:39:32

In article <20130510181446.GN27359< at >trav.math.uni-bonn.de>,
Edgar Fuß  <ef< at >math.uni-bonn.de> wrote:

Using 2 copies of the library is asking for trouble. I suggest that the
package should be changed to use the system ldap copy if available like
we do with openssl.

christos

Re: radiusd: Error detected by libpthread: Invalid mutex.

Edgar Fuß — 2013-05-10T18:14:48

I'm making some progress on this. That ldap_ld_free() is called from a
pthread_atfork (child) handler installed by nss_ldap.

However, I had a hard time setting breakpoints that where not hit despite
the corresponding function showing up in a later backtrace until I realized
that I had TWO copies of LDAP libraries in memory: One libldap pulled in by
nss_ldap and one libldap_r pulled in by FreeRADIUS' rlm_ldap module.

Question one: Is that alone (i.e. using both libldap and libldap_r) asking
for trouble?

Question two: If not, how do I set a breakpoint on a specific incarnation
of ldap_foobar?

Re: where is res_nupdate()?

Emmanuel Dreyfus — 2013-05-10T09:45:45

It works fine.

Re: where is res_nupdate()?

Christos Zoulas — 2013-05-10T02:05:53

Re: where is res_nupdate()?

Emmanuel Dreyfus — 2013-05-10T00:46:30


That builds fine. I copied the file below to a NetBSD-6.0 systelm and it
see no regression. I will test res_update functionnality later and send
the pullup.

lib/libc.so -> libc.so.12.181
lib/libc.so.12 -> libc.so.12.181
lib/libc.so.12.181  
usr/lib/libc.a  
usr/lib/libc.so -> ../../lib/libc.so.12.181
usr/lib/libc.so.12 -> ../../lib/libc.so.12.181
usr/lib/libc.so.12.181 -> ../../lib/libc.so.12.181
usr/lib/libresolv.a  
usr/lib/libresolv.so -> libresolv.so.3.0
usr/lib/libresolv.so.3 -> libresolv.so.3.0
usr/lib/libresolv.so.3.0  
usr/include/res_update.h

Alternative access for C locale

Joerg Sonnenberger — 2013-05-09T20:27:15

Hi all,
there was a concern about exposing the C locale via the special NULL
argument on source-changes. The attached patch provides LC_C_LOCALE and
LC_GLOBAL_LOCALE for access to the corresponding locales. Inside libc,
they are protected, so that access can avoid the GOT and use PC relative
addressing if supported by the platform. This removes the last potential
performance penality of the *_l wrapping.

The patch allows LC_GLOBAL_LOCALE for all locale functions, which is an
extension over POSIX. LC_C_LOCALE can be easily implemented using
newlocale() if necessary on platforms lacking it. I'm in the process of
getting it supported e.g. by Apple as well.

The patch contains one chunk from the mbsnrtowcs patch that is unrelated
and not for commit, but I don't want to edit that out before commit time.

Joerg
Index: include/locale.h
===================================================================
RCS file: /home/joerg/repo/netbsd/src/include/locale.h,v
retrieving revision 1.21
diff -u -p -r1.21 locale.h
---

Re: radiusd: Error detected by libpthread: Invalid mutex.

Edgar Fuß — 2013-05-09T20:22:57

Eh, no. But the backtrace shows it's happening inside fork(), isn't it?