From raj.khem at gmail.com Thu May 1 03:22:51 2008 From: raj.khem at gmail.com (Khem Raj) Date: Thu, 01 May 2008 03:22:51 -0700 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <19c1b8a90805010304n7a6cc057p8d5350c43ca97f1a@mail.gmail.com> References: <200804120407.07311.vda.linux@googlemail.com> <200805010204.54587.vda.linux@googlemail.com> <19c1b8a90805010053n442accf3pb23e65a76a279374@mail.gmail.com> <200805011001.01545.vda.linux@googlemail.com> <19c1b8a90805010236s6217265cocf8cc33308c6ec06@mail.gmail.com> <19c1b8a90805010252w7657fe3ck380f06127d1a0b5f@mail.gmail.com> <19c1b8a90805010304n7a6cc057p8d5350c43ca97f1a@mail.gmail.com> Message-ID: <1209637371.9205.5.camel@isis> Hi Denys In the new script to install headers. We assume that unifdef fails if the return is not 0. However as per the manpages of unifdef I see this The unifdef utility exits 0 if the output is an exact copy of the input, 1 if not, and 2 if in trouble. I have fixed the script so that it only exits when the return code from unifdef command is 2. OK? Thanks -Khem Signed-off-by: Khem Raj Index: extra/scripts/install_headers.sh =================================================================== --- extra/scripts/install_headers.sh (revision 21903) +++ extra/scripts/install_headers.sh (working copy) @@ -42,7 +42,10 @@ if test -d "$1/$filename"; then mkdir -p "$2/$filename" 2>/dev/null else - "$top_builddir/extra/scripts/unifdef" -UUCLIBC_INTERNAL "$1/$filename" >"$2/$filename" || exit + "$top_builddir/extra/scripts/unifdef" -UUCLIBC_INTERNAL "$1/$filename" >"$2/$filename" + if [ "$?" -eq "2" ]; then + exit + fi fi done ) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://busybox.net/lists/uclibc/attachments/20080501/90c549c5/attachment.pgp From vda.linux at googlemail.com Thu May 1 05:13:31 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 1 May 2008 14:13:31 +0200 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <1209637371.9205.5.camel@isis> References: <200804120407.07311.vda.linux@googlemail.com> <19c1b8a90805010304n7a6cc057p8d5350c43ca97f1a@mail.gmail.com> <1209637371.9205.5.camel@isis> Message-ID: <200805011413.31762.vda.linux@googlemail.com> On Thursday 01 May 2008 12:22, Khem Raj wrote: > Hi Denys > > In the new script to install headers. We assume that unifdef fails if > the return is not 0. However as per the manpages of unifdef I see this > > The unifdef utility exits 0 if the output is an exact copy of the input, > 1 if not, and 2 if in trouble. > > I have fixed the script so that it only exits when the return code from > unifdef command is 2. > > OK? Well, I just removed "|| exit". Thanks for debugging! -- vda From timo.teras at iki.fi Thu May 1 23:04:08 2008 From: timo.teras at iki.fi (=?ISO-8859-1?Q?Timo_Ter=E4s?=) Date: Fri, 02 May 2008 09:04:08 +0300 Subject: [PATCH] splice, vmsplice and tee for i386 In-Reply-To: <481183B5.5030402@iki.fi> References: <480C5F87.3060707@iki.fi> <20080421122113.GC18155@mx.loc> <50BF37ECE4954A4BA18C08D0C2CF88CB0411EDB1@exmail1.se.axis.com> <480E2657.1030703@iki.fi> <480E2AFE.8080706@mvista.com> <20080422201238.GA10167@mx.loc> <481071F7.5020201@iki.fi> <20080424124759.GA9754@mx.loc> <481183B5.5030402@iki.fi> Message-ID: <481AAED8.9090003@iki.fi> Timo Ter?s wrote: > Bernhard Fischer wrote: >> On Thu, Apr 24, 2008 at 02:41:43PM +0300, Timo Ter?s wrote: >>> Bernhard Fischer wrote: >>>> does splice() work if !LFS ? >>> I'm not exactly sure. splice has __off64_t * in it's prototype so >>> it might require LFS. >> Perhaps you can try this with your testcase and stub it out if it >> doesn't work. > > I turned off UCLIBC_HAS_LFS and recompiled without errors. > > (Though, I noticed that "make clean" does not delete all .os files > which caused the build to initially fail on other errors.) IMHO, this is good to commit. Any objections? - Timo From rep.dot.nop at gmail.com Fri May 2 00:18:57 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Fri, 2 May 2008 09:18:57 +0200 Subject: [PATCH] splice, vmsplice and tee for i386 In-Reply-To: <481AAED8.9090003@iki.fi> References: <480C5F87.3060707@iki.fi> <20080421122113.GC18155@mx.loc> <50BF37ECE4954A4BA18C08D0C2CF88CB0411EDB1@exmail1.se.axis.com> <480E2657.1030703@iki.fi> <480E2AFE.8080706@mvista.com> <20080422201238.GA10167@mx.loc> <481071F7.5020201@iki.fi> <20080424124759.GA9754@mx.loc> <481183B5.5030402@iki.fi> <481AAED8.9090003@iki.fi> Message-ID: <20080502071857.GA14696@mx.loc> On Fri, May 02, 2008 at 09:04:08AM +0300, Timo Ter?s wrote: >IMHO, this is good to commit. Any objections? Applied. Thanks! From carmelo.amoroso at st.com Fri May 2 06:59:45 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Fri, 02 May 2008 15:59:45 +0200 Subject: [Fwd: FW: 'locale' command.] Message-ID: <481B1E51.4050902@st.com> Thanks Filippo, patch has been committed in rev21923 on trunk Carmelo -------- Original Message -------- Subject: FW: 'locale' command. Date: Wed, 23 Apr 2008 10:39:05 +0200 From: Filippo ARCIDIACONO To: Carmelo AMOROSO -----Original Message----- From: filippo arcidiacono [mailto:filippo.arcidiacono at st.com] Sent: Monday, April 21, 2008 4:35 PM To: 'uclibc at uclibc.org' Subject: 'locale' command. Hi all, The following patch add the 'locale' command into the uClibc utilities. The patch applies to the latest trunk revision. Any comment are welcome. Best Regards, Filippo. This patch provide the first version of 'locale' command, it has been included into the utilities commands. Signed-off-by: Filippo Arcidiacono Index: utils/Makefile.in =================================================================== --- utils/Makefile.in (revision 21732) +++ utils/Makefile.in (working copy) @@ -25,6 +25,8 @@ CFLAGS-readelf := $(CFLAGS-utils-shared) +CFLAGS-locale := $(CFLAGS-utils) + BUILD_CFLAGS-utils := -include $(top_srcdir)include/elf.h BUILD_CFLAGS-utils-common := $(CFLAGS-utils-common) @@ -51,15 +53,17 @@ endif utils_ICONV_OBJ = +utils_LOCALE_OBJ = ifeq ($(UCLIBC_HAS_LOCALE),y) utils_ICONV_OBJ := $(utils_OUT)/iconv +utils_LOCALE_OBJ := $(utils_OUT)/locale endif utils_OBJ := $(patsubst %,$(utils_OUT)/%,$(utils_OBJ)) hostutils_OBJ := $(patsubst %,%.host,$(utils_OBJ)) -utils: $(utils_OBJ) $(utils_ICONV_OBJ) +utils: $(utils_OBJ) $(utils_ICONV_OBJ) $(utils_LOCALE_OBJ) # NOTE: We build the utils AFTER we have a uClibc-targeted toolchain. @@ -69,6 +73,9 @@ $(utils_OUT)/iconv: $(top_srcdir)libc/misc/wchar/wchar.c | $(libc) $(compile.u) +$(utils_OUT)/locale: $(top_srcdir)extra/locale/programs/locale.c | $(libc) + $(compile.u) + hostutils: $(hostutils_OBJ) $(hostutils_OBJ): $(utils_OUT)/%.host : $(utils_DIR)/%.c @@ -86,9 +93,10 @@ endif ifeq ($(UCLIBC_HAS_LOCALE),y) $(INSTALL) -m 755 $(utils_OUT)/iconv $(PREFIX)$(RUNTIME_PREFIX)usr/bin/iconv + $(INSTALL) -m 755 $(utils_OUT)/locale +$(PREFIX)$(RUNTIME_PREFIX)usr/bin/locale endif objclean-y += utils_clean utils_clean: - $(RM) $(utils_OUT)/{ldconfig,ldd,readelf,iconv,*.host} + $(RM) $(utils_OUT)/{ldconfig,ldd,readelf,iconv,locale,*.host} Index: include/langinfo.h =================================================================== --- include/langinfo.h (revision 21732) +++ include/langinfo.h (working copy) @@ -354,7 +354,6 @@ _NL_CTYPE_EXTRA_MAP_12, _NL_CTYPE_EXTRA_MAP_13, _NL_CTYPE_EXTRA_MAP_14, - _NL_NUM_LC_CTYPE, #else /* 0 */ _NL_CTYPE_OUTDIGIT0_MB = _NL_ITEM (__LC_CTYPE, 0), _NL_CTYPE_OUTDIGIT1_MB, @@ -370,6 +369,7 @@ CODESET = _NL_CTYPE_CODESET_NAME, #define CODESET CODESET #endif /* 0 */ + _NL_NUM_LC_CTYPE, /* LC_MONETARY category: formatting of monetary quantities. These items each correspond to a member of `struct lconv', Index: extra/locale/programs/locale.c =================================================================== --- extra/locale/programs/locale.c (revision 0) +++ extra/locale/programs/locale.c (revision 0) @@ -0,0 +1,466 @@ +/* + * + * Copyright (c) 2008 STMicroelectronics Ltd + * Filippo Arcidiacono (filippo.arcidiacono at st.com) + * + * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. + * + * A 'locale' command implementation for uClibc. + * + */ + + +#include +#include +#include +#include +#include + +typedef struct { + unsigned char idx_name; + char dot_cs; /* 0 if no codeset specified */ + char cs; + unsigned char lc_ctype_row; + unsigned char lc_numeric_row; + unsigned char lc_monetary_row; + unsigned char lc_time_row; + unsigned char lc_collate_row; + unsigned char lc_messages_row; +} locale_entry; + +/* Need to include this before locale.h and xlocale.h! */ #include + + +#undef CODESET_LIST +#define CODESET_LIST (__locale_mmap->codeset_list) +#include +#define LOCALE_NAMES (__locale_mmap->locale_names5) +#define LOCALES (__locale_mmap->locales) +#define LOCALE_AT_MODIFIERS (__locale_mmap->locale_at_modifiers) +#define CATEGORY_NAMES (__locale_mmap->lc_names) + +#define GET_CODESET_NAME(N) (CODESET_LIST + *(CODESET_LIST + N - 3)) +#define GET_LOCALE_ENTRY(R) (locale_entry *)(LOCALES + +(__LOCALE_DATA_WIDTH_LOCALES * R)) #define GET_CATEGORY_NAME(X) (CATEGORY_NAMES + *(CATEGORY_NAMES + X)) +#define GET_LOCALE_NAME(I) (const char *)(LOCALE_NAMES + 5 * (I - 1)) + +static const char utf8[] = "UTF-8"; +static const char ascii[] = "ASCII"; + +/* If set print the name of the category. */ static int +show_category_name = 0; + +/* If set print the name of the item. */ static int show_keyword_name += 0; + +/* If set print the usage command. */ +static int show_usage = 0; + +/* Print names of all available locales. */ static int do_all = 0; + +/* Print names of all available character maps. */ static int +do_charmaps = 0; + +static int remaining = 0; + +/* We can map the types of the entries into a few categories. */ enum +value_type { + none, + string, + stringarray, + byte, + bytearray, + word, + stringlist, + wordarray, + wstring, + wstringarray, + wstringlist +}; + +/* Definition of the data structure which represents a category and its + items. */ +struct category +{ + int cat_id; + const char *name; + size_t number; + struct cat_item + { + int item_id; + const char *name; + enum { std, opt } status; + enum value_type value_type; + int min; + int max; + } *item_desc; +}; + +/* Simple helper macro. */ +#define NELEMS(arr) ((sizeof (arr)) / (sizeof (arr[0]))) + +/* For some tricky stuff. */ +#define NO_PAREN(Item, More...) Item, ## More + +/* We have all categories defined in `categories.def'. Now construct + the description and data structure used for all categories. */ +#define DEFINE_ELEMENT(Item, More...) { Item, ## More }, #define +DEFINE_CATEGORY(category, name, items, postload) \ + static struct cat_item category##_desc[] = \ + { \ + NO_PAREN items \ + }; + +#include "categories.def" +#undef DEFINE_CATEGORY + +static struct category category[] = + { +#define DEFINE_CATEGORY(category, name, items, postload) \ + [category] = { _NL_NUM_##category, name, NELEMS (category##_desc), \ + category##_desc }, +#include "categories.def" +#undef DEFINE_CATEGORY + }; +#define NCATEGORIES NELEMS (category) + +static void usage(const char *name); +static void usage(const char *name) +{ + const char *s; + + s = basename(name); + fprintf(stderr, + "Usage: %s [-ck] [--category-name] [--keyword-name] [--help] NAME\n" + "or: %s [OPTION...] [-a|-m] [--all-locales] [--charmaps] \n", s, +s); } + +static int argp_parse(int argc, char *argv[]); static int +argp_parse(int argc, char *argv[]) { + static const struct option long_options[] = + { + {"all-locales", no_argument, NULL, 'a'}, + {"charmaps", no_argument, NULL, 'm'}, + {"category-name", no_argument, NULL, 'c'}, + {"keyword-name", no_argument, NULL, 'k'}, + {"help", no_argument, NULL, 'h'}, + {NULL, 0, NULL, 0 } + }; + int c; + char *progname; + + progname = *argv; + while ((c = getopt_long (argc, argv, "amckh", long_options, NULL)) >= 0) + switch (c) + { + case 'a': + do_all = 1; + break; + case 'c': + show_category_name = 1; + break; + case 'm': + do_charmaps = 1; + break; + case 'k': + show_keyword_name = 1; + break; + case 'h': + show_usage = 1; + break; + case '?': + fprintf (stderr, "Unknown option.\n"); + usage(progname); + return 1; + + default: + fprintf (stderr, "This should never happen!\n"); + return 1; + } + + remaining = optind; + + return 0; +} + +static unsigned const char * find_at(char c); static unsigned const +char * find_at(char c) { + const unsigned char *q; + + q = LOCALE_AT_MODIFIERS; + do { + if (q[1] == c) { + return (unsigned const char *)q+2; + } + q += 2 + *q; + } while (*q); + + return NULL; +} + +static void find_locale_string(locale_entry *loc_rec, char *loc) { + char at = 0; + unsigned char idx; + uint16_t dotcs, cs; + + idx = loc_rec->idx_name; + if (!idx) { + *loc++ = 'C'; /* jump the first locale (C) */ + *loc = '\0'; + } + else { + dotcs = (uint16_t) loc_rec->dot_cs; + cs = (uint16_t) loc_rec->cs;; + loc = strncpy(loc, GET_LOCALE_NAME(idx), 5); + + if (loc[2] == '_') { + sprintf(loc, "%5.5s%c%s\0", loc, (dotcs != 0) ? '.' : ' ', + (cs == 1) ? ascii : ((cs == 2) ? utf8 : GET_CODESET_NAME(cs))); + } else { + at = loc[2]; + loc[2] = '_'; + sprintf(loc, "%5.5s%c%s@%s\0", loc, (dotcs != 0) ? '.' : ' ', + (cs == 1) ? ascii : ((cs == 2) ? utf8 : GET_CODESET_NAME(cs)), + find_at(at)); + } + } +} + +static void list_locale(void); +static void list_locale() +{ + char loc[40]; + uint16_t n = 0; + locale_entry *locales = (locale_entry *)LOCALES; + + do { + find_locale_string(locales, loc); + printf("%s\n", loc); + ++n; + locales++; + } while (n < __LOCALE_DATA_NUM_LOCALES); } + +static void list_charmaps(void); +static void list_charmaps() +{ + unsigned const char *cl; + + cl = CODESET_LIST; + do { + printf("%s\n", CODESET_LIST + *cl); + } while (*++cl); + +} + +static void print_item (struct cat_item *item); static void print_item +(struct cat_item *item) { + switch (item->value_type) + { + case string: + if (show_keyword_name) + printf ("%s=\"", item->name); + fputs (nl_langinfo (item->item_id) ? : "", stdout); + if (show_keyword_name) + putchar ('"'); + putchar ('\n'); + break; + case stringarray: + { + int cnt; + const char *val; + + if (show_keyword_name) + printf ("%s=\"", item->name); + + for (cnt = 0; cnt < item->max - 1; ++cnt) + { + val = nl_langinfo (item->item_id + cnt); + if (val != NULL) + fputs (val, stdout); + putchar (';'); + } + + val = nl_langinfo (item->item_id + cnt); + if (val != NULL) + fputs (val, stdout); + + if (show_keyword_name) + putchar ('"'); + putchar ('\n'); + } + break; + case stringlist: + { + int first = 1; + const char *val = nl_langinfo (item->item_id) ? : ""; + int cnt; + + if (show_keyword_name) + printf ("%s=", item->name); + + for (cnt = 0; cnt < item->max && *val != '\0'; ++cnt) + { + printf ("%s%s%s%s", first ? "" : ";", + show_keyword_name ? "\"" : "", val, + show_keyword_name ? "\"" : ""); + val = strchr (val, '\0') + 1; + first = 0; + } + putchar ('\n'); + } + break; + case byte: + { + const char *val = nl_langinfo (item->item_id); + + if (show_keyword_name) + printf ("%s=", item->name); + + if (val != NULL) + printf ("%d", *val == '\177' ? -1 : *val); + putchar ('\n'); + } + break; + case bytearray: + { + const char *val = nl_langinfo (item->item_id); + int cnt = val ? strlen (val) : 0; + + if (show_keyword_name) + printf ("%s=", item->name); + + while (cnt > 1) + { + printf ("%d;", *val == '\177' ? -1 : *val); + --cnt; + ++val; + } + + printf ("%d\n", cnt == 0 || *val == '\177' ? -1 : *val); + } + break; + case word: + { + union { unsigned int word; char *string; } val; + val.string = nl_langinfo (item->item_id); + if (show_keyword_name) + printf ("%s=", item->name); + + printf ("%d\n", val.word); + } + break; + case wstring: + case wstringarray: + case wstringlist: + /* We don't print wide character information since the same + information is available in a multibyte string. */ + default: + break; + + } +} + +/* Show the information request for NAME. */ static void +show_info(const char *name); static void show_info(const char *name) { + size_t cat_no, item_no; + const unsigned char *cat_name; + + /* Now all categories in an unspecified order. */ + for (cat_no = 0; cat_no < __LC_ALL; ++cat_no) { + cat_name = GET_CATEGORY_NAME(cat_no); + if (strcmp (name, (const char *)cat_name) == 0) { + if (show_category_name) + printf("%s\n", name); + + for (item_no = 0; item_no < category[cat_no].number; ++item_no) + print_item (&category[cat_no].item_desc[item_no]); + + return; + } + + for (item_no = 0; item_no < category[cat_no].number; ++item_no) + if (strcmp (name, category[cat_no].item_desc[item_no].name) == 0) { + if (show_category_name != 0) + puts (category[cat_no].name); + + print_item (&category[cat_no].item_desc[item_no]); + return; + } + } +} + +static void show_locale_vars(void); +static void show_locale_vars() +{ + size_t cat_no; + int row; /* locale row */ + const char *lcall = getenv ("LC_ALL"); + const char *lang = getenv ("LANG") ? : ""; + unsigned char *cur_loc = __global_locale->cur_locale + 1; + char loc_name[40]; + locale_entry *locales; + + /* LANG has to be the first value. */ + printf ("LANG=%s\n", lang); + + /* Now all categories in an unspecified order. */ + for (cat_no = 0; cat_no < __LC_ALL; ++cat_no) { + row = (((int)(*cur_loc & 0x7f)) << 7) + (cur_loc[1] & 0x7f); +/* assert(row < __LOCALE_DATA_NUM_LOCALES); */ + + locales = GET_LOCALE_ENTRY(row); + find_locale_string(locales, loc_name); + printf("%s=%s\n", GET_CATEGORY_NAME(cat_no), loc_name); + + cur_loc += 2; + } + + /* The last is the LC_ALL value. */ + printf ("LC_ALL=%s\n", lcall ? : ""); +} + +int +main (int argc, char *argv[]) +{ + /* Parse and process arguments. */ + if (argp_parse(argc, argv)) + return 1; + + if (do_all) { + list_locale(); + exit (EXIT_SUCCESS); + } + + if (do_charmaps) { + list_charmaps(); + exit (EXIT_SUCCESS); + } + + if (show_usage) { + usage(*argv); + exit (EXIT_SUCCESS); + } + + /* If no real argument is given we have to print the contents of the + current locale definition variables. These are LANG and the LC_*. + */ if (remaining == argc && show_category_name == 0 && show_keyword_name == 0) { + show_locale_vars (); + exit (EXIT_SUCCESS); + } + + /* Process all given names. */ + while (remaining < argc) + show_info (argv[remaining++]); + + exit (EXIT_SUCCESS); + +} Index: extra/locale/programs/categories.def =================================================================== --- extra/locale/programs/categories.def (revision 0) +++ extra/locale/programs/categories.def (revision 0) @@ -0,0 +1,357 @@ +/* + * + * Copyright (c) 2008 STMicroelectronics Ltd + * Filippo Arcidiacono (filippo.arcidiacono at st.com) + * + * Licensed under the LGPL v2.1, see the file COPYING.LIB in this tarball. + * + * Taken from glibc 2.6 + * + */ + + +/* Definition of all available locale categories and their items. -*- +C -*- + + These definitions are used by the 'locale' the program. + + The general format of the descriptions is like this: + + DEFINE_CATEGORY (ID, name, ( items ), setlocale-postload) + + where items itself is an array of entries in the form + + { ID, name, standard, value-type, min, max } + + The usage of the load, check, output functions depends on the individual + program code which loads this file. + + The various value types for the items are `string', `stringarray', `byte' + `bytearray', and `word'. These cover all possible values in the current + locale definitions. `min' and `max' can be individually used again. + */ + +#ifndef NO_POSTLOAD +#define NO_POSTLOAD NULL +#endif + +#if 0 +DEFINE_CATEGORY +( + LC_COLLATE, "LC_COLLATE", + ( + DEFINE_ELEMENT (_NL_COLLATE_NRULES, "collate-nrules", std, word) + DEFINE_ELEMENT (_NL_COLLATE_RULESETS, "collate-rulesets", std, string) + DEFINE_ELEMENT (_NL_COLLATE_TABLEMB, "collate-tablemb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_WEIGHTMB, "collate-weightmb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_EXTRAMB, "collate-extramb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_INDIRECTMB, "collate-indirectmb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_TABLEWC, "collate-tablewc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_WEIGHTWC, "collate-weightwc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_EXTRAWC, "collate-extrawc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_INDIRECTWC, "collate-indirectwc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_SYMB_HASH_SIZEMB, "collate-symb-hash-sizemb", std, word) + DEFINE_ELEMENT (_NL_COLLATE_SYMB_TABLEMB, "collate-symb-tablemb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_SYMB_EXTRAMB, "collate-symb-extramb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_COLLSEQMB, "collate-collseqmb", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_COLLSEQWC, "collate-collseqwc", std, wstring) + DEFINE_ELEMENT (_NL_COLLATE_CODESET, "collate-codeset", std, string) + ), NO_POSTLOAD) +#endif + + +/* The actual definition of ctype is meaningless here. It is hard coded in + the code because it has to be handled very specially. Only the names of + the functions and the value types are important. */ DEFINE_CATEGORY +( LC_CTYPE, "LC_CTYPE", ( #if 0 + DEFINE_ELEMENT (_NL_CTYPE_CLASS, "ctype-class", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TOUPPER, "ctype-toupper", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TOLOWER, "ctype-tolower", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_CLASS32, "ctype-class32", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_CLASS_NAMES, "ctype-class-names", std, stringlist, 10, 32) + DEFINE_ELEMENT (_NL_CTYPE_MAP_NAMES, "ctype-map-names", std, stringlist, 2, 32) + DEFINE_ELEMENT (_NL_CTYPE_WIDTH, "ctype-width", std, bytearray) + DEFINE_ELEMENT (_NL_CTYPE_MB_CUR_MAX, "ctype-mb-cur-max", std, word) + DEFINE_ELEMENT (_NL_CTYPE_CODESET_NAME, "charmap", std, string) + DEFINE_ELEMENT (_NL_CTYPE_TOUPPER32, "ctype-toupper32", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TOLOWER32, "ctype-tolower32", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_CLASS_OFFSET, "ctype-class-offset", std, word) + DEFINE_ELEMENT (_NL_CTYPE_MAP_OFFSET, "ctype-map-offset", std, word) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS_MB_LEN, "ctype-indigits_mb-len", +std, word) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS0_MB, "ctype-indigits0_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS1_MB, "ctype-indigits1_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS2_MB, "ctype-indigits2_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS3_MB, "ctype-indigits3_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS4_MB, "ctype-indigits4_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS5_MB, "ctype-indigits5_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS6_MB, "ctype-indigits6_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS7_MB, "ctype-indigits7_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS8_MB, "ctype-indigits8_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS9_MB, "ctype-indigits9_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS_WC_LEN, "ctype-indigits_wc-len", +std, word) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS0_WC, "ctype-indigits0_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS1_WC, "ctype-indigits1_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS2_WC, "ctype-indigits2_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS3_WC, "ctype-indigits3_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS4_WC, "ctype-indigits4_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS5_WC, "ctype-indigits5_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS6_WC, "ctype-indigits6_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS7_WC, "ctype-indigits7_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS8_WC, "ctype-indigits8_wc", std, +wstring) + DEFINE_ELEMENT (_NL_CTYPE_INDIGITS9_WC, "ctype-indigits9_wc", std, +wstring) #endif + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT0_MB, "ctype-outdigit0_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT1_MB, "ctype-outdigit1_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT2_MB, "ctype-outdigit2_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT3_MB, "ctype-outdigit3_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT4_MB, "ctype-outdigit4_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT5_MB, "ctype-outdigit5_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT6_MB, "ctype-outdigit6_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT7_MB, "ctype-outdigit7_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT8_MB, "ctype-outdigit8_mb", std, +string) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT9_MB, "ctype-outdigit9_mb", std, +string) #if 0 + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT0_WC, "ctype-outdigit0_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT1_WC, "ctype-outdigit1_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT2_WC, "ctype-outdigit2_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT3_WC, "ctype-outdigit3_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT4_WC, "ctype-outdigit4_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT5_WC, "ctype-outdigit5_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT6_WC, "ctype-outdigit6_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT7_WC, "ctype-outdigit7_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT8_WC, "ctype-outdigit8_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_OUTDIGIT9_WC, "ctype-outdigit9_wc", std, +word) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_TAB_SIZE, +"ctype-translit-tab-size", std, word) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_FROM_IDX, +"ctype-translit-from-idx", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_FROM_TBL, +"ctype-translit-from-tbl", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_TO_IDX, "ctype-translit-to-idx", +std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_TO_TBL, "ctype-translit-to-tbl", +std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_DEFAULT_MISSING_LEN, +"ctype-translit-default-missing-len", std, word) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_DEFAULT_MISSING, +"ctype-translit-default-missing", std, wstring) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_IGNORE_LEN, +"ctype-translit-ignore-len", std, word) + DEFINE_ELEMENT (_NL_CTYPE_TRANSLIT_IGNORE, "ctype-translit-ignore", +std, string) + DEFINE_ELEMENT (_NL_CTYPE_MAP_TO_NONASCII, "map-to-nonascii", std, +word) #endif + ), _nl_postload_ctype) + + +DEFINE_CATEGORY +( + LC_MONETARY, "LC_MONETARY", + ( + DEFINE_ELEMENT (INT_CURR_SYMBOL, "int_curr_symbol", std, string) + DEFINE_ELEMENT (CURRENCY_SYMBOL, "currency_symbol", std, string) + DEFINE_ELEMENT (MON_DECIMAL_POINT, "mon_decimal_point", std, string) + DEFINE_ELEMENT (MON_THOUSANDS_SEP, "mon_thousands_sep", std, string) + DEFINE_ELEMENT (MON_GROUPING, "mon_grouping", std, bytearray) + DEFINE_ELEMENT (POSITIVE_SIGN, "positive_sign", std, string) + DEFINE_ELEMENT (NEGATIVE_SIGN, "negative_sign", std, string) + DEFINE_ELEMENT (INT_FRAC_DIGITS, "int_frac_digits", std, byte) + DEFINE_ELEMENT (FRAC_DIGITS, "frac_digits", std, byte) + DEFINE_ELEMENT (P_CS_PRECEDES, "p_cs_precedes", std, byte, 0, 1) + DEFINE_ELEMENT (P_SEP_BY_SPACE, "p_sep_by_space", std, byte, 0, 2) + DEFINE_ELEMENT (N_CS_PRECEDES, "n_cs_precedes", std, byte, 0, 1) + DEFINE_ELEMENT (N_SEP_BY_SPACE, "n_sep_by_space", std, byte, 0, 2) + DEFINE_ELEMENT (P_SIGN_POSN, "p_sign_posn", std, byte, 0, 4) + DEFINE_ELEMENT (N_SIGN_POSN, "n_sign_posn", std, byte, 0, 4) + DEFINE_ELEMENT (__INT_P_CS_PRECEDES, "int_p_cs_precedes", std, byte, 0, 1) + DEFINE_ELEMENT (__INT_P_SEP_BY_SPACE, "int_p_sep_by_space", std, byte, 0, 2) + DEFINE_ELEMENT (__INT_N_CS_PRECEDES, "int_n_cs_precedes", std, byte, 0, 1) + DEFINE_ELEMENT (__INT_N_SEP_BY_SPACE, "int_n_sep_by_space", std, byte, 0, 2) + DEFINE_ELEMENT (__INT_P_SIGN_POSN, "int_p_sign_posn", std, byte, 0, 4) + DEFINE_ELEMENT (__INT_N_SIGN_POSN, "int_n_sign_posn", std, byte, 0, 4) +#if 0 + DEFINE_ELEMENT (_NL_MONETARY_DUO_INT_CURR_SYMBOL, "duo_int_curr_symbol", std, string) + DEFINE_ELEMENT (_NL_MONETARY_DUO_CURRENCY_SYMBOL, "duo_currency_symbol", std, string) + DEFINE_ELEMENT (_NL_MONETARY_DUO_INT_FRAC_DIGITS, "duo_int_frac_digits", std, byte) + DEFINE_ELEMENT (_NL_MONETARY_DUO_FRAC_DIGITS, "duo_frac_digits", std, byte) + DEFINE_ELEMENT (_NL_MONETARY_DUO_P_CS_PRECEDES, "duo_p_cs_precedes", std, byte, 0, 1) + DEFINE_ELEMENT (_NL_MONETARY_DUO_P_SEP_BY_SPACE, "duo_p_sep_by_space", std, byte, 0, 2) + DEFINE_ELEMENT (_NL_MONETARY_DUO_N_CS_PRECEDES, "duo_n_cs_precedes", std, byte, 0, 1) + DEFINE_ELEMENT (_NL_MONETARY_DUO_N_SEP_BY_SPACE, "duo_n_sep_by_space", std, byte, 0, 2) + DEFINE_ELEMENT (_NL_MONETARY_DUO_INT_P_CS_PRECEDES, +"duo_int_p_cs_precedes", std, byte, 0, 1) + DEFINE_ELEMENT (_NL_MONETARY_DUO_INT_P_SEP_BY_SPACE, +"duo_int_p_sep_by_space", std, byte, 0, 2) + DEFINE_ELEMENT (_NL_MONETARY_DUO_INT_N_CS_PRECEDES, +"duo_int_n_cs_precedes", std, byte, 0, 1) + DEFINE_ELEMENT (_NL_MONETARY_DUO_INT_N_SEP_BY_SPACE, "duo_int_n_sep_by_space", std, byte, 0, 2) + DEFINE_ELEMENT (_NL_MONETARY_DUO_P_SIGN_POSN, "duo_p_sign_posn", std, byte, 0, 4) + DEFINE_ELEMENT (_NL_MONETARY_DUO_N_SIGN_POSN, "duo_n_sign_posn", std, byte, 0, 4) + DEFINE_ELEMENT (_NL_MONETARY_DUO_INT_P_SIGN_POSN, "duo_int_p_sign_posn", std, byte, 0, 4) + DEFINE_ELEMENT (_NL_MONETARY_DUO_INT_N_SIGN_POSN, "duo_int_n_sign_posn", std, byte, 0, 4) + DEFINE_ELEMENT (_NL_MONETARY_UNO_VALID_FROM, "uno_valid_from", std, word) + DEFINE_ELEMENT (_NL_MONETARY_UNO_VALID_TO, "uno_valid_to", std, word) + DEFINE_ELEMENT (_NL_MONETARY_DUO_VALID_FROM, "duo_valid_from", std, word) + DEFINE_ELEMENT (_NL_MONETARY_DUO_VALID_TO, "duo_valid_to", std, word) + DEFINE_ELEMENT (_NL_MONETARY_CONVERSION_RATE, "conversion_rate", std, wordarray, 2, 2) + DEFINE_ELEMENT (_NL_MONETARY_DECIMAL_POINT_WC, "monetary-decimal-point-wc", std, word) + DEFINE_ELEMENT (_NL_MONETARY_THOUSANDS_SEP_WC, "monetary-thousands-sep-wc", std, word) + DEFINE_ELEMENT (_NL_MONETARY_CODESET, "monetary-codeset", std, string) +#else + DEFINE_ELEMENT (_NL_MONETARY_CRNCYSTR, "monetary-crncystr", std, string) +#endif + ), NO_POSTLOAD) + + +DEFINE_CATEGORY +( + LC_NUMERIC, "LC_NUMERIC", + ( + DEFINE_ELEMENT (DECIMAL_POINT, "decimal_point", std, string) + DEFINE_ELEMENT (THOUSANDS_SEP, "thousands_sep", std, string) + DEFINE_ELEMENT (GROUPING, "grouping", std, bytearray) +#if 0 + DEFINE_ELEMENT (_NL_NUMERIC_DECIMAL_POINT_WC, +"numeric-decimal-point-wc", std, word) + DEFINE_ELEMENT (_NL_NUMERIC_THOUSANDS_SEP_WC, "numeric-thousands-sep-wc", std, word) + DEFINE_ELEMENT (_NL_NUMERIC_CODESET, "numeric-codeset", std, string) +#endif + + ), NO_POSTLOAD) + + +DEFINE_CATEGORY +( + LC_TIME, "LC_TIME", + ( + DEFINE_ELEMENT (ABDAY_1, "abday", std, stringarray, 7, 7) + DEFINE_ELEMENT (DAY_1, "day", std, stringarray, 7, 7) + DEFINE_ELEMENT (ABMON_1, "abmon", std, stringarray, 12, 12) + DEFINE_ELEMENT (MON_1, "mon", std, stringarray, 12, 12) + DEFINE_ELEMENT (AM_STR, "am_pm", std, stringarray, 2, 2) + DEFINE_ELEMENT (D_T_FMT, "d_t_fmt", std, string) + DEFINE_ELEMENT (D_FMT, "d_fmt", std, string) + DEFINE_ELEMENT (T_FMT, "t_fmt", std, string) + DEFINE_ELEMENT (T_FMT_AMPM, "t_fmt_ampm", std, string) + DEFINE_ELEMENT (ERA, "era", opt, stringlist, 0, 100) + DEFINE_ELEMENT (ERA_YEAR, "era_year", opt, string) + DEFINE_ELEMENT (ERA_D_FMT, "era_d_fmt", opt, string) + DEFINE_ELEMENT (ALT_DIGITS, "alt_digits", opt, stringlist, 100, +100) + DEFINE_ELEMENT (ERA_D_T_FMT, "era_d_t_fmt", opt, string) + DEFINE_ELEMENT (ERA_T_FMT, "era_t_fmt", opt, string) +#if 0 + DEFINE_ELEMENT (_NL_TIME_ERA_NUM_ENTRIES, "time-era-num-entries", opt, word) + DEFINE_ELEMENT (_NL_TIME_ERA_ENTRIES, "time-era-entries", opt, string) + DEFINE_ELEMENT (_NL_WABDAY_1, "wide-abday", std, wstringarray, 7, 7) + DEFINE_ELEMENT (_NL_WDAY_1, "wide-day", std, wstringarray, 7, 7) + DEFINE_ELEMENT (_NL_WABMON_1, "wide-abmon", std, wstringarray, 12, 12) + DEFINE_ELEMENT (_NL_WMON_1, "wide-mon", std, wstringarray, 12, 12) + DEFINE_ELEMENT (_NL_WAM_STR, "wide-am_pm", std, wstringarray, 2, 2) + DEFINE_ELEMENT (_NL_WD_T_FMT, "wide-d_t_fmt", std, wstring) + DEFINE_ELEMENT (_NL_WD_FMT, "wide-d_fmt", std, wstring) + DEFINE_ELEMENT (_NL_WT_FMT, "wide-t_fmt", std, wstring) + DEFINE_ELEMENT (_NL_WT_FMT_AMPM, "wide-t_fmt_ampm", std, wstring) + DEFINE_ELEMENT (_NL_WERA_YEAR, "wide-era_year", opt, wstring) + DEFINE_ELEMENT (_NL_WERA_D_FMT, "wide-era_d_fmt", opt, wstring) + DEFINE_ELEMENT (_NL_WALT_DIGITS, "wide-alt_digits", opt, +wstringlist, 1000, 100) + DEFINE_ELEMENT (_NL_WERA_D_T_FMT, "wide-era_d_t_fmt", opt, wstring) + DEFINE_ELEMENT (_NL_WERA_T_FMT, "wide-era_t_fmt", opt, wstring) + DEFINE_ELEMENT (_NL_TIME_WEEK_NDAYS, "week-ndays", std, byte) + DEFINE_ELEMENT (_NL_TIME_WEEK_1STDAY, "week-1stday", std, word) + DEFINE_ELEMENT (_NL_TIME_WEEK_1STWEEK, "week-1stweek", std, byte) + DEFINE_ELEMENT (_NL_TIME_FIRST_WEEKDAY, "first_weekday", std, byte) + DEFINE_ELEMENT (_NL_TIME_FIRST_WORKDAY, "first_workday", std, byte) + DEFINE_ELEMENT (_NL_TIME_CAL_DIRECTION, "cal_direction", std, byte) + DEFINE_ELEMENT (_NL_TIME_TIMEZONE, "timezone", std, string) + DEFINE_ELEMENT (_DATE_FMT, "date_fmt", opt, string) + DEFINE_ELEMENT (_NL_W_DATE_FMT, "wide-date_fmt", opt, wstring) + DEFINE_ELEMENT (_NL_TIME_CODESET, "time-codeset", std, string) +#endif + ), NO_POSTLOAD) + + +DEFINE_CATEGORY +( + LC_MESSAGES, "LC_MESSAGES", + ( + DEFINE_ELEMENT (YESEXPR, "yesexpr", std, string) + DEFINE_ELEMENT (NOEXPR, "noexpr", std, string) + DEFINE_ELEMENT (YESSTR, "yesstr", opt, string) + DEFINE_ELEMENT (NOSTR, "nostr", opt, string) +#if 0 + DEFINE_ELEMENT (_NL_MESSAGES_CODESET, "messages-codeset", std, +string) #endif + ), NO_POSTLOAD) + +#if 0 +DEFINE_CATEGORY +( + LC_PAPER, "LC_PAPER", + ( + DEFINE_ELEMENT (_NL_PAPER_HEIGHT, "height", std, word) + DEFINE_ELEMENT (_NL_PAPER_WIDTH, "width", std, word) + DEFINE_ELEMENT (_NL_PAPER_CODESET, "paper-codeset", std, string) + ), NO_POSTLOAD) + +DEFINE_CATEGORY +( + LC_NAME, "LC_NAME", + ( + DEFINE_ELEMENT (_NL_NAME_NAME_FMT, "name_fmt", std, string) + DEFINE_ELEMENT (_NL_NAME_NAME_GEN, "name_gen", std, string) + DEFINE_ELEMENT (_NL_NAME_NAME_MR, "name_mr", std, string) + DEFINE_ELEMENT (_NL_NAME_NAME_MRS, "name_mrs", std, string) + DEFINE_ELEMENT (_NL_NAME_NAME_MISS, "name_miss", std, string) + DEFINE_ELEMENT (_NL_NAME_NAME_MS, "name_ms", std, string) + DEFINE_ELEMENT (_NL_NAME_CODESET, "name-codeset", std, string) + ), NO_POSTLOAD) + +DEFINE_CATEGORY +( + LC_ADDRESS, "LC_ADDRESS", + ( + DEFINE_ELEMENT (_NL_ADDRESS_POSTAL_FMT, "postal_fmt", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_COUNTRY_NAME, "country_name", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_COUNTRY_POST, "country_post", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_COUNTRY_AB2, "country_ab2", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_COUNTRY_AB3, "country_ab3", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_COUNTRY_CAR, "country_car", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_COUNTRY_NUM, "country_num", std, word) + DEFINE_ELEMENT (_NL_ADDRESS_COUNTRY_ISBN, "country_isbn", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_LANG_NAME, "lang_name", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_LANG_AB, "lang_ab", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_LANG_TERM, "lang_term", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_LANG_LIB, "lang_lib", std, string) + DEFINE_ELEMENT (_NL_ADDRESS_CODESET, "address-codeset", std, string) + ), NO_POSTLOAD) + +DEFINE_CATEGORY +( + LC_TELEPHONE, "LC_TELEPHONE", + ( + DEFINE_ELEMENT (_NL_TELEPHONE_TEL_INT_FMT, "tel_int_fmt", std, +string) + DEFINE_ELEMENT (_NL_TELEPHONE_TEL_DOM_FMT, "tel_dom_fmt", std, +string) + DEFINE_ELEMENT (_NL_TELEPHONE_INT_SELECT, "int_select", std, +string) + DEFINE_ELEMENT (_NL_TELEPHONE_INT_PREFIX, "int_prefix", std, string) + DEFINE_ELEMENT (_NL_TELEPHONE_CODESET, "telephone-codeset", std, string) + ), NO_POSTLOAD) + +DEFINE_CATEGORY +( + LC_MEASUREMENT, "LC_MEASUREMENT", + ( + DEFINE_ELEMENT (_NL_MEASUREMENT_MEASUREMENT, "measurement", std, byte) + DEFINE_ELEMENT (_NL_MEASUREMENT_CODESET, "measurement-codeset", std, string) + ), NO_POSTLOAD) + +DEFINE_CATEGORY +( + LC_IDENTIFICATION, "LC_IDENTIFICATION", ( + DEFINE_ELEMENT (_NL_IDENTIFICATION_TITLE, "title", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_SOURCE, "source", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_ADDRESS, "address", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_CONTACT, "contact", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_EMAIL, "email", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_TEL, "tel", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_FAX, "fax", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_LANGUAGE, "language", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_TERRITORY, "territory", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_AUDIENCE, "audience", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_APPLICATION, "application", std, +string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_ABBREVIATION, "abbreviation", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_REVISION, "revision", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_DATE, "date", std, string) + DEFINE_ELEMENT (_NL_IDENTIFICATION_CATEGORY, "category", std, stringarray, 13, 13) + DEFINE_ELEMENT (_NL_IDENTIFICATION_CODESET, "identification-codeset", std, string) + ), NO_POSTLOAD) +#endif From raj.khem at gmail.com Fri May 2 22:48:17 2008 From: raj.khem at gmail.com (Khem Raj) Date: Fri, 2 May 2008 22:48:17 -0700 Subject: [PATCH] splice, vmsplice and tee for i386 In-Reply-To: <20080502071857.GA14696@mx.loc> References: <480C5F87.3060707@iki.fi> <50BF37ECE4954A4BA18C08D0C2CF88CB0411EDB1@exmail1.se.axis.com> <480E2657.1030703@iki.fi> <480E2AFE.8080706@mvista.com> <20080422201238.GA10167@mx.loc> <481071F7.5020201@iki.fi> <20080424124759.GA9754@mx.loc> <481183B5.5030402@iki.fi> <481AAED8.9090003@iki.fi> <20080502071857.GA14696@mx.loc> Message-ID: <19c1b8a90805022248g51cef47di6e31c9db48e576ed@mail.gmail.com> Hi We need to patch fcntl.h for all architectures where these syscalls are wired up in kernel, otherwise it will break the build for those architectures. I have already patched up arm with the attached patch and tested it. I did not patch others Thanks -Khem On Fri, May 2, 2008 at 12:18 AM, Bernhard Fischer wrote: > On Fri, May 02, 2008 at 09:04:08AM +0300, Timo Ter?s wrote: > > >IMHO, this is good to commit. Any objections? > > Applied. Thanks! > > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > -------------- next part -------------- A non-text attachment was scrubbed... Name: diff Type: application/octet-stream Size: 2479 bytes Desc: not available Url : http://busybox.net/lists/uclibc/attachments/20080502/7dbdf314/attachment.obj From raj.khem at gmail.com Fri May 2 22:58:29 2008 From: raj.khem at gmail.com (Khem Raj) Date: Fri, 02 May 2008 22:58:29 -0700 Subject: RFC: first stab at getting rid of libc_hidden_proto() forest In-Reply-To: <200805011413.31762.vda.linux@googlemail.com> References: <200804120407.07311.vda.linux@googlemail.com> <19c1b8a90805010304n7a6cc057p8d5350c43ca97f1a@mail.gmail.com> <1209637371.9205.5.camel@isis> <200805011413.31762.vda.linux@googlemail.com> Message-ID: <1209794310.26129.2.camel@isis> On Thu, 2008-05-01 at 14:13 +0200, Denys Vlasenko wrote: > On Thursday 01 May 2008 12:22, Khem Raj wrote: > > Hi Denys > > > > In the new script to install headers. We assume that unifdef fails if > > the return is not 0. However as per the manpages of unifdef I see this > > > > The unifdef utility exits 0 if the output is an exact copy of the input, > > 1 if not, and 2 if in trouble. > > > > I have fixed the script so that it only exits when the return code from > > unifdef command is 2. > > > > OK? > > Well, I just removed "|| exit". ok cool. I tested it works now. I was able to compile a whole lot of applications all works well. > > Thanks for debugging! > -- > vda -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://busybox.net/lists/uclibc/attachments/20080502/d1e47255/attachment.pgp From carmelo73 at gmail.com Fri May 2 23:33:11 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sat, 03 May 2008 08:33:11 +0200 Subject: [PATCH] splice, vmsplice and tee for i386 In-Reply-To: <19c1b8a90805022248g51cef47di6e31c9db48e576ed@mail.gmail.com> References: <480C5F87.3060707@iki.fi> <50BF37ECE4954A4BA18C08D0C2CF88CB0411EDB1@exmail1.se.axis.com> <480E2657.1030703@iki.fi> <480E2AFE.8080706@mvista.com> <20080422201238.GA10167@mx.loc> <481071F7.5020201@iki.fi> <20080424124759.GA9754@mx.loc> <481183B5.5030402@iki.fi> <481AAED8.9090003@iki.fi> <20080502071857.GA14696@mx.loc> <19c1b8a90805022248g51cef47di6e31c9db48e576ed@mail.gmail.com> Message-ID: <481C0727.2060101@gmail.com> Khem Raj wrote: > Hi > > We need to patch fcntl.h for all architectures where these syscalls > are wired up in kernel, otherwise it will break the build for those > architectures. I have already patched up arm > with the attached patch and tested it. I did not patch others > > Thanks > > -Khem > > Yes, indeed after having updated my working copy, sh4 build was broken. I'll do the same for sh4. I think who committed the patch for splice & co should do the fix for all other archs. Thanks, Carmelo > > > On Fri, May 2, 2008 at 12:18 AM, Bernhard Fischer wrote: >> On Fri, May 02, 2008 at 09:04:08AM +0300, Timo Ter?s wrote: >> >> >IMHO, this is good to commit. Any objections? >> >> Applied. Thanks! >> >> >> _______________________________________________ >> uClibc mailing list >> uClibc at uclibc.org >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> uClibc mailing list >> uClibc at uclibc.org >> http://busybox.net/cgi-bin/mailman/listinfo/uclibc From rep.dot.nop at gmail.com Sat May 3 05:16:41 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Sat, 3 May 2008 14:16:41 +0200 Subject: [PATCH] splice, vmsplice and tee for i386 In-Reply-To: <481C0727.2060101@gmail.com> References: <480E2657.1030703@iki.fi> <480E2AFE.8080706@mvista.com> <20080422201238.GA10167@mx.loc> <481071F7.5020201@iki.fi> <20080424124759.GA9754@mx.loc> <481183B5.5030402@iki.fi> <481AAED8.9090003@iki.fi> <20080502071857.GA14696@mx.loc> <19c1b8a90805022248g51cef47di6e31c9db48e576ed@mail.gmail.com> <481C0727.2060101@gmail.com> Message-ID: <20080503121641.GC9589@mx.loc> On Sat, May 03, 2008 at 08:33:11AM +0200, Carmelo Amoroso wrote: > Khem Raj wrote: >> Hi >> >> We need to patch fcntl.h for all architectures where these syscalls >> are wired up in kernel, otherwise it will break the build for those >> architectures. I have already patched up arm >> with the attached patch and tested it. I did not patch others >> >> Thanks >> >> -Khem >> >> > Yes, indeed after having updated my working copy, > sh4 build was broken. > > I'll do the same for sh4. > I think who committed the patch for splice & co should do the > fix for all other archs. Oh sorry, forgot about the rest. I will fix them up in a minute.. From dhylands at gmail.com Sun May 4 01:22:35 2008 From: dhylands at gmail.com (Dave Hylands) Date: Sun, 4 May 2008 01:22:35 -0700 Subject: Bug? related to fork and pthreads Message-ID: Hi, I've stumbled on what appears to be a problem with pthreads. I'm using what I believe is a version of 0.9.29 with the linuxthreads.old variant with libpthread as a shared library (it came from Wind River - so I'm not 100% sure on the version). If my program calls fork, then __pthread_reset_main_thread gets called, and everything seems to behave correctly. However, if my program calls daemon (which also calls fork) then __pthread_reset_main_thread doesn't get called. This causes pthread_create's which are called after daemon is called to hang, since the wrong thread gets signalled. pthread_create trys to signal the original initial thread which existed before the daemon call was made. I've done a kludge by having pthread_create do: self->p_pid = getpid(); before sending the request which allows my program to work, but I'm not sure what the correct fix should be. -- Dave Hylands Vancouver, BC, Canada http://www.DaveHylands.com/ From carmelo73 at gmail.com Sun May 4 05:58:52 2008 From: carmelo73 at gmail.com (Carmelo Amoroso) Date: Sun, 04 May 2008 14:58:52 +0200 Subject: Bug? related to fork and pthreads In-Reply-To: References: Message-ID: <481DB30C.5090500@gmail.com> Dave Hylands wrote: > Hi, > > I've stumbled on what appears to be a problem with pthreads. > I'm using what I believe is a version of 0.9.29 with the > linuxthreads.old variant with libpthread as a shared library (it came > from Wind River - so I'm not 100% sure on the version). > > If my program calls fork, then __pthread_reset_main_thread gets > called, and everything seems to behave correctly. > > However, if my program calls daemon (which also calls fork) then > __pthread_reset_main_thread doesn't get called. > > This causes pthread_create's which are called after daemon is called > to hang, since the wrong thread gets signalled. > pthread_create trys to signal the original initial thread which > existed before the daemon call was made. > > I've done a kludge by having pthread_create do: > > self->p_pid = getpid(); > > before sending the request which allows my program to work, but I'm > not sure what the correct fix should be. > Hello, i'm not totally sure, but linuxthreads implementation suffer of problems when using threads and signal, and your scenario seems to be fitting perfectly in this context.... this was one of the main reason for which NPTL was developed, among some others... so, if I'm right, your problem cannot be solved unless you'll have an nptl implementation. Carmelo From carmelo.amoroso at st.com Wed May 7 00:49:35 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 07 May 2008 09:49:35 +0200 Subject: svn commit: trunk/uClibc: extra/scripts In-Reply-To: <20080427231001.427983C8A9@busybox.net> References: <20080427231001.427983C8A9@busybox.net> Message-ID: <48215F0F.2090209@st.com> Hello, just some comments... vda at uclibc.org wrote: > Author: vda > Date: 2008-04-27 16:10:00 -0700 (Sun, 27 Apr 2008) > New Revision: 21880 > > Log: > build system: improve install_headers. > Now it uses dedicated script instead of inline makefile commands, > which helps readability. > ok, tha's fine for me > It also installs asm[-generic] and linux subdirs from kernel headers > (previously it had to be done separately). > why ? I'd disagree with this choice.... it brakes some more complex build system where kernel-headers are installed in other way (i.e. rpm based build system). are there have been discussion on the list about this change... if yes, please give me the link... likely I've missed during my last holidays some posts. otherwise, I'd like to open a discussion on this. > Lastly, it passes each uclibc header thru unifdef, which strips > #ifdef UCLIBC_INTERNAL conditional from headers. > > Currently it's a no-op (no such #ifders in tree). > The plan is to have libc_hidden_proto(foo) migrated to headers > and guard them by these #ifdefs. > so, the final choice was to use this approach.. just for confirmation. Thanks, Carmelo > > > Added: > trunk/uClibc/extra/scripts/install_headers.sh > trunk/uClibc/extra/scripts/unifdef.c > > Modified: > trunk/uClibc/Makefile.in > > > Changeset: > > Sorry, the patch is too large to include (1144 lines). > Please use ViewCVS to see it! > > http://uclibc.org/cgi-bin/viewcvs.cgi?view=rev&root=svn&rev=21880 > _______________________________________________ > uClibc-cvs mailing list > uClibc-cvs at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs > > From vda.linux at googlemail.com Wed May 7 02:36:01 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 May 2008 11:36:01 +0200 Subject: svn commit: trunk/uClibc: extra/scripts In-Reply-To: <48215F0F.2090209@st.com> References: <20080427231001.427983C8A9@busybox.net> <48215F0F.2090209@st.com> Message-ID: <200805071136.01702.vda.linux@googlemail.com> On Wednesday 07 May 2008 09:49, Carmelo AMOROSO wrote: > Hello, just some comments... > > It also installs asm[-generic] and linux subdirs from kernel headers > > (previously it had to be done separately). > > why ? I'd disagree with this choice.... it brakes some more complex > build system > where kernel-headers are installed in other way (i.e. rpm based build > system). I found it usefult. Before this, I had to copy kernel headers to installed uclibc' include dir by hand. Every time. Not funny. If one builds his libc against a set of kernel headers X he's better not use built libc and its headers with different set of kernel headers Y! Sure, kernel is supposed to provide stable API, but this inevitably breaks in some more obscure corners. Having said that, I understand that this constitutes a change from previous behavior. I propose introducing "make install_kernel_headers" for those who needs it. Is this acceptable for you? > > Lastly, it passes each uclibc header thru unifdef, which strips > > #ifdef UCLIBC_INTERNAL conditional from headers. > > > > Currently it's a no-op (no such #ifders in tree). > > The plan is to have libc_hidden_proto(foo) migrated to headers > > and guard them by these #ifdefs. > > so, the final choice was to use this approach.. just for confirmation. Yes. This will also trivially extendable to remove other extraneous/internal stuff, for example: ./nl_types.h:#ifdef __UCLIBC_MJN3_ONLY__ ./time.h:#ifdef __UCLIBC_MJN3_ONLY__ ./time.h:#ifdef __UCLIBC_MJN3_ONLY__ ./time.h:#ifdef __UCLIBC_MJN3_ONLY__ -- vda From carmelo.amoroso at st.com Wed May 7 02:47:47 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 07 May 2008 11:47:47 +0200 Subject: svn commit: trunk/uClibc: extra/scripts In-Reply-To: <200805071136.01702.vda.linux@googlemail.com> References: <20080427231001.427983C8A9@busybox.net> <48215F0F.2090209@st.com> <200805071136.01702.vda.linux@googlemail.com> Message-ID: <48217AC3.8010507@st.com> Denys Vlasenko wrote: > On Wednesday 07 May 2008 09:49, Carmelo AMOROSO wrote: > >> Hello, just some comments... >> > > >>> It also installs asm[-generic] and linux subdirs from kernel headers >>> (previously it had to be done separately). >>> >> why ? I'd disagree with this choice.... it brakes some more complex >> build system >> where kernel-headers are installed in other way (i.e. rpm based build >> system). >> > > I found it usefult. Before this, I had to copy kernel headers > to installed uclibc' include dir by hand. Every time. Not funny. > > If one builds his libc against a set of kernel headers X he's better > not use built libc and its headers with different set of kernel headers Y! > Sure, kernel is supposed to provide stable API, but this inevitably > breaks in some more obscure corners. > > Having said that, I understand that this constitutes a change > from previous behavior. > > I propose introducing "make install_kernel_headers" > for those who needs it. > > Is this acceptable for you? > > Hi Denis, thanks for your explanation... yes this sounds good me. So who need to install only libc headers, will call make install_headers... who needs both will call make install_kernel_headers too. I think it's more flexible. Thanks, Carmelo >>> Lastly, it passes each uclibc header thru unifdef, which strips >>> #ifdef UCLIBC_INTERNAL conditional from headers. >>> >>> Currently it's a no-op (no such #ifders in tree). >>> The plan is to have libc_hidden_proto(foo) migrated to headers >>> and guard them by these #ifdefs. >>> >> so, the final choice was to use this approach.. just for confirmation. >> > > Yes. > > This will also trivially extendable to remove other extraneous/internal > stuff, for example: > > ./nl_types.h:#ifdef __UCLIBC_MJN3_ONLY__ > ./time.h:#ifdef __UCLIBC_MJN3_ONLY__ > ./time.h:#ifdef __UCLIBC_MJN3_ONLY__ > ./time.h:#ifdef __UCLIBC_MJN3_ONLY__ > > -- > vda > > From vda.linux at googlemail.com Wed May 7 06:01:59 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 May 2008 15:01:59 +0200 Subject: svn commit: trunk/uClibc: extra/scripts In-Reply-To: <48217AC3.8010507@st.com> References: <20080427231001.427983C8A9@busybox.net> <200805071136.01702.vda.linux@googlemail.com> <48217AC3.8010507@st.com> Message-ID: <200805071501.59602.vda.linux@googlemail.com> On Wednesday 07 May 2008 11:47, Carmelo AMOROSO wrote: > >>> It also installs asm[-generic] and linux subdirs from kernel headers > >>> (previously it had to be done separately). > >>> > >> why ? I'd disagree with this choice.... it brakes some more complex > >> build system > >> where kernel-headers are installed in other way (i.e. rpm based build > >> system). > >> > > > > I found it usefult. Before this, I had to copy kernel headers > > to installed uclibc' include dir by hand. Every time. Not funny. > > > > If one builds his libc against a set of kernel headers X he's better > > not use built libc and its headers with different set of kernel headers Y! > > Sure, kernel is supposed to provide stable API, but this inevitably > > breaks in some more obscure corners. > > > > Having said that, I understand that this constitutes a change > > from previous behavior. > > > > I propose introducing "make install_kernel_headers" > > for those who needs it. > > > > Is this acceptable for you? > > > > > Hi Denis, > thanks for your explanation... yes this sounds good me. > So who need to install only libc headers, will call make > install_headers... who needs both > will call make install_kernel_headers too. > I think it's more flexible. Fixed in svn. Thanks -- vda From kraj at mvista.com Wed May 7 08:14:35 2008 From: kraj at mvista.com (Khem Raj) Date: Wed, 07 May 2008 08:14:35 -0700 Subject: svn commit: trunk/uClibc: extra/scripts In-Reply-To: <200805071136.01702.vda.linux@googlemail.com> References: <20080427231001.427983C8A9@busybox.net> <48215F0F.2090209@st.com> <200805071136.01702.vda.linux@googlemail.com> Message-ID: <4821C75B.6060308@mvista.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Denys Vlasenko wrote: > On Wednesday 07 May 2008 09:49, Carmelo AMOROSO wrote: >> Hello, just some comments... > >>> It also installs asm[-generic] and linux subdirs from kernel headers >>> (previously it had to be done separately). >> why ? I'd disagree with this choice.... it brakes some more complex >> build system >> where kernel-headers are installed in other way (i.e. rpm based build >> system). > > I found it usefult. Before this, I had to copy kernel headers > to installed uclibc' include dir by hand. Every time. Not funny. btw. what we need are sanitized kernel headers ( which we get by doing make headers_install from linux kernel srcs).Copying might work but not the right way I guess with newer kernels. > > If one builds his libc against a set of kernel headers X he's better > not use built libc and its headers with different set of kernel headers Y! > Sure, kernel is supposed to provide stable API, but this inevitably > breaks in some more obscure corners. > > Having said that, I understand that this constitutes a change > from previous behavior. > > I propose introducing "make install_kernel_headers" > for those who needs it. > > Is this acceptable for you? This sounds ok. - -- Khem Raj MontaVista Software Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIIcdbUjbQJxVzeZQRAlDiAKCEl/XRl5JOv5SL4E+a2D1zeuGm0gCfR/Hu irI+Rniz0U/hKiesPgj8Nf0= =qdN1 -----END PGP SIGNATURE----- From carmelo.amoroso at st.com Wed May 7 08:30:09 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 07 May 2008 17:30:09 +0200 Subject: svn commit: trunk/uClibc: extra/scripts In-Reply-To: <4821C75B.6060308@mvista.com> References: <20080427231001.427983C8A9@busybox.net> <48215F0F.2090209@st.com> <200805071136.01702.vda.linux@googlemail.com> <4821C75B.6060308@mvista.com> Message-ID: <4821CB01.20504@st.com> Khem Raj wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Denys Vlasenko wrote: > >> On Wednesday 07 May 2008 09:49, Carmelo AMOROSO wrote: >> >>> Hello, just some comments... >>> >>>> It also installs asm[-generic] and linux subdirs from kernel headers >>>> (previously it had to be done separately). >>>> >>> why ? I'd disagree with this choice.... it brakes some more complex >>> build system >>> where kernel-headers are installed in other way (i.e. rpm based build >>> system). >>> >> I found it usefult. Before this, I had to copy kernel headers >> to installed uclibc' include dir by hand. Every time. Not funny. >> > > btw. what we need are sanitized kernel headers ( which we get by > doing make headers_install from linux kernel srcs).Copying might > work but not the right way I guess with newer kernels. > > Yes, exactly.... we (@ST) use sanitized kernel headers to build the uclibc-nptl for sh4 without any problems (kernel is 2.6.23.xx) since a long time. >> If one builds his libc against a set of kernel headers X he's better >> not use built libc and its headers with different set of kernel headers Y! >> Sure, kernel is supposed to provide stable API, but this inevitably >> breaks in some more obscure corners. >> >> Having said that, I understand that this constitutes a change >> from previous behavior. >> >> I propose introducing "make install_kernel_headers" >> for those who needs it. >> >> Is this acceptable for you? >> > > This sounds ok. > > > - -- > Khem Raj > MontaVista Software Inc. > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.7 (MingW32) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIIcdbUjbQJxVzeZQRAlDiAKCEl/XRl5JOv5SL4E+a2D1zeuGm0gCfR/Hu > irI+Rniz0U/hKiesPgj8Nf0= > =qdN1 > -----END PGP SIGNATURE----- > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > From vda.linux at googlemail.com Wed May 7 08:29:28 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 May 2008 17:29:28 +0200 Subject: [RFC] build system replacement Message-ID: <200805071729.28418.vda.linux@googlemail.com> Hi. I noticed that uclibc build system is broken. After I touch a file, running make won't rebuild it. I love hacking on makefiles as much as anyone else, but this was simply way below acceptable. So I decided to replace build system, using my experience in replacing build system for busybox. For busybox, I simply adapted Linux kernel build system. It is much bigger than needed for busybox and I ended up having unused features, but in the end of a day, it worked wonderfully ever since. This time, I decided "to make it right" and not carry kernel's build system idiosyncrasies. It took me nearly a week but now the first cut is ready. It does not modify any existing files, and adds these new ones: .: -rw-r--r-- 1 root root 1574 May 7 17:15 Kbuild -rw-r--r-- 1 root root 4618 May 7 17:18 Makefile.new ./libc: -rw-r--r-- 1 root root 503 May 6 12:56 Kbuild ./libc/inet: -rw-r--r-- 1 root root 1262 May 6 12:56 Kbuild ./libc/inet/rpc: -rw-r--r-- 1 root root 1065 May 6 12:56 Kbuild ./libc/misc: -rw-r--r-- 1 root root 529 May 6 12:58 Kbuild ./libc/misc/assert: -rw-r--r-- 1 root root 208 May 6 12:59 Kbuild ./libc/misc/ctype: -rw-r--r-- 1 root root 631 May 6 12:58 Kbuild ./libc/misc/dirent: -rw-r--r-- 1 root root 368 May 6 12:59 Kbuild ./libc/misc/error: -rw-r--r-- 1 root root 208 May 6 12:59 Kbuild ./libc/misc/file: -rw-r--r-- 1 root root 237 May 6 12:56 Kbuild ./libc/misc/fnmatch: -rw-r--r-- 1 root root 266 May 6 12:59 Kbuild ./libc/misc/ftw: -rw-r--r-- 1 root root 233 May 6 12:56 Kbuild ./libc/misc/glob: -rw-r--r-- 1 root root 335 May 6 12:57 Kbuild ./libc/misc/gnu: -rw-r--r-- 1 root root 208 May 6 12:56 Kbuild ./libc/misc/internals: -rw-r--r-- 1 root root 894 May 5 04:13 Kbuild ./libc/misc/locale: -rw-r--r-- 1 root root 424 May 6 12:59 Kbuild ./libc/misc/mntent: -rw-r--r-- 1 root root 208 May 6 12:58 Kbuild ./libc/misc/pthread: -rw-r--r-- 1 root root 228 May 6 12:56 Kbuild ./libc/misc/regex: -rw-r--r-- 1 root root 260 May 6 12:59 Kbuild ./libc/misc/search: -rw-r--r-- 1 root root 467 May 6 12:58 Kbuild ./libc/misc/statfs: -rw-r--r-- 1 root root 270 May 6 12:58 Kbuild ./libc/misc/syslog: -rw-r--r-- 1 root root 208 May 6 12:58 Kbuild ./libc/misc/sysvipc: -rw-r--r-- 1 root root 415 May 2 12:55 Kbuild ./libc/misc/time: -rw-r--r-- 1 root root 696 May 6 12:57 Kbuild ./libc/misc/ttyent: -rw-r--r-- 1 root root 208 May 6 12:58 Kbuild ./libc/misc/utmp: -rw-r--r-- 1 root root 208 May 6 12:57 Kbuild ./libc/misc/wchar: -rw-r--r-- 1 root root 767 May 6 12:59 Kbuild ./libc/misc/wctype: -rw-r--r-- 1 root root 554 May 2 12:55 Kbuild ./libc/misc/wordexp: -rw-r--r-- 1 root root 228 May 6 12:58 Kbuild ./libc/pwd_grp: -rw-r--r-- 1 root root 271 May 6 12:58 Kbuild ./libc/signal: -rw-r--r-- 1 root root 841 May 6 12:57 Kbuild ./libc/stdio: -rw-r--r-- 1 root root 2917 May 6 12:58 Kbuild ./libc/stdlib: -rw-r--r-- 1 root root 2623 May 5 04:13 Kbuild ./libc/stdlib/malloc: -rw-r--r-- 1 root root 656 May 3 10:57 Kbuild ./libc/stdlib/malloc-simple: -rw-r--r-- 1 root root 306 May 3 10:57 Kbuild ./libc/stdlib/malloc-standard: -rw-r--r-- 1 root root 380 May 3 10:57 Kbuild ./libc/string: -rw-r--r-- 1 root root 1681 May 6 12:57 Kbuild ./libc/string/generic: ./libc/string/i386: ./libc/string/x86_64: ./libc/sysdeps: -rw-r--r-- 1 root root 182 May 3 10:57 Kbuild ./libc/sysdeps/linux: -rw-r--r-- 1 root root 287 May 3 15:37 Kbuild ./libc/sysdeps/linux/common: -rw-r--r-- 1 root root 1333 May 3 11:09 Kbuild ./libc/sysdeps/linux/i386: -rw-r--r-- 1 root root 366 May 3 15:37 Kbuild ./libc/termios: -rw-r--r-- 1 root root 208 May 6 12:57 Kbuild ./libc/unistd: -rw-r--r-- 1 root root 883 May 6 12:57 Kbuild ./libcrypt: -rw-r--r-- 1 root root 335 May 6 01:52 Kbuild ./libintl: -rw-r--r-- 1 root root 563 May 6 13:52 Kbuild ./libm: -rw-r--r-- 1 root root 3961 May 6 01:52 Kbuild ./libm/i386: -rw-r--r-- 1 root root 371 May 6 01:52 Kbuild ./libm/powerpc: ./libm/powerpc/classic: -rw-r--r-- 1 root root 291 May 6 01:52 Kbuild ./libm/powerpc/e500: -rw-r--r-- 1 root root 263 May 6 01:52 Kbuild ./libm/powerpc/e500/fpu: -rw-r--r-- 1 root root 291 May 6 01:52 Kbuild ./libnsl: -rw-r--r-- 1 root root 333 May 6 01:52 Kbuild ./libresolv: -rw-r--r-- 1 root root 338 May 6 01:52 Kbuild ./librt: -rw-r--r-- 1 root root 334 May 6 01:52 Kbuild ./libutil: -rw-r--r-- 1 root root 334 May 6 01:52 Kbuild ./scripts: -rw-r--r-- 1 root root 4516 May 6 01:52 Kbuild.include -rw-r--r-- 1 root root 3971 May 3 16:49 Kbuild.install -rw-r--r-- 1 root root 15843 May 6 13:52 Kbuild.klibc -rw-r--r-- 1 root root 3043 May 3 16:51 Makefile.clean -rw-r--r-- 1 root root 14108 May 6 01:52 Makefile.flags -rw-r--r-- 1 root root 6179 May 3 17:33 Makefile.host -rwxr-xr-x 1 root root 425 May 6 13:56 debug_compare_libs -rwxr-xr-x 1 root root 1613 May 4 08:57 generate_h.sh ./scripts/basic: -rw-r--r-- 1 root root 102 May 2 12:55 Kbuild -rw-r--r-- 1 root root 9482 May 2 12:55 fixdep.c -rwxr-xr-x 1 root root 500 May 6 12:27 strip.sh Makefile.new carries the following explanation: # This file is a part of an experimental new build system. # # New build system is ortogonal to existing one. # They will co-exist for some time. # New system consists of Makefile.new (this file), # scripts/* directory, and Kbuild files scattrered in source directories. # It does not use Makefile[.in] files, those are from pre-existing system. # # "Old" build system is still fully functional and is recommended # for general use. No usage changes for it. # # In order to build uclibc with new system, use # make [ARCH=xxx V=1 etc] -f Makefile.new ... # # Currently, it was tested to produce byte-identical object files # in i386 static build. More testing is underway (2008-05). # # See scripts/Kbuild.klibc for the information how to write Kbuild files. I would like to commit it to svn, allowing any volunteers to try it. I will continue working on it with the goal of making it generally usable over few next weeks. Any objections for this commit? -- vda From vda.linux at googlemail.com Wed May 7 08:59:27 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 May 2008 17:59:27 +0200 Subject: svn commit: trunk/uClibc: extra/scripts In-Reply-To: <4821C75B.6060308@mvista.com> References: <20080427231001.427983C8A9@busybox.net> <200805071136.01702.vda.linux@googlemail.com> <4821C75B.6060308@mvista.com> Message-ID: <200805071759.27734.vda.linux@googlemail.com> On Wednesday 07 May 2008 17:14, Khem Raj wrote: > >>> It also installs asm[-generic] and linux subdirs from kernel headers > >>> (previously it had to be done separately). > >> why ? I'd disagree with this choice.... it brakes some more complex > >> build system > >> where kernel-headers are installed in other way (i.e. rpm based build > >> system). > > > > I found it usefult. Before this, I had to copy kernel headers > > to installed uclibc' include dir by hand. Every time. Not funny. > > btw. what we need are sanitized kernel headers ( which we get by > doing make headers_install from linux kernel srcs).Copying might > work but not the right way I guess with newer kernels. My understanding is that you should use _already_ sanitized_ kernel headers to build uclibc. Thus sanitizing already sanitized headers makes little sense. -- vda From carmelo.amoroso at st.com Wed May 7 10:11:48 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Wed, 07 May 2008 19:11:48 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <200712021348.23252.vda.linux@googlemail.com> References: <200712020244.43454.vda.linux@googlemail.com> <200712021348.23252.vda.linux@googlemail.com> Message-ID: <4821E2D4.2040308@st.com> Denys Vlasenko wrote: > On Sunday 02 December 2007 02:44, Denys Vlasenko wrote: > >> Proposed patch uses user-supplied buffer directly, >> without intermediate on-stack copy. >> This can only make a difference if user supplied >> a buffer which is too small - thus user breaks API. >> >> Failure scenario: >> >> realpath("/link_name", user_buffer) >> >> /link_name -> /very_long_name_which_fits_into_PATH_MAX_and_is_also_a_link >> -> -> /shorter_name >> >> If user will give e.g. 40-char user_buffer, current implementation >> will work, patched one will overflow user_buffer by intermediate name. >> >> This should not be a problem - user must supply PATH_MAX sized buffer, >> and in this case patched version also works correctly. >> > > And the following patch on top of previous one reuses copy_buf[] > for readlink, eliminating link_buf[]. In order to make it work, > "source" pathname is kept at the end of copy_buf, not at the > beginning (so that last NUL byte is the last byte of the copy_buf[]). > > The situation when readlink returns link name which is too long > (so that it overwrites pathname), was resulting in ENAMETOOLONG > error return. This patch does the same - the fact the we now trash > pathname does not matter, as we are not returning it to the user. > > Run tested. > > Can somebody review these patches please? > -- > vda > Hi Denys, I'm just now playing with uclibc-trunk (linuxthreads.old implementation) and discovered that your latest change on realpath implementation brakes test-canon test from uclibc test-suite. Indeed, I've run exactly the same on nptl branch (that contains the previous implementation of the realpath function) and it works fine. Have you run these tests before committing the patch... yes, likely nodoby reviewed your patch, but for sure something now doesn't work longer. Thanks, Carmelo > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc From vda.linux at googlemail.com Wed May 7 11:56:37 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 May 2008 20:56:37 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <4821E2D4.2040308@st.com> References: <200712020244.43454.vda.linux@googlemail.com> <200712021348.23252.vda.linux@googlemail.com> <4821E2D4.2040308@st.com> Message-ID: <200805072056.37076.vda.linux@googlemail.com> On Wednesday 07 May 2008 19:11, Carmelo AMOROSO wrote: > Hi Denys, > I'm just now playing with uclibc-trunk (linuxthreads.old implementation) > and discovered > that your latest change on realpath implementation brakes test-canon > test from uclibc test-suite. > Indeed, I've run exactly the same on nptl branch (that contains the > previous implementation of > the realpath function) and it works fine. Looking into it. Learning about uclibc testsuite in the process... So far I stumbled upon another failure, in gethost_r-align: # ./gethost_r-align Testing misalignment of 0 bytes: !!!gethostent_r() gethostbyname_r() gethostbyname2_r() gethostbyaddr_r() OK! Testing misalignment of 1 bytes: # strace ./gethost_r-align execve("./gethost_r-align", ["./gethost_r-align"], [/* 32 vars */]) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 write(1, "Testing misalignment of 0 bytes"..., 34Testing misalignment of 0 bytes: ) = 34 brk(0) = 0x8050000 brk(0x8051000) = 0x8051000 open("/etc/hosts", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xffcad248) = -1 ENOTTY (Inappropriate ioctl for device) read(3, "# This file is automagically reg"..., 1024) = 291 close(3) = 0 open("/etc/resolv.conf", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xffcad168) = -1 ENOTTY (Inappropriate ioctl for device) read(3, "# This file is automagically reg"..., 1024) = 259 read(3, "", 1024) = 0 close(3) = 0 open("/etc/hosts", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xffcad194) = -1 ENOTTY (Inappropriate ioctl for device) read(3, "# This file is automagically reg"..., 1024) = 291 close(3) = 0 open("/etc/hosts", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xffcad130) = -1 ENOTTY (Inappropriate ioctl for device) read(3, "# This file is automagically reg"..., 1024) = 291 close(3) = 0 open("/etc/hosts", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xffcad138) = -1 ENOTTY (Inappropriate ioctl for device) read(3, "# This file is automagically reg"..., 1024) = 291 close(3) = 0 write(1, "!!!gethostent_r() gethostbyname_"..., 77!!!gethostent_r() gethostbyname_r() gethostbyname2_r() gethostbyaddr_r() OK! ) = 77 write(1, "Testing misalignment of 1 bytes"..., 34Testing misalignment of 1 bytes: ) = 34 close(-1) = -1 EBADF (Bad file descriptor) open("/etc/hosts", O_RDONLY) = 3 ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, 0xffcad194) = -1 ENOTTY (Inappropriate ioctl for device) --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Will look into relapath() problem in a second. Stay tuned. -- vda From vda.linux at googlemail.com Wed May 7 12:06:54 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 May 2008 21:06:54 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <4821E2D4.2040308@st.com> References: <200712020244.43454.vda.linux@googlemail.com> <200712021348.23252.vda.linux@googlemail.com> <4821E2D4.2040308@st.com> Message-ID: <200805072106.54404.vda.linux@googlemail.com> On Wednesday 07 May 2008 19:11, Carmelo AMOROSO wrote: > >> Proposed patch uses user-supplied buffer directly, > >> without intermediate on-stack copy. > >> This can only make a difference if user supplied > >> a buffer which is too small - thus user breaks API. > >> > >> Failure scenario: > >> > >> realpath("/link_name", user_buffer) > >> > >> /link_name -> /very_long_name_which_fits_into_PATH_MAX_and_is_also_a_link > >> -> -> /shorter_name > >> > >> If user will give e.g. 40-char user_buffer, current implementation > >> will work, patched one will overflow user_buffer by intermediate name. > >> > >> This should not be a problem - user must supply PATH_MAX sized buffer, > >> and in this case patched version also works correctly. > >> > > > > And the following patch on top of previous one reuses copy_buf[] > > for readlink, eliminating link_buf[]. In order to make it work, > > "source" pathname is kept at the end of copy_buf, not at the > > beginning (so that last NUL byte is the last byte of the copy_buf[]). > > > > The situation when readlink returns link name which is too long > > (so that it overwrites pathname), was resulting in ENAMETOOLONG > > error return. This patch does the same - the fact the we now trash > > pathname does not matter, as we are not returning it to the user. > > > > Run tested. > > > > Can somebody review these patches please? > > -- > > vda > > > > Hi Denys, > I'm just now playing with uclibc-trunk (linuxthreads.old implementation) > and discovered > that your latest change on realpath implementation brakes test-canon > test from uclibc test-suite. > Indeed, I've run exactly the same on nptl branch (that contains the > previous implementation of > the realpath function) and it works fine. Just built and run test here. Result: # ./test-canon ./test-canon: flunked test 3 (expected `/etc', got `/.local/etc') ./test-canon: flunked test 4 (expected `/etc', got `/.local/etc') ./test-canon: flunked test 7 (expected resolved `/etc/doesNotExist', got `/.local/etc/doesNotExist') ./test-canon: flunked test 14 (expected resolved `', got `/.1/usr/srcdevel/uclibc/fix/uClibc.t7/test/stdlib/SYMLINK_LOOP') ./test-canon: flunked test 15 (expected resolved `', got `/.1/usr/srcdevel/uclibc/fix/uClibc.t7/test/stdlib/SYMLINK_LOOP') ./test-canon: flunked test 18 (expected `/etc', got `/.local/etc') ./test-canon: flunked test 20 (expected `/etc', got `/.local/etc') ./test-canon: flunked test 22 (expected `/etc', got `/.local/etc') ./test-canon: flunked test 24 (expected `/etc', got `/.local/etc') Except 14 and 15, test makes an assumption that /etc is not a symlink. On my machine it is not true, so it fails. Tests 14 and 15 say in source: /* 10 */ {"./doesExist/../doesExist", "./doesExist"}, {"foobar", 0, "./foobar", ENOENT}, {".", "."}, {"./foobar", 0, "./foobar", ENOENT}, #ifdef __UCLIBC__ /* we differ from glibc here, but POSIX allows it as it says that if we did * not successfuly complete, the value of resolved_path is undefined */ {"SYMLINK_LOOP", 0, "", ELOOP}, /* 15 */ {"./SYMLINK_LOOP", 0, "", ELOOP}, #else I can make it work so that test passes. However, as this comment says, POSIX says nothing about return buffer's contents, so alternative fix would be to not check its contents, only return value and errno. Do you want me to make readlink return "" or to stop testing buffer's contents? Your pick. -- vda From vda.linux at googlemail.com Wed May 7 12:27:17 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Wed, 7 May 2008 21:27:17 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <200805072106.54404.vda.linux@googlemail.com> References: <200712020244.43454.vda.linux@googlemail.com> <4821E2D4.2040308@st.com> <200805072106.54404.vda.linux@googlemail.com> Message-ID: <200805072127.17464.vda.linux@googlemail.com> On Wednesday 07 May 2008 21:06, Denys Vlasenko wrote: > Tests 14 and 15 say in source: > > /* 10 */ > {"./doesExist/../doesExist", "./doesExist"}, > {"foobar", 0, "./foobar", ENOENT}, > {".", "."}, > {"./foobar", 0, "./foobar", ENOENT}, > #ifdef __UCLIBC__ > /* we differ from glibc here, but POSIX allows it as it says that if we did > * not successfuly complete, the value of resolved_path is undefined */ > {"SYMLINK_LOOP", 0, "", ELOOP}, > /* 15 */ > {"./SYMLINK_LOOP", 0, "", ELOOP}, > #else > > I can make it work so that test passes. However, as this comment says, > POSIX says nothing about return buffer's contents, so alternative > fix would be to not check its contents, only return value and errno. > > Do you want me to make readlink return "" which can be done this way: /* Protect against infinite loops. */ if (readlinks++ > MAX_READLINKS) { __set_errno(ELOOP); + got_path[0] = '\0'; return NULL; } > or to stop testing buffer's contents? this way: --- test-canon-old.c Wed May 7 21:22:49 2008 +++ test-canon.c Wed May 7 21:25:14 2008 @@ -72,17 +72,9 @@ {"foobar", 0, "./foobar", ENOENT}, {".", "."}, {"./foobar", 0, "./foobar", ENOENT}, -#ifdef __UCLIBC__ - /* we differ from glibc here, but POSIX allows it as it says that if we did - * not successfuly complete, the value of resolved_path is undefined */ - {"SYMLINK_LOOP", 0, "", ELOOP}, + {"SYMLINK_LOOP", 0, 0, ELOOP}, /* 15 */ - {"./SYMLINK_LOOP", 0, "", ELOOP}, -#else - {"SYMLINK_LOOP", 0, "./SYMLINK_LOOP", ELOOP}, - /* 15 */ - {"./SYMLINK_LOOP", 0, "./SYMLINK_LOOP", ELOOP}, -#endif + {"./SYMLINK_LOOP", 0, 0, ELOOP}, {"SYMLINK_1", "."}, {"SYMLINK_1/foobar", 0, "./foobar", ENOENT}, {"SYMLINK_2", "/etc"}, @@ -191,7 +183,8 @@ continue; } - if (!check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) + if ((tests[i].out || tests[i].resolved) + && !check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) { printf ("%s: flunked test %d (expected resolved `%s', got `%s')\n", argv[0], i, tests[i].out ? tests[i].out : tests[i].resolved, > Your pick. -- vda From rep.dot.nop at gmail.com Wed May 7 12:41:50 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 7 May 2008 21:41:50 +0200 Subject: [RFC] build system replacement In-Reply-To: <200805071729.28418.vda.linux@googlemail.com> References: <200805071729.28418.vda.linux@googlemail.com> Message-ID: <20080507194150.GF9589@mx.loc> On Wed, May 07, 2008 at 05:29:28PM +0200, Denys Vlasenko wrote: >Hi. > >I noticed that uclibc build system is broken. [big snip non-patch babble] >I would like to commit it to svn, allowing any volunteers to >try it. Please put a patch somewhere for double-checking. >I will continue working on it with the goal of making it generally >usable over few next weeks. got distracted by looking into the [pre-]alpha state of alpha -- but there seem to be literally no users as this would have been noted before by now, i fear. >Any objections for this commit? yes ;) Patch, please and give us 2 weeks or three to comment and double-check, even if it is not active per default. We'll certainly have to adjust our callers, external anyways. cheers && TIA for said patch (or tarball, as you see fit), From rep.dot.nop at gmail.com Wed May 7 13:07:24 2008 From: rep.dot.nop at gmail.com (Bernhard Fischer) Date: Wed, 7 May 2008 22:07:24 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <200805072106.54404.vda.linux@googlemail.com> References: <200712020244.43454.vda.linux@googlemail.com> <200712021348.23252.vda.linux@googlemail.com> <4821E2D4.2040308@st.com> <200805072106.54404.vda.linux@googlemail.com> Message-ID: <20080507200724.GG9589@mx.loc> On Wed, May 07, 2008 at 09:06:54PM +0200, Denys Vlasenko wrote: >On Wednesday 07 May 2008 19:11, Carmelo AMOROSO wrote: >> >> Proposed patch uses user-supplied buffer directly, >> >> without intermediate on-stack copy. >> >> This can only make a difference if user supplied >> >> a buffer which is too small - thus user breaks API. >> >> >> >> Failure scenario: >> >> >> >> realpath("/link_name", user_buffer) >> >> >> >> /link_name -> /very_long_name_which_fits_into_PATH_MAX_and_is_also_a_link >> >> -> -> /shorter_name >> >> >> >> If user will give e.g. 40-char user_buffer, current implementation >> >> will work, patched one will overflow user_buffer by intermediate name. >> >> >> >> This should not be a problem - user must supply PATH_MAX sized buffer, >> >> and in this case patched version also works correctly. >> >> >> > >> > And the following patch on top of previous one reuses copy_buf[] >> > for readlink, eliminating link_buf[]. In order to make it work, >> > "source" pathname is kept at the end of copy_buf, not at the >> > beginning (so that last NUL byte is the last byte of the copy_buf[]). >> > >> > The situation when readlink returns link name which is too long >> > (so that it overwrites pathname), was resulting in ENAMETOOLONG >> > error return. This patch does the same - the fact the we now trash >> > pathname does not matter, as we are not returning it to the user. >> > >> > Run tested. >> > >> > Can somebody review these patches please? >> > -- >> > vda >> > >> >> Hi Denys, >> I'm just now playing with uclibc-trunk (linuxthreads.old implementation) >> and discovered >> that your latest change on realpath implementation brakes test-canon >> test from uclibc test-suite. >> Indeed, I've run exactly the same on nptl branch (that contains the >> previous implementation of >> the realpath function) and it works fine. > >Just built and run test here. Result: > ># ./test-canon >./test-canon: flunked test 3 (expected `/etc', got `/.local/etc') >./test-canon: flunked test 4 (expected `/etc', got `/.local/etc') >./test-canon: flunked test 7 (expected resolved `/etc/doesNotExist', got `/.local/etc/doesNotExist') >./test-canon: flunked test 14 (expected resolved `', got `/.1/usr/srcdevel/uclibc/fix/uClibc.t7/test/stdlib/SYMLINK_LOOP') >./test-canon: flunked test 15 (expected resolved `', got `/.1/usr/srcdevel/uclibc/fix/uClibc.t7/test/stdlib/SYMLINK_LOOP') >./test-canon: flunked test 18 (expected `/etc', got `/.local/etc') >./test-canon: flunked test 20 (expected `/etc', got `/.local/etc') >./test-canon: flunked test 22 (expected `/etc', got `/.local/etc') >./test-canon: flunked test 24 (expected `/etc', got `/.local/etc') > >Except 14 and 15, test makes an assumption that /etc is not a symlink. >On my machine it is not true, so it fails. > >Tests 14 and 15 say in source: > > /* 10 */ > {"./doesExist/../doesExist", "./doesExist"}, > {"foobar", 0, "./foobar", ENOENT}, > {".", "."}, > {"./foobar", 0, "./foobar", ENOENT}, >#ifdef __UCLIBC__ > /* we differ from glibc here, but POSIX allows it as it says that if we did > * not successfuly complete, the value of resolved_path is undefined */ > {"SYMLINK_LOOP", 0, "", ELOOP}, > /* 15 */ > {"./SYMLINK_LOOP", 0, "", ELOOP}, >#else > >I can make it work so that test passes. However, as this comment says, >POSIX says nothing about return buffer's contents, so alternative I didn't (and will not) look what posix mandates in this regard, but if posix sais that it's undefined then it's just that, undefined. Obviously, if we can follow bloat-libc in this respect for compatibility with minor trade-off, then please follow suite (as always) but if we cannot, then please introduce a(nother) config-knob to follow bloat-libc in this respect (ISTR that we flags this as glibc-compat in the comment, fwiw). >fix would be to not check its contents, only return value and errno. > >Do you want me to make readlink return "" or to stop testing >buffer's contents? Your pick. cought: no-bloat-libc-code-here; From lsjunk1 at cableone.net Wed May 7 13:03:50 2008 From: lsjunk1 at cableone.net (Lance Spaulding) Date: Wed, 07 May 2008 14:03:50 -0600 Subject: NPTL? Message-ID: <48220B26.2060004@cableone.net> Hi all, Is there an NPTL version of uClibc for x86 available anywhere? I have an application that needs features such as named sems & process-shared sems that aren't currently supported in uClibc. Thanks in advance, Lance From vda.linux at googlemail.com Wed May 7 15:24:46 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 May 2008 00:24:46 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <20080507200724.GG9589@mx.loc> References: <200712020244.43454.vda.linux@googlemail.com> <200805072106.54404.vda.linux@googlemail.com> <20080507200724.GG9589@mx.loc> Message-ID: <200805080024.46183.vda.linux@googlemail.com> On Wednesday 07 May 2008 22:07, Bernhard Fischer wrote: > >Tests 14 and 15 say in source: > > > > /* 10 */ > > {"./doesExist/../doesExist", "./doesExist"}, > > {"foobar", 0, "./foobar", ENOENT}, > > {".", "."}, > > {"./foobar", 0, "./foobar", ENOENT}, > >#ifdef __UCLIBC__ > > /* we differ from glibc here, but POSIX allows it as it says that if we did > > * not successfuly complete, the value of resolved_path is undefined */ > > {"SYMLINK_LOOP", 0, "", ELOOP}, > > /* 15 */ > > {"./SYMLINK_LOOP", 0, "", ELOOP}, > >#else > > > >I can make it work so that test passes. However, as this comment says, > >POSIX says nothing about return buffer's contents, so alternative > > I didn't (and will not) look what posix mandates in this regard, but if > posix sais that it's undefined then it's just that, undefined. > Obviously, if we can follow bloat-libc in this respect for compatibility > with minor trade-off, then please follow suite (as always) but if we > cannot, then please introduce a(nother) config-knob to follow bloat-libc > in this respect (ISTR that we flags this as glibc-compat in the comment, > fwiw). uclibc already did NOT mimic glibc in this regard. After my patch, it still does not mimic glibc, but differently - the "undefined" contents of the buffer is different. > >fix would be to not check its contents, only return value and errno. > > > >Do you want me to make readlink return "" or to stop testing > >buffer's contents? Your pick. > > cought: > no-bloat-libc-code-here; I dont understand. -- vda From vda.linux at googlemail.com Wed May 7 16:03:16 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 May 2008 01:03:16 +0200 Subject: [RFC] build system replacement In-Reply-To: <20080507194150.GF9589@mx.loc> References: <200805071729.28418.vda.linux@googlemail.com> <20080507194150.GF9589@mx.loc> Message-ID: <200805080103.16400.vda.linux@googlemail.com> On Wednesday 07 May 2008 21:41, Bernhard Fischer wrote: > On Wed, May 07, 2008 at 05:29:28PM +0200, Denys Vlasenko wrote: > >I noticed that uclibc build system is broken. > [big snip non-patch babble] > >I would like to commit it to svn, allowing any volunteers to > >try it. > > Please put a patch somewhere for double-checking. > >I will continue working on it with the goal of making it generally > >usable over few next weeks. > > got distracted by looking into the [pre-]alpha state of alpha -- but > there seem to be literally no users as this would have been noted before > by now, i fear. > > >Any objections for this commit? > > yes ;) Patch, please and give us 2 weeks or three to comment and > double-check, even if it is not active per default. We'll certainly have > to adjust our callers, external anyways. "External callers"? > cheers && TIA for said patch (or tarball, as you see fit), Tarball is easier to review. http://uclibc.org/~vda/build_system.tar.bz2 Just untar and copy it into uclibc tree. Read Makefile.new. Included .config is the one which is verified to be compiled correctly (byte-identically). -- vda From christian.michon at gmail.com Thu May 8 00:15:54 2008 From: christian.michon at gmail.com (Christian MICHON) Date: Thu, 8 May 2008 09:15:54 +0200 Subject: [RFC] build system replacement In-Reply-To: <200805071729.28418.vda.linux@googlemail.com> References: <200805071729.28418.vda.linux@googlemail.com> Message-ID: <46d6db660805080015o3f992e08q87b5a527404f97ef@mail.gmail.com> On Wed, May 7, 2008 at 5:29 PM, Denys Vlasenko wrote: > Hi. > > I noticed that uclibc build system is broken. > After I touch a file, running make won't rebuild it. > > I love hacking on makefiles as much as anyone else, > but this was simply way below acceptable. > > So I decided to replace build system, using my > experience in replacing build system for busybox. > > For busybox, I simply adapted Linux kernel build system. > It is much bigger than needed for busybox and I ended up > having unused features, but in the end of a day, it worked > wonderfully ever since. > > This time, I decided "to make it right" and not carry > kernel's build system idiosyncrasies. > I have not tested it yet, but could you tell if this time, ncurses is still needed when doing "make oldconfig" ? -- Christian -- http://detaolb.sourceforge.net/, a linux distribution for Qemu with Git inside ! From carmelo.amoroso at st.com Thu May 8 02:12:05 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 08 May 2008 11:12:05 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <200805072127.17464.vda.linux@googlemail.com> References: <200712020244.43454.vda.linux@googlemail.com> <4821E2D4.2040308@st.com> <200805072106.54404.vda.linux@googlemail.com> <200805072127.17464.vda.linux@googlemail.com> Message-ID: <4822C3E5.4030006@st.com> Denys Vlasenko wrote: > On Wednesday 07 May 2008 21:06, Denys Vlasenko wrote: > > [SNIP] > > >> or to stop testing buffer's contents? >> > > this way: > > --- test-canon-old.c Wed May 7 21:22:49 2008 > +++ test-canon.c Wed May 7 21:25:14 2008 > @@ -72,17 +72,9 @@ > {"foobar", 0, "./foobar", ENOENT}, > {".", "."}, > {"./foobar", 0, "./foobar", ENOENT}, > -#ifdef __UCLIBC__ > - /* we differ from glibc here, but POSIX allows it as it says that if we did > - * not successfuly complete, the value of resolved_path is undefined */ > - {"SYMLINK_LOOP", 0, "", ELOOP}, > + {"SYMLINK_LOOP", 0, 0, ELOOP}, > /* 15 */ > - {"./SYMLINK_LOOP", 0, "", ELOOP}, > -#else > - {"SYMLINK_LOOP", 0, "./SYMLINK_LOOP", ELOOP}, > - /* 15 */ > - {"./SYMLINK_LOOP", 0, "./SYMLINK_LOOP", ELOOP}, > -#endif > + {"./SYMLINK_LOOP", 0, 0, ELOOP}, > {"SYMLINK_1", "."}, > {"SYMLINK_1/foobar", 0, "./foobar", ENOENT}, > {"SYMLINK_2", "/etc"}, > @@ -191,7 +183,8 @@ > continue; > } > > - if (!check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) > + if ((tests[i].out || tests[i].resolved) > + && !check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) > { > printf ("%s: flunked test %d (expected resolved `%s', got `%s')\n", > argv[0], i, tests[i].out ? tests[i].out : tests[i].resolved, > > > >> Your pick. >> > > -- > vda > Hi Denys, I looked better at realpath man page and your implementation... well I think that we should only fix the test not testing for buffer contents (that in undefined) when the realpath fails... so i'd use 'result' instead of test[i].out or test[i].resolved... something like that - if (!check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) + if (result && !check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) { printf ("%s: flunked test %d (expected resolved `%s', got `%s')\n", argv[0], i, tests[i].out ? tests[i].out : tests[i].resolved, So, if realpath return result==NULL (it means it is failing), then do not check buffern content and go on to check the errno for ELOOP Do you agree ? Let's keep your implementation for realpath ;-) Thanks, Carmelo From carmelo.amoroso at st.com Thu May 8 02:17:32 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 08 May 2008 11:17:32 +0200 Subject: NPTL? In-Reply-To: <48220B26.2060004@cableone.net> References: <48220B26.2060004@cableone.net> Message-ID: <4822C52C.5080004@st.com> Lance Spaulding wrote: > Hi all, > > Is there an NPTL version of uClibc for x86 available anywhere? I have > an application that needs features such as named sems & process-shared > sems that aren't currently supported in uClibc. > > Thanks in advance, > Lance > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > > I'm sorry not... only mips/sh4 on svn branch and arm from a different web site (hopefully all merged soon ) From vda.linux at googlemail.com Thu May 8 06:55:06 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 May 2008 15:55:06 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <4822C3E5.4030006@st.com> References: <200712020244.43454.vda.linux@googlemail.com> <200805072127.17464.vda.linux@googlemail.com> <4822C3E5.4030006@st.com> Message-ID: <200805081555.06176.vda.linux@googlemail.com> On Thursday 08 May 2008 11:12, Carmelo AMOROSO wrote: > Hi Denys, > I looked better at realpath man page and your implementation... > well I think that we should only fix the test not testing for buffer > contents (that in undefined) > when the realpath fails... so i'd use 'result' instead of test[i].out or > test[i].resolved... > something like that > > - if (!check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) > + if (result && !check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) > { > printf ("%s: flunked test %d (expected resolved `%s', got `%s')\n", > argv[0], i, tests[i].out ? tests[i].out : tests[i].resolved, > > So, if realpath return result==NULL (it means it is failing), then > do not check buffern content and go on to check the errno for ELOOP > > Do you agree ? Yes. I committed the fix to svn. I also renamed struct fields to more closely explain what they mean. Another change is to check errno always, regardless of NULL return. This last change found a bug in realpath - also fixed now. -- vda From carmelo.amoroso at st.com Thu May 8 07:01:53 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 08 May 2008 16:01:53 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <200805081555.06176.vda.linux@googlemail.com> References: <200712020244.43454.vda.linux@googlemail.com> <200805072127.17464.vda.linux@googlemail.com> <4822C3E5.4030006@st.com> <200805081555.06176.vda.linux@googlemail.com> Message-ID: <482307D1.4050203@st.com> Denys Vlasenko wrote: > On Thursday 08 May 2008 11:12, Carmelo AMOROSO wrote: > >> Hi Denys, >> I looked better at realpath man page and your implementation... >> well I think that we should only fix the test not testing for buffer >> contents (that in undefined) >> when the realpath fails... so i'd use 'result' instead of test[i].out or >> test[i].resolved... >> something like that >> >> - if (!check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) >> + if (result && !check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) >> { >> printf ("%s: flunked test %d (expected resolved `%s', got `%s')\n", >> argv[0], i, tests[i].out ? tests[i].out : tests[i].resolved, >> >> So, if realpath return result==NULL (it means it is failing), then >> do not check buffern content and go on to check the errno for ELOOP >> >> Do you agree ? >> > > Yes. > > I committed the fix to svn. > you said yes... but committed something different, you did not use my last suggestion to use result > I also renamed struct fields to more closely explain what they mean. > Another change is to check errno always, regardless of NULL return. > This last change found a bug in realpath - also fixed now. > -- > vda > > From vda.linux at googlemail.com Thu May 8 08:42:56 2008 From: vda.linux at googlemail.com (Denys Vlasenko) Date: Thu, 8 May 2008 17:42:56 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <482307D1.4050203@st.com> References: <200712020244.43454.vda.linux@googlemail.com> <200805081555.06176.vda.linux@googlemail.com> <482307D1.4050203@st.com> Message-ID: <200805081742.56285.vda.linux@googlemail.com> On Thursday 08 May 2008 16:01, Carmelo AMOROSO wrote: > >> > >> - if (!check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) > >> + if (result && !check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) > >> { > >> printf ("%s: flunked test %d (expected resolved `%s', got `%s')\n", > >> argv[0], i, tests[i].out ? tests[i].out : tests[i].resolved, > >> > >> So, if realpath return result==NULL (it means it is failing), then > >> do not check buffern content and go on to check the errno for ELOOP > >> > >> Do you agree ? > >> > > > > Yes. > > > > I committed the fix to svn. > > > you said yes... but committed something different, you did not use my > last suggestion to use result Well, there is a multitude of ways how to do it, all slightly different. I did not use "if (result && !check_path(...)) construct because it does not allow for doing check_path if result is NULL. I don't know whether anyone ever realonably _need_ such check. I just retained that. In version which I committed check_path() is done unless both expected retval and expected buffer contents is NULL. And I set them to NULL in two cases. This means that I did minimal change - I switched check off ONLY for two cases where it was giving false positives. I don't feel strongly about it. If you want to switch off buffer contents check for all cases where reval is NULL, by all means, please do it. -- vda From carmelo.amoroso at st.com Tue May 13 07:20:26 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Tue, 13 May 2008 16:20:26 +0200 Subject: [PATCH] realpath stack usage 8k -> 4k In-Reply-To: <200805081742.56285.vda.linux@googlemail.com> References: <200712020244.43454.vda.linux@googlemail.com> <200805081555.06176.vda.linux@googlemail.com> <482307D1.4050203@st.com> <200805081742.56285.vda.linux@googlemail.com> Message-ID: <4829A3AA.4050208@st.com> Denys Vlasenko wrote: > On Thursday 08 May 2008 16:01, Carmelo AMOROSO wrote: > >>>> - if (!check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) >>>> + if (result && !check_path (buf, tests[i].out ? tests[i].out : tests[i].resolved)) >>>> { >>>> printf ("%s: flunked test %d (expected resolved `%s', got `%s')\n", >>>> argv[0], i, tests[i].out ? tests[i].out : tests[i].resolved, >>>> >>>> So, if realpath return result==NULL (it means it is failing), then >>>> do not check buffern content and go on to check the errno for ELOOP >>>> >>>> Do you agree ? >>>> >>>> >>> Yes. >>> >>> I committed the fix to svn. >>> >>> >> you said yes... but committed something different, you did not use my >> last suggestion to use result >> > > Well, there is a multitude of ways how to do it, all slightly different. > > I did not use "if (result && !check_path(...)) construct because it > does not allow for doing check_path if result is NULL. > I don't know whether anyone ever realonably _need_ such check. > I just retained that. > > In version which I committed check_path() is done unless > both expected retval and expected buffer contents is NULL. > And I set them to NULL in two cases. > This means that I did minimal change - I switched check off > ONLY for two cases where it was giving false positives. > > I don't feel strongly about it. If you want to switch off > buffer contents check for all cases where reval is NULL, > by all means, please do it. > -- > vda > Hi Denis, I think that the check against the result is more correct. From the man page... ----------- If there is no error, it returns a pointer to the resolved_path. Otherwise it returns a NULL pointer, and the contents of the array resolved_path are undefined. The global variable errno is set to indicate the error. -------------- I'd prefer to rely on the return value of the function instead of the expect values provided by the testcase, I think it 's clearer from the functional point of view. If the realpath function returns a not null value while null is expected, this is already verified in the first check (test-canon.c:182 and following) 182 if (!check_path (result, tests[i].retval)) 183 { 184 printf ("%s: flunked test %d (expected `%s', got `%s')\n", 185 argv[0], i, tests[i].retval ? tests[i].retval : "NULL", 186 result ? result : "NULL"); 187 ++errors; 188 continue; 189 } So, I'm going to change it ;-) Cheers, Carmelo From vapier at gentoo.org Wed May 14 17:13:37 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Wed, 14 May 2008 20:13:37 -0400 Subject: svn commit: branches/uClibc-nptl/libc/misc/dirent In-Reply-To: <20071205172509.21874128569@busybox.net> References: <20071205172509.21874128569@busybox.net> Message-ID: <200805142013.38095.vapier@gentoo.org> On Wednesday 05 December 2007, carmelo at uclibc.org wrote: > Author: carmelo > Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007) > New Revision: 20626 > > Log: > Fix opendir problem when statically linked due to a missing > initialization of the mutex field within DIR struct. > When linked dynamically instead, __pthread_mutex_init will > initialize the mutex itself. Without this fix, any call to > readdir will stuck forever trying to acquire the mutex. sorry, but i dont follow. we call __pthread_mutex_init() on the dd_lock member of the dirent structure which should initialize the mutex just fine. you cant assume that zeroing the structure is the same as initializing the mutex. that is why we have these initializer functions in the first place. are you suggesting that the __pthread_mutex_init() function is not doing its job ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080514/badeb2fe/attachment.pgp From carmelo.amoroso at st.com Thu May 15 00:42:21 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 15 May 2008 09:42:21 +0200 Subject: svn commit: branches/uClibc-nptl/libc/misc/dirent In-Reply-To: <200805142013.38095.vapier@gentoo.org> References: <20071205172509.21874128569@busybox.net> <200805142013.38095.vapier@gentoo.org> Message-ID: <482BE95D.1060400@st.com> Mike Frysinger wrote: > On Wednesday 05 December 2007, carmelo at uclibc.org wrote: > >> Author: carmelo >> Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007) >> New Revision: 20626 >> >> Log: >> Fix opendir problem when statically linked due to a missing >> initialization of the mutex field within DIR struct. >> When linked dynamically instead, __pthread_mutex_init will >> initialize the mutex itself. Without this fix, any call to >> readdir will stuck forever trying to acquire the mutex. >> > > sorry, but i dont follow. we call __pthread_mutex_init() on the dd_lock > member of the dirent structure which should initialize the mutex just fine. > you cant assume that zeroing the structure is the same as initializing the > mutex. that is why we have these initializer functions in the first place. > are you suggesting that the __pthread_mutex_init() function is not doing its > job ? > -mike > Hi Mike, yes exactly... but only if statically linked. I suspect that in this case the __pthread_mutex_init is a nop... likely due to weak aliasing... however, glibc does exactly the same call to memset and it uses #ifndef NOT_IN_libc __libc_lock_init (dirp->lock); #endif instead of __pthread_mutex_init(&(ptr->dd_lock), NULL); > ------------------------------------------------------------------------ > > _______________________________________________ > uClibc-cvs mailing list > uClibc-cvs at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc-cvs From lundman at lundman.net Thu May 15 00:54:34 2008 From: lundman at lundman.net (Jorgen Lundman) Date: Thu, 15 May 2008 16:54:34 +0900 Subject: uClibc-0.9.27 with locale for ntfs-3g Message-ID: <482BEC3A.60908@lundman.net> Hello list, Working on an embedded MIPS32le architecture to get ntfs-3g to work (which it does) I run into the problem that it needs locale to be able to convert to utf8. I have not been able to find much information regarding this. If I compile uClibc with "nls", do I also need some binary locale files somewhere on the system? Can I download those separately, or do I need to generate them myself? Or should I be looking at compiling iconv as a separate package and re-compile ntfs-3g? There was a separate tarball from 2003 with source code, is that relevant? The rootfs provided on the download page for mips32 appear to contain no locale files. Lund -- Jorgen Lundman | Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) From natanael.copa at gmail.com Thu May 15 01:48:28 2008 From: natanael.copa at gmail.com (Natanael Copa) Date: Thu, 15 May 2008 10:48:28 +0200 Subject: uClibc-0.9.27 with locale for ntfs-3g In-Reply-To: <482BEC3A.60908@lundman.net> References: <482BEC3A.60908@lundman.net> Message-ID: <1210841308.14700.2.camel@nc.nor.wtbts.org> On Thu, 2008-05-15 at 16:54 +0900, Jorgen Lundman wrote: > Hello list, > > Working on an embedded MIPS32le architecture to get ntfs-3g to work > (which it does) I run into the problem that it needs locale to be able > to convert to utf8. I am able to compile ntfs-3g version 1.2310 without nls/iconv. > I have not been able to find much information regarding this. If I > compile uClibc with "nls", do I also need some binary locale files > somewhere on the system? Can I download those separately, or do I need > to generate them myself? Or should I be looking at compiling iconv as a > separate package and re-compile ntfs-3g? If you still need an iconv, you can use my tiny iso-8859-1/utf8/ascii iconv: ftp://distrib-coffee.ipsl.jussieu.fr/pub/linux/alpine/alpine/uiconv > > There was a separate tarball from 2003 with source code, is that > relevant? The rootfs provided on the download page for mips32 appear to > contain no locale files. > > Lund > > From filippo.arcidiacono at st.com Thu May 15 02:14:01 2008 From: filippo.arcidiacono at st.com (Filippo ARCIDIACONO) Date: Thu, 15 May 2008 11:14:01 +0200 Subject: uClibc-0.9.27 with locale for ntfs-3g In-Reply-To: <482BEC3A.60908@lundman.net> Message-ID: <000001c8b66c$103fa9b0$838182a4@st.com> I suggest you to upgrate uClibc to the last thrunk revision. > -----Original Message----- > From: uclibc-bounces at uclibc.org > [mailto:uclibc-bounces at uclibc.org] On Behalf Of Jorgen Lundman > Sent: Thursday, May 15, 2008 9:55 AM > To: uclibc at uclibc.org > Subject: uClibc-0.9.27 with locale for ntfs-3g > > > Hello list, > > Working on an embedded MIPS32le architecture to get ntfs-3g > to work (which it does) I run into the problem that it needs > locale to be able to convert to utf8. > > I have not been able to find much information regarding this. > If I compile uClibc with "nls", do I also need some binary > locale files somewhere on the system? Can I download those > separately, or do I need to generate them myself? Or should I > be looking at compiling iconv as a separate package and > re-compile ntfs-3g? There aren't any locale file that you need. You have to recompile the uClibc adding the locale support doing: - make menuconfig enable "Locale Support" into the "String and Stdio Support" menu. If you need the iconv tool you have to build also utility doing: - make utils So you can have the locale utility "iconv" and "locale", the latter Recently added to see the currently supported locale. > > There was a separate tarball from 2003 with source code, is > that relevant? The tarbal you refering are the locale pregenereted file needed if We enable "Use pre-genereted Locale Data" also. >The rootfs provided on the download page for > mips32 appear to contain no locale files. > > Lund > > > -- > Jorgen Lundman | > Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) > Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) > Japan | +81 (0)3 -3375-1767 (home) > _______________________________________________ > uClibc mailing list > uClibc at uclibc.org > http://busybox.net/cgi-bin/mailman/listinfo/uclibc > Regards, Filippo Arcidiacono From vapier at gentoo.org Thu May 15 02:32:37 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 15 May 2008 05:32:37 -0400 Subject: svn commit: branches/uClibc-nptl/libc/misc/dirent In-Reply-To: <482BE95D.1060400@st.com> References: <20071205172509.21874128569@busybox.net> <200805142013.38095.vapier@gentoo.org> <482BE95D.1060400@st.com> Message-ID: <200805150532.38099.vapier@gentoo.org> On Thursday 15 May 2008, Carmelo AMOROSO wrote: > Mike Frysinger wrote: > > On Wednesday 05 December 2007, carmelo at uclibc.org wrote: > >> Author: carmelo > >> Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007) > >> New Revision: 20626 > >> > >> Log: > >> Fix opendir problem when statically linked due to a missing > >> initialization of the mutex field within DIR struct. > >> When linked dynamically instead, __pthread_mutex_init will > >> initialize the mutex itself. Without this fix, any call to > >> readdir will stuck forever trying to acquire the mutex. > > > > sorry, but i dont follow. we call __pthread_mutex_init() on the dd_lock > > member of the dirent structure which should initialize the mutex just > > fine. you cant assume that zeroing the structure is the same as > > initializing the mutex. that is why we have these initializer functions > > in the first place. are you suggesting that the __pthread_mutex_init() > > function is not doing its job ? > > yes exactly... but only if statically linked. I suspect that in this > case the __pthread_mutex_init is a nop... > likely due to weak aliasing... however, glibc does exactly the same call > to memset > and it uses > > #ifndef NOT_IN_libc > __libc_lock_init (dirp->lock); > #endif > > instead of __pthread_mutex_init(&(ptr->dd_lock), NULL); can you provide a test case ? i'd like to fix the real problem ... adding a memset() just ignores the larger issue with every function that does something similar. -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080515/cf24713b/attachment.pgp From carmelo.amoroso at st.com Thu May 15 03:13:34 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 15 May 2008 12:13:34 +0200 Subject: svn commit: branches/uClibc-nptl/libc/misc/dirent In-Reply-To: <200805150532.38099.vapier@gentoo.org> References: <20071205172509.21874128569@busybox.net> <200805142013.38095.vapier@gentoo.org> <482BE95D.1060400@st.com> <200805150532.38099.vapier@gentoo.org> Message-ID: <482C0CCE.7090207@st.com> Mike Frysinger wrote: > On Thursday 15 May 2008, Carmelo AMOROSO wrote: > >> Mike Frysinger wrote: >> >>> On Wednesday 05 December 2007, carmelo at uclibc.org wrote: >>> >>>> Author: carmelo >>>> Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007) >>>> New Revision: 20626 >>>> >>>> Log: >>>> Fix opendir problem when statically linked due to a missing >>>> initialization of the mutex field within DIR struct. >>>> When linked dynamically instead, __pthread_mutex_init will >>>> initialize the mutex itself. Without this fix, any call to >>>> readdir will stuck forever trying to acquire the mutex. >>>> >>> sorry, but i dont follow. we call __pthread_mutex_init() on the dd_lock >>> member of the dirent structure which should initialize the mutex just >>> fine. you cant assume that zeroing the structure is the same as >>> initializing the mutex. that is why we have these initializer functions >>> in the first place. are you suggesting that the __pthread_mutex_init() >>> function is not doing its job ? >>> >> yes exactly... but only if statically linked. I suspect that in this >> case the __pthread_mutex_init is a nop... >> likely due to weak aliasing... however, glibc does exactly the same call >> to memset >> and it uses >> >> #ifndef NOT_IN_libc >> __libc_lock_init (dirp->lock); >> #endif >> >> instead of __pthread_mutex_init(&(ptr->dd_lock), NULL); >> > > can you provide a test case ? i'd like to fix the real problem ... adding a > memset() just ignores the larger issue with every function that does > something similar. > -mike > Hi, below there is the test used by an our customer that reported the error. You can simplify it as you like. Anyway, regarding this issue, I was thinking in the past to review the use of pthread dor locking within the libc and use instead something like glibc (libc_lock)... any comments about this ? Carmelo sh4-linux-uclibc-gcc -g -o test test.c -lpthread -static ============================ source code ============= /* test.c for opendir and readdir */ #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #include #define MAX_FILE_LENGTH 1024 void printdir(char *dir); void readFile(const char *fileName); void *jvmCommunication(void *ptr); #define DIRTOOPEN "/var/java/appdb/" int main(void) { printf("test start\n"); // printdir(DIRTOOPEN); printf("before readfile\n"); readFile("/var/tvst.inf"); printf("after readfile.\n"); fflush(stdout); printdir(DIRTOOPEN); pthread_t t; pthread_create(&t, NULL, jvmCommunication, NULL); printf("after pthread_create.\n"); // printdir(DIRTOOPEN); return 0; } void printdir(char *dir) { DIR *pDir = NULL; struct dirent *ptEntry = NULL; printf("before opendir.(%s)\n",dir); fflush(stdout); if (NULL == (pDir = opendir(dir))) // open failed { printf("cann't open %s.\n", dir); return; } printf("after opendir.and before readdir.\n"); fflush(stdout); printf("it will be hang in here ..\n"); while ((ptEntry = readdir(pDir)) != NULL) { printf("DIR:"); printf("%s\n", ptEntry->d_name); } printf("after readdir.and before closedir.\n"); fflush(stdout); if (pDir != NULL) { closedir(pDir); } printf("after closedir.\n"); fflush(stdout); return; } void readFile(const char *flName) { FILE * flHandl = NULL; unsigned char ptChrUtf[MAX_FILE_LENGTH]; short ptChrUnicode[MAX_FILE_LENGTH]; memset(ptChrUtf, 0, MAX_FILE_LENGTH); memset(ptChrUnicode, 0, MAX_FILE_LENGTH * sizeof(short)); flHandl = fopen(flName, "rb"); printf("after open\n"); if(flHandl == NULL) //???????????? { return; } fread(ptChrUtf, sizeof(char), MAX_FILE_LENGTH, flHandl); printf("fread = %s\n", ptChrUtf); #if 1 printf("if remove fclose() in here , there will be no hang \n"); fclose(flHandl); //if removed it. there will be no hang #endif printf("after fclose!\n"); return; } void *jvmCommunication(void *ptr) { while(1) { sleep(1); printf("running ..!\n"); } } From vapier at gentoo.org Thu May 15 07:02:58 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 15 May 2008 10:02:58 -0400 Subject: svn commit: branches/uClibc-nptl/libc/misc/dirent In-Reply-To: <482C0CCE.7090207@st.com> References: <20071205172509.21874128569@busybox.net> <200805150532.38099.vapier@gentoo.org> <482C0CCE.7090207@st.com> Message-ID: <200805151002.59196.vapier@gentoo.org> On Thursday 15 May 2008, Carmelo AMOROSO wrote: > Mike Frysinger wrote: > > On Thursday 15 May 2008, Carmelo AMOROSO wrote: > >> Mike Frysinger wrote: > >>> On Wednesday 05 December 2007, carmelo at uclibc.org wrote: > >>>> Author: carmelo > >>>> Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007) > >>>> New Revision: 20626 > >>>> > >>>> Log: > >>>> Fix opendir problem when statically linked due to a missing > >>>> initialization of the mutex field within DIR struct. > >>>> When linked dynamically instead, __pthread_mutex_init will > >>>> initialize the mutex itself. Without this fix, any call to > >>>> readdir will stuck forever trying to acquire the mutex. > >>> > >>> sorry, but i dont follow. we call __pthread_mutex_init() on the > >>> dd_lock member of the dirent structure which should initialize the > >>> mutex just fine. you cant assume that zeroing the structure is the same > >>> as initializing the mutex. that is why we have these initializer > >>> functions in the first place. are you suggesting that the > >>> __pthread_mutex_init() function is not doing its job ? > >> > >> yes exactly... but only if statically linked. I suspect that in this > >> case the __pthread_mutex_init is a nop... > >> likely due to weak aliasing... however, glibc does exactly the same call > >> to memset > >> and it uses > >> > >> #ifndef NOT_IN_libc > >> __libc_lock_init (dirp->lock); > >> #endif > >> > >> instead of __pthread_mutex_init(&(ptr->dd_lock), NULL); > > > > can you provide a test case ? i'd like to fix the real problem ... > > adding a memset() just ignores the larger issue with every function that > > does something similar. > > below there is the test used by an our customer that reported the error. > You can simplify it as you like. unfortunately, it isnt hanging for me. but i'm testing Blackfin here. if i checkout uClibc trunk at the rev just before your commit and build it for sh4, that should be able to reproduce the issue, right ? (i have sh4 hardware i can test on). > Anyway, regarding this issue, I was thinking in the past to review the > use of pthread dor locking > within the libc and use instead something like glibc (libc_lock)... any > comments about this ? i'm not terribly familiar with how glibc does internal locking, but i dont see how it'd be any different from the locking we already have with uClibc_mutex.h. could you elaborate ? -mike -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 827 bytes Desc: This is a digitally signed message part. Url : http://busybox.net/lists/uclibc/attachments/20080515/f974daa3/attachment-0001.pgp From carmelo.amoroso at st.com Thu May 15 07:48:36 2008 From: carmelo.amoroso at st.com (Carmelo AMOROSO) Date: Thu, 15 May 2008 16:48:36 +0200 Subject: svn commit: branches/uClibc-nptl/libc/misc/dirent In-Reply-To: <200805151002.59196.vapier@gentoo.org> References: <20071205172509.21874128569@busybox.net> <200805150532.38099.vapier@gentoo.org> <482C0CCE.7090207@st.com> <200805151002.59196.vapier@gentoo.org> Message-ID: <482C4D44.2030008@st.com> Mike Frysinger wrote: > On Thursday 15 May 2008, Carmelo AMOROSO wrote: > >> Mike Frysinger wrote: >> >>> On Thursday 15 May 2008, Carmelo AMOROSO wrote: >>> >>>> Mike Frysinger wrote: >>>> >>>>> On Wednesday 05 December 2007, carmelo at uclibc.org wrote: >>>>> >>>>>> Author: carmelo >>>>>> Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007) >>>>>> New Revision: 20626 >>>>>> >>>>>> Log: >>>>>> Fix opendir problem when statically linked due to a missing >>>>>> initialization of the mutex field within DIR struct. >>>>>> When linked dynamically instead, __pthread_mutex_init will >>>>>> initialize the mutex itself. Without this fix, any call to >>>>>> readdir will stuck forever trying to acquire the mutex. >>>>>> >>>>> sorry, but i dont follow. we call __pthread_mutex_init() on the >>>>> dd_lock member of the dirent structure which should initialize the >>>>> mutex just fine. you cant assume that zeroing the structure is the same >>>>> as initializing the mutex. that is why we have these initializer >>>>> functions in the first place. are you suggesting that the >>>>> __pthread_mutex_init() function is not doing its job ? >>>>> >>>> yes exactly... but only if statically linked. I suspect that in this >>>> case the __pthread_mutex_init is a nop... >>>> likely due to weak aliasing... however, glibc does exactly the same call >>>> to memset >>>> and it uses >>>> >>>> #ifndef NOT_IN_libc >>>> __libc_lock_init (dirp->lock); >>>> #endif >>>> >>>> instead of __pthread_mutex_init(&(ptr->dd_lock), NULL); >>>> >>> can you provide a test case ? i'd like to fix the real problem ... >>> adding a memset() just ignores the larger issue with every function that >>> does something similar. >>> >> below there is the test used by an our customer that reported the error. >> You can simplify it as you like. >> > > unfortunately, it isnt hanging for me. but i'm testing Blackfin here. if i > checkout uClibc trunk at the rev just before your commit and build it for > sh4, that should be able to reproduce the issue, right ? (i have sh4 > hardware i can test on). > It should, even if the problem appeared on nptl port, but, from this point of view, you know, the code is the same. Anyway I have now a uclibc-linuxthreads for my sh4 target, I can check it. > >> Anyway, regarding this issue, I was thinking in the past to review the >> use of pthread dor locking >> within the libc and use instead something like glibc (libc_lock)... any >> comments about this ? >> > > i'm not terribly familiar with how glibc does internal locking, but i dont see > how it'd be any different from the locking we already have with > uClibc_mutex.h. could you elaborate ? > -mike > I need to review this... it is something I was looking at times ago. Give me some time. Carmelo From vapier at gentoo.org Thu May 15 08:03:00 2008 From: vapier at gentoo.org (Mike Frysinger) Date: Thu, 15 May 2008 11:03:00 -0400 Subject: svn commit: branches/uClibc-nptl/libc/misc/dirent In-Reply-To: <482C4D44.2030008@st.com> References: <20071205172509.21874128569@busybox.net> <200805151002.59196.vapier@gentoo.org> <482C4D44.2030008@st.com> Message-ID: <200805151103.00843.vapier@gentoo.org> On Thursday 15 May 2008, Carmelo AMOROSO wrote: > Mike Frysinger wrote: > > On Thursday 15 May 2008, Carmelo AMOROSO wrote: > >> Mike Frysinger wrote: > >>> On Thursday 15 May 2008, Carmelo AMOROSO wrote: > >>>> Mike Frysinger wrote: > >>>>> On Wednesday 05 December 2007, carmelo at uclibc.org wrote: > >>>>>> Author: carmelo > >>>>>> Date: 2007-12-05 09:25:08 -0800 (Wed, 05 Dec 2007) > >>>>>> New Revision: 20626 > >>>>>> > >>>>>> Log: > >>>>>> Fix opendir problem when statically linked due to a missing > >>>>>> initialization of the mutex field within DIR struct. > >>>>>> When linked dynamically instead, __pthread_mutex_init will > >>>>>> initialize the mutex itself. Without this fix, any call to > >>>>>> readdir will stuck forever trying to acquire the mutex. > >>>>> > >>>>> sorry, but i dont follow. we call __pthread_mutex_init() on the > >>>>> dd_lock member of the dirent structure which should initialize the > >>>>> mutex just fine. you cant assume that zeroing the structure is the > >>>>> same as initializing the mutex. that is why we have these > >>>>> initializer functions in the first place. are you suggesting that the > >>>>> __pthread_mutex_init() function is not doing its job ? > >>>> > >>>> yes exactly... but only if statically linked. I suspect that in this > >>>> case the __pthread_mutex_init is a nop... > >>>> likely due to weak aliasing... however, glibc does exactly the same > >>>> call to memset > >>>> and it uses > >>>> > >>>> #ifndef NOT_IN_libc > >>>> __libc_lock_init (dirp->lock); > >>>> #endif > >>>> > >>>> instead of __pthread_mutex_init(&(ptr->dd_lock), NULL); > >>> > >>> can you provide a test case ? i'd like to fix the real problem ... > >>> adding a memset() just ignores the larger issue with every function > >>> that does something similar. > >> > >> below there is the test used by an our customer that reported the error. > >> You can simplify it as you like. > > > > unfortunately, it isnt hanging for me. but i'm testing Blackfin here. > > if i checkout uClibc trunk at the rev just before your commit and build > > it for sh4, that should be able to reproduce the issue, right ? (i have > > sh4 hardware i can test on). > > It should, even if the problem appeared on nptl port, but, from this > point of view, you know, the code is > the same. Anyway I have now a uclibc-linuxthreads for my sh4 target, I > can check it. if you can verify the hang is still there, i can debug it. ive been debugging pthread issues the last few days, so i dont mind going a bit further. > >> Anyway, regarding this issue, I was thinking in the past to review the > >> use of pthr