From hjl@lucon.org Sun Jul 4 13:52:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 04 Jul 1999 13:52:00 -0000 Subject: A glibc dynamic linker or gld bug? Message-ID: <19990704205206.7C71E57B9@ocean.lucon.org> Hi, Here is a testcase for a glibc dynamic linker or gld bug: # make cc -shared -o libfoo.so -fPIC -O -g foo.c cc -o bar1.o -c -fPIC -O -g bar.c cc -o foo1 -O -g libfoo.so main.c bar1.o -Wl,-rpath,. cc -o bar2.o -c -O -g bar.c cc -o foo2 -O -g libfoo.so main.c bar2.o -Wl,-rpath,. for f in foo1 foo2; do echo "Running: $f"; ./$f; \ if [ $? != 0 ]; then echo Failed; fi; done Running: foo1 Failed Running: foo2 The same testcase ran fine under Solaris/x86 and Solaris/Sparc even with the GNU ld. I suspect the bug is in the weak symbol handling in the glibc dynamic linker. Since the Solaris dynamic linker treats weak as strong, the bug may also be in gld. -- H.J. Lu (hjl@gnu.org) -- begin 644 shared.tar.gz M'XL(`,S'?S<``^V7WVO;,!#'\QK]%;]@,4 MQTZ\.G)1'/HP]K]/LA,O@2;9'NP.>I^'&%FZTSFGK^^\6D@=S_A%IT'`H\+W MH0/`A$_M%=B(E]<-%"`0(R&\D:#<=R3_WZOS3P#>SS/."#M"&XMGCF><_507,8IEE M>22+&"Z!AN2I8T+:8ZO_C_(N3M(L;F*/4_H77-3Z#T1@9CGG#/7?!I.K#V_? M?;ITKL&9$W)S>VT&8(H!LS^<$/-F&$.O7TX,2#?)-220JOI6"+,&%>,/`MA&(1J\KL2II3-PLA2:TK M%1-B=Q]#EDYM35KEL)2I&T*J<,=VPQVS:GETR((? MMMA?&V6Q5&/2U4OCJDX&#.V3#LWS_77^M_JO_IYFSM@I_7/ZI_YSP6S]#SC6 M_U9X>:_E?"GA(99W.XT`>:PO*&\.[?F$_J`:$GMNS(C\)*7*^Z]VC(S8J[4# M8M,LI[DN*DL`'1=KK:S77]AO/"%;_;OSV315:='$'B?[?V9J?C#R&?>-_*W^ MN>D`4/]M,-56^*:V$;U6J,1GQU;_9=/1T!ZG],]VOO\Y$]7WOT#]M\&A^G^D G`;"-ZJ;B;ZKX3M''>HX@"((@"((@"((@"((@_P^_`1H*[V<`*``` ` end From wmglo@dent.med.uni-muenchen.de Sun Jul 4 14:41:00 1999 From: wmglo@dent.med.uni-muenchen.de (Wolfram Gloger) Date: Sun, 04 Jul 1999 14:41:00 -0000 Subject: malloc patch for overflow detection Message-ID: <19990704214141.16662.qmail@md.dent.med.uni-muenchen.de> OK, here is what I promised I would come up with to make even the strangest malloc test programs happy. It isn't perfect, but I can't measure a significant slowdown from the non-overflow checking version on Intel. If the patch cannot be applied to current glibc (it should) just yell and I will provide a line-number-clean version. Incidentally, my last malloc patch possibly wasn't applied completely, the realloc() part was dropped. Should I send it again? Regards, Wolfram. 1999-07-04 Wolfram Gloger * malloc/malloc.c (request2size): Check for overflow and return NULL whenever it is encountered. --- ptmalloc.c 1999/07/04 20:34:03 1.1.1.10 +++ ptmalloc.c 1999/07/04 21:08:24 @@ -1256,12 +1256,12 @@ #define chunk2mem(p) ((Void_t*)((char*)(p) + 2*SIZE_SZ)) #define mem2chunk(mem) ((mchunkptr)((char*)(mem) - 2*SIZE_SZ)) -/* pad request bytes into a usable size */ +/* pad request bytes into a usable size, return non-zero on overflow */ -#define request2size(req) \ - (((long)((req) + (SIZE_SZ + MALLOC_ALIGN_MASK)) < \ - (long)(MINSIZE + MALLOC_ALIGN_MASK)) ? MINSIZE : \ - (((req) + (SIZE_SZ + MALLOC_ALIGN_MASK)) & ~(MALLOC_ALIGN_MASK))) +#define request2size(req, nb) \ + ((nb = (req) + (SIZE_SZ + MALLOC_ALIGN_MASK)),\ + ((long)nb <= 0 ? 1 : ((nb < (MINSIZE + MALLOC_ALIGN_MASK) ? (nb = MINSIZE) :\ + (nb &= ~MALLOC_ALIGN_MASK)), 0))) /* Check if m has acceptable alignment */ @@ -2623,7 +2623,8 @@ } #endif - nb = request2size(bytes); + if(request2size(bytes, nb)) + return 0; arena_get(ar_ptr, nb); if(!ar_ptr) return 0; @@ -3126,7 +3127,8 @@ oldp = mem2chunk(oldmem); oldsize = chunksize(oldp); - nb = request2size(bytes); + if(request2size(bytes, nb)) + return 0; #if HAVE_MMAP if (chunk_is_mmapped(oldp)) @@ -3387,7 +3389,8 @@ if (alignment < MINSIZE) alignment = MINSIZE; - nb = request2size(bytes); + if(request2size(bytes, nb)) + return 0; arena_get(ar_ptr, nb + alignment + MINSIZE); if(!ar_ptr) return 0; @@ -3558,7 +3561,8 @@ } #endif - sz = request2size(n * elem_size); + if(request2size(n * elem_size, sz)) + return 0; arena_get(ar_ptr, sz); if(!ar_ptr) return 0; @@ -4344,8 +4348,10 @@ #endif { mchunkptr victim; - INTERNAL_SIZE_T nb = request2size(sz + 1); + INTERNAL_SIZE_T nb; + if(request2size(sz+1, nb)) + return 0; (void)mutex_lock(&main_arena.mutex); victim = (top_check() >= 0) ? chunk_alloc(&main_arena, nb) : NULL; (void)mutex_unlock(&main_arena.mutex); @@ -4410,7 +4416,10 @@ } oldsize = chunksize(oldp); - nb = request2size(bytes+1); + if(request2size(bytes+1, nb)) { + (void)mutex_unlock(&main_arena.mutex); + return 0; + } #if HAVE_MMAP if (chunk_is_mmapped(oldp)) { @@ -4466,7 +4475,8 @@ if (alignment <= MALLOC_ALIGNMENT) return malloc_check(bytes); if (alignment < MINSIZE) alignment = MINSIZE; - nb = request2size(bytes+1); + if(request2size(bytes+1, nb)) + return 0; (void)mutex_lock(&main_arena.mutex); p = (top_check() >= 0) ? chunk_align(&main_arena, nb, alignment) : NULL; (void)mutex_unlock(&main_arena.mutex); @@ -4486,7 +4496,12 @@ malloc_starter(sz) size_t sz; #endif { - mchunkptr victim = chunk_alloc(&main_arena, request2size(sz)); + INTERNAL_SIZE_T nb; + mchunkptr victim; + + if(request2size(sz, nb)) + return 0; + victim = chunk_alloc(&main_arena, nb); return victim ? chunk2mem(victim) : 0; } @@ -4522,16 +4537,20 @@ #endif { Void_t *vptr = NULL; + INTERNAL_SIZE_T nb; mchunkptr victim; tsd_getspecific(arena_key, vptr); if(!vptr) { if(save_malloc_hook != malloc_check) { - victim = chunk_alloc(&main_arena, request2size(sz)); + if(request2size(sz, nb)) + return 0; + victim = chunk_alloc(&main_arena, nb); return victim ? chunk2mem(victim) : 0; } else { - if(top_check() < 0) return 0; - victim = chunk_alloc(&main_arena, request2size(sz+1)); + if(top_check()<0 || request2size(sz+1, nb)) + return 0; + victim = chunk_alloc(&main_arena, nb); return victim ? chunk2mem_check(victim, sz) : 0; } } else { -- `Surf the sea, not double-u three...' wmglo@dent.med.uni-muenchen.de From hjl@lucon.org Sun Jul 4 16:51:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sun, 04 Jul 1999 16:51:00 -0000 Subject: Serious C++ linking error Message-ID: <19990704235138.E65F557B9@ocean.lucon.org> I am enclosing a simplified testcase for the bug. It is a very complicated bug due to the weak symbol handling in glibc and gld. It doesn't happen on Solaris where weak symbols in DSO are treated as strong and the dynamic linker treats all weak symbols as strong. I don't know if there is a reasonable fix from glibc or gld. I tend to believe the bug is in g++. Basically under glibc, for the same symbol, g++ has to make it either weak or strong in all cases, compiler-generated or not. Otherwise, bad things can happen. -- H.J. Lu (hjl@gnu.org) -- begin 644 shared.tar.gz M'XL(`"CL?S<``^U876_:,!3E%?^*.\HFJ$@:FWQ(9-U6T76:MJE5^]"'=9-" MXH"WX%0AB$[3_OOLA*1`H;330A_J\Y`0V]?WVK['/G@R\A(:D(-:A0#3<"P+ M:@#8L0SY!MPEV7L.`\!VNHYCVT;7$;6&Z9`:6%4&56`Z2;T$H#;Z$=W;3C0+ MPUT$M%M,YNL?QK'N5^0#&X9MFIO7'SMFL?[$$HD"&%L&KH%143Q+>.;KO\>X M'TT#"J\G:Z,"K6_.V*]HF-)TF?+'817_04X]=X9;_7[R?-&01K<+' M%OYCT^@6_.\2T0`P(=A1_-\%^B>?CSY<'&JGH`T1.CL_%1^2S%@^",RRG_)) M$!+<[4&SE35JHWH8)Q`"XV61"T$,U!_%T#B?C(6U66RPKZ< MBWTQ`4]-P2=%L?_G25&-CVWZSR2XU'\V-J7^L[M*_^T$>RP,:`@9Q_:N$V\X M]F!&O9\+`G"M'MRCT62U1I;R@(5SL2C9+<2B.__*I6.N))%,MUQ((A$!&"@[ M%UH+`E$>#WD';223Q!O$29IUD+M>$*#TAOJ=;%N[1X(6[J$,JPBVE*?&,Q2E M!?_U83!@G*55^-C&?\"VX'_7PL0B#L92_PD%J/B_"PP2279!#I1,^7-+?H62 M_YD2J\C'-OX3Q[Z]_S&S^Q_3-A7_=X%U]S\/T03_*@KD?Z+5"Z3\_!85Z@9) ;04%!04%!04%!04%!04%!X;_C+^),&@L`*``` ` end From geoffk@ozemail.com.au Mon Jul 5 02:38:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Mon, 05 Jul 1999 02:38:00 -0000 Subject: A glibc dynamic linker or gld bug? References: <19990704205206.7C71E57B9@ocean.lucon.org> <19990704205206.7C71E57B9@ocean.lucon.org> Message-ID: <199907050455.OAA00862@geoffk.wattle.id.au> > Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm > Date: Sun, 4 Jul 1999 13:52:06 -0700 (PDT) > Cc: ian@cygnus.com (Ian Lance Taylor), binutils@sourceware.cygnus.com, > libc-hacker@sourceware.cygnus.com (GNU C Library), jgg@ualberta.ca > From: hjl@lucon.org (H.J. Lu) > > Hi, > > Here is a testcase for a glibc dynamic linker or gld bug: > > # make > cc -shared -o libfoo.so -fPIC -O -g foo.c > cc -o bar1.o -c -fPIC -O -g bar.c > cc -o foo1 -O -g libfoo.so main.c bar1.o -Wl,-rpath,. > cc -o bar2.o -c -O -g bar.c > cc -o foo2 -O -g libfoo.so main.c bar2.o -Wl,-rpath,. > for f in foo1 foo2; do echo "Running: $f"; ./$f; \ > if [ $? != 0 ]; then echo Failed; fi; done > Running: foo1 > Failed > Running: foo2 > > The same testcase ran fine under Solaris/x86 and Solaris/Sparc even > with the GNU ld. I suspect the bug is in the weak symbol handling > in the glibc dynamic linker. Since the Solaris dynamic linker treats > weak as strong, the bug may also be in gld. I can't reproduce this on ppc with binutils snapshot from 981225, and the released 2.1.1 ld.so. I suspect there is a (possibly machine-specific) bug in your ld; in fact, I would suspect the problem is in linking PIC code into executables. On my machine, the dynamic linker has no influence whatsoever on whether 'abort' is called in foo1 or foo2. The complete list of relocations generated is: [geoffk@geoffk shared2]$ objdump -R foo1 foo1: file format elf32-powerpc DYNAMIC RELOCATION RECORDS OFFSET TYPE VALUE 018406d4 R_PPC_JMP_SLOT abort 018406dc R_PPC_JMP_SLOT __libc_start_main and it's the same for foo2. This is correct. There is no way that a weak symbol defined in an executable can be overriden by anything else, so there should be no relocations referring to it. -- Geoffrey Keating From rth@twiddle.net Mon Jul 5 20:48:00 1999 From: rth@twiddle.net (Richard Henderson) Date: Mon, 05 Jul 1999 20:48:00 -0000 Subject: A glibc dynamic linker or gld bug? References: <19990704205206.7C71E57B9@ocean.lucon.org> <199907050455.OAA00862@geoffk.wattle.id.au> Message-ID: <19990705204814.A26423@twiddle.net> On Mon, Jul 05, 1999 at 02:55:51PM +1000, Geoff Keating wrote: > There is no way that a weak symbol defined in an > executable can be overriden by anything else, so there should be no > relocations referring to it. In the weak model prefered by glibc and SGI, sure there is. A strong symbol defined in a shared library will override the weak symbol in the main executable. But this is not the model Sun prefers, since it kills their cute lazy loading scheme. r~ From geoffk@ozemail.com.au Tue Jul 6 01:01:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Tue, 06 Jul 1999 01:01:00 -0000 Subject: A glibc dynamic linker or gld bug? References: <19990704205206.7C71E57B9@ocean.lucon.org> <199907050455.OAA00862@geoffk.wattle.id.au> <19990705204814.A26423@twiddle.net> Message-ID: <199907060800.SAA01123@geoffk.wattle.id.au> > Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm > Date: Mon, 5 Jul 1999 20:48:14 -0700 > From: Richard Henderson > Cc: hjl@lucon.org, drepper@cygnus.com, ian@cygnus.com, > binutils@sourceware.cygnus.com, libc-hacker@sourceware.cygnus.com, > jgg@ualberta.ca > > On Mon, Jul 05, 1999 at 02:55:51PM +1000, Geoff Keating wrote: > > There is no way that a weak symbol defined in an > > executable can be overriden by anything else, so there should be no > > relocations referring to it. > > In the weak model prefered by glibc and SGI, sure there is. > A strong symbol defined in a shared library will override > the weak symbol in the main executable. > > But this is not the model Sun prefers, since it kills their > cute lazy loading scheme. I now understand the bug report. The problem on powerpc would look similar if ld was trying to implement that weak symbol model. However, clearly it is not, at least not for data objects. The problem is that, for instance in the executable given, it is necessary to emit a R_*_COPY reloc for any data objects which are defined weak. The current linker (well, the 981225 snapshot), however, only does this for data objects that go in the .dyn.bss pseudo-section, at least on i386, sparc, and ppc; that is, data objects that are not defined in the application. Note that in this case, ld.so is responsible for determining where the 'true' data for the data object is, and using it for the R_*_COPY reloc. It is also responsible for not doing the copy if it turned out that there is never a strong definition of the symbol. It must also ensure that any relocs to the weak symbol (from shared libraries) end up pointed to the copy in the application, in the same way that relocs to functions in shared libraries end up pointed to a PLT entry in the application instead of the real function. To make all this clear, I attach a shell script. On ppc, it prints the following at the end: + ./weak-w-wp-wm 1 1 1 + ./weak-w-sp-wm 1 2 1 + ./weak-wp-wm-s 1 1 1 + ./weak-sp-wm-s 1 1 1 On sparc-solaris it prints: + ./weak-w-wp-wm 1 1 1 + ./weak-w-sp-wm 1 1 1 + ./weak-wp-wm-s 1 1 1 + ./weak-sp-wm-s 1 1 1 which is what I expected. You're saying that it should print, on glibc + ./weak-w-wp-wm 1 1 1 + ./weak-w-sp-wm 2 2 2 + ./weak-wp-wm-s 1 1 1 + ./weak-sp-wm-s 1 1 1 -- Geoffrey Keating ===File ~/glibc-tests/weaktest.c============================ #define CONCAT(x,y) x ## y #define CONCAT2(x,y) CONCAT(x,y) #define STRING(x) #x #define STRING2(x) STRING(x) #ifdef WEAKDATA #pragma weak dataitem #endif const char *dataitem = "weaktest-" STRING2(NUM) ".c"; const char *CONCAT2(getdataitem_,NUM)(void) { return dataitem; } extern const char *getdataitem_1(void); extern const char *getdataitem_2(void); extern const char *getdataitem_3(void); extern const char *getdataitem_4(void); #ifdef MAIN #include int main(void) { static const char *(*const (funcs[MAIN]))(void) = { getdataitem_1, #if MAIN >= 2 getdataitem_2, #endif #if MAIN >= 3 getdataitem_3, #endif #if MAIN >= 4 getdataitem_4 #endif }; int i; for (i = 0; i < MAIN; i++) if (funcs[i]) printf("getdataitem_%d has getdataitem defined in %s\n", i+1, funcs[i]()); else printf("getdataitem_%d is NULL\n", i+1); } #endif ============================================================ ===File ~/glibc-tests/weaktest.sh=========================== #!/bin/sh set -x set -e gcc -c -DNUM=1 weaktest.c -O -o weak1-strong.o gcc -c -DNUM=1 -DWEAKDATA weaktest.c -O -o weak1-weak.o gcc -c -DNUM=1 -fpic -DWEAKDATA weaktest.c -O -o weak1-weak-pic.o gcc -shared -DNUM=2 -DWEAKDATA -fpic weaktest.c -O -o weak2-weak-pic.so gcc -shared -DNUM=2 -DWEAKDATA -fpic weaktest.c -O -o weak2-strong-pic.so gcc -c -DNUM=3 -DWEAKDATA -DMAIN=3 weaktest.c -O -o weak3-weak-main.o gcc weak1-weak.o ./weak2-weak-pic.so weak3-weak-main.o -o weak-w-wp-wm gcc weak1-weak.o ./weak2-strong-pic.so weak3-weak-main.o -o weak-w-sp-wm gcc weak1-strong.o ./weak2-strong-pic.so weak3-weak-main.o -o weak-s-sp-wm gcc ./weak2-strong-pic.so weak3-weak-main.o weak1-strong.o -o weak-sp-wm-s ============================================================ From geoffk@ozemail.com.au Tue Jul 6 12:16:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Tue, 06 Jul 1999 12:16:00 -0000 Subject: A glibc dynamic linker or gld bug? References: <19990704205206.7C71E57B9@ocean.lucon.org> <199907050455.OAA00862@geoffk.wattle.id.au> <19990705204814.A26423@twiddle.net> <199907060800.SAA01123@geoffk.wattle.id.au> Message-ID: <199907061916.FAA00483@geoffk.wattle.id.au> Um. The test case wouldn't have made things much clearer because I sent the wrong version. Try this. -- Geoffrey Keating ===File ~/glibc-tests/weaktest.c============================ #define CONCAT(x,y) x ## y #define CONCAT2(x,y) CONCAT(x,y) #define STRING(x) #x #define STRING2(x) STRING(x) #ifdef WEAKDATA #pragma weak dataitem #endif int dataitem = NUM; int CONCAT2(getdataitem_,NUM)(void) { return dataitem; } extern int getdataitem_1(void); extern int getdataitem_2(void); extern int getdataitem_3(void); extern int getdataitem_4(void); #ifdef MAIN #include int main(void) { static int (*const (funcs[MAIN]))(void) = { getdataitem_1, #if MAIN >= 2 getdataitem_2, #endif #if MAIN >= 3 getdataitem_3, #endif #if MAIN >= 4 getdataitem_4 #endif }; int i; for (i = 0; i < MAIN; i++) if (funcs[i]) printf("%d ", funcs[i]()); else printf("NULL ", i+1); printf("\n"); } #endif ============================================================ ===File ~/glibc-tests/weaktest.sh=========================== #!/bin/sh set -x set -e gcc -c -DNUM=1 weaktest.c -O -o weak1-strong.o gcc -c -DNUM=1 -DWEAKDATA weaktest.c -O -o weak1-weak.o gcc -c -DNUM=1 -fpic -DWEAKDATA weaktest.c -O -o weak1-weak-pic.o gcc -shared -DNUM=2 -DWEAKDATA -fpic weaktest.c -O -o weak2-weak-pic.so gcc -shared -DNUM=2 -fpic weaktest.c -O -o weak2-strong-pic.so gcc -c -DNUM=3 -DWEAKDATA -DMAIN=3 weaktest.c -O -o weak3-weak-main.o gcc weak1-weak.o ./weak2-weak-pic.so weak3-weak-main.o -o weak-w-wp-wm gcc weak1-weak.o ./weak2-strong-pic.so weak3-weak-main.o -o weak-w-sp-wm gcc ./weak2-weak-pic.so weak3-weak-main.o weak1-strong.o -o weak-wp-wm-s gcc ./weak2-strong-pic.so weak3-weak-main.o weak1-strong.o -o weak-sp-wm-s set +e ./weak-w-wp-wm ./weak-w-sp-wm ./weak-wp-wm-s ./weak-sp-wm-s ============================================================ From drepper@cygnus.com Tue Jul 6 15:29:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 06 Jul 1999 15:29:00 -0000 Subject: malloc patch for overflow detection References: <19990704214141.16662.qmail@md.dent.med.uni-muenchen.de> Message-ID: Wolfram Gloger writes: > OK, here is what I promised I would come up with to make even the > strangest malloc test programs happy. Thanks, I've applied the patch. > Incidentally, my last malloc patch possibly wasn't applied completely, > the realloc() part was dropped. Should I send it again? Yes. I anything is missing I don't have it anymore. Thanks, -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From rth@twiddle.net Tue Jul 6 19:28:00 1999 From: rth@twiddle.net (Richard Henderson) Date: Tue, 06 Jul 1999 19:28:00 -0000 Subject: A glibc dynamic linker or gld bug? References: <19990704205206.7C71E57B9@ocean.lucon.org> <199907050455.OAA00862@geoffk.wattle.id.au> <19990705204814.A26423@twiddle.net> <19990707021030.28537.qmail@daffy.airs.com> Message-ID: <19990706192811.A20081@twiddle.net> On Tue, Jul 06, 1999 at 10:10:30PM -0400, Ian Lance Taylor wrote: > In order to implement ``strong defined symbol in shared library > overrides weak defined symbol in main executable'' correctly, we must > ensure that all relocations involving weak defined symbols in the > executable become dynamic relocations resolved at run time. /* Should we do dynamic things to this symbol? */ #define alpha_elf_dynamic_symbol_p(h, info) \ ((((info)->shared && !(info)->symbolic) \ || (((h)->elf_link_hash_flags \ & (ELF_LINK_HASH_DEF_DYNAMIC | ELF_LINK_HASH_REF_REGULAR)) \ == (ELF_LINK_HASH_DEF_DYNAMIC | ELF_LINK_HASH_REF_REGULAR)) \ || (h)->root.type == bfd_link_hash_undefweak \ || (h)->root.type == bfd_link_hash_defweak) \ && (h)->dynindx != -1) This should probably just be generic. > Are we willing to pay that price for all weak defined symbols in all > dynamically linked executables? I think so. There are really very few of them in practice. And failing to override weak symbols is surprising behaviour from my point of view. > It is perhaps worth noting that the System V linker and the SGI > linker, unlike the GNU linker and the Solaris linker, considers a weak > definition followed by a strong definition to be a multiple definition > error. Really? SGI does this? I'm a bit surprised. > (I am therefore a bit surprised to hear that the SGI dynamic > linker permits a strong definition in a shared library to override a > weak definition in an executable, since that appears to contradict the > program linker's behaviour.) This based on how Uli reported that SGI was arguing the weak symbol behaviour at load time topic at the IA64 ELF ABI meetings. (Which, btw, has reportedly degenerated into a generic ELF ABI meeting.) r~ From hjl@lucon.org Tue Jul 6 21:45:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Tue, 06 Jul 1999 21:45:00 -0000 Subject: A glibc dynamic linker or gld bug? References: <19990707021030.28537.qmail@daffy.airs.com> Message-ID: <19990707044502.A80DE57B9@ocean.lucon.org> > If we do not, then we will fail to implement the model correctly. > Consider the case in which a main executable defines a symbol weakly, > and a shared library does not define it at all. At present we will > not generate any dynamic relocations for the weak defined symbol. > > However, if we later replace the shared library with one which does > have a strong definition for the symbol, then correct operation would > appear to require that that strong symbol override the weak symbol in > the main executable. > > As far as I can see, this can only happen if all relocations involving > the weak defined symbol are copied into the executable as dynamic > relocations. What if the definition in executable is strong? Do you have the same problem? I don't think we should worry about this. > > Are we willing to pay that price for all weak defined symbols in all > dynamically linked executables? > > Should we instead go for the half-measure of only copying relocations > for weak defined symbols in the case where we link against a shared > library which has a strong definition for the symbol? It's easy to > predict that we will get bug reports on this in the future. > I have sent a patch to implement this. H.J. From geoffk@ozemail.com.au Wed Jul 7 01:33:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Wed, 07 Jul 1999 01:33:00 -0000 Subject: A glibc dynamic linker or gld bug? References: <19990704205206.7C71E57B9@ocean.lucon.org> <199907050455.OAA00862@geoffk.wattle.id.au> <19990705204814.A26423@twiddle.net> <19990707021030.28537.qmail@daffy.airs.com> Message-ID: <199907070823.SAA00550@geoffk.wattle.id.au> > Date: 6 Jul 1999 22:10:30 -0400 > From: Ian Lance Taylor > In order to implement ``strong defined symbol in shared library > overrides weak defined symbol in main executable'' correctly, we must > ensure that all relocations involving weak defined symbols in the > executable become dynamic relocations resolved at run time. > > If we do not, then we will fail to implement the model correctly. > Consider the case in which a main executable defines a symbol weakly, > and a shared library does not define it at all. At present we will > not generate any dynamic relocations for the weak defined symbol. There are also other cases that seem to go wrong at present. For instance, consider the case where an executable references a weak symbol, but it is not defined anywhere. Then, later, some shared object defines it. Usually, the address of the symbol (that is, NULL), has been compiled into the executable in many places and no relocs are/can be generated. Or the converse; if the weak symbol is initially defined in a shared object, referenced by the executable, but later becomes undefined. I think that if such a thing happens, it should be an error in ld.so (only for symbols referenced by the executable, of course). It would be nice to make the first case a visible error too. These cases are not fixable under the usual non-pic-executable model, in which all addresses referenced by the executable are fixed at link time. -- Geoffrey Keating From aj@arthur.rhein-neckar.de Wed Jul 7 10:42:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Wed, 07 Jul 1999 10:42:00 -0000 Subject: malloc patch for overflow detection References: <19990704214141.16662.qmail@md.dent.med.uni-muenchen.de> Message-ID: >>>>> Wolfram Gloger writes: > OK, here is what I promised I would come up with to make even the > strangest malloc test programs happy. It isn't perfect, but I can't > measure a significant slowdown from the non-overflow checking version > on Intel. If the patch cannot be applied to current glibc (it should) > just yell and I will provide a line-number-clean version. Sorry, the request2size macro isn't working correctly. Please try the appended test program (I wouldn't call it strange;-), it will report that malloc (-1) still fails. The problem with request2size is that incrementing -1 leads to a positive value. You might need to check req for <= 0. Andreas /* Copyright (C) 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Andreas Jaeger , 1999. The GNU C Library is free software; you can redistribute it and/or modify it under the terms of the GNU Library General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. The GNU C Library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Library General Public License for more details. You should have received a copy of the GNU Library General Public License along with the GNU C Library; see the file COPYING.LIB. If not, write to the Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ #include #include #include static int errors = 0; static void merror (const char *msg) { errors++; printf ("Error: %s\n", msg); } int main (void) { void *p; int save; errno = 0; p = malloc (-1); save = errno; if (p != NULL) merror ("malloc (-1) succeeded."); if (p == NULL && save != ENOMEM) merror ("errno is not set correctly"); p = malloc (10); if (p == NULL) merror ("malloc (10) failed."); /* realloc (p, 0) == free (p). */ p = realloc (p, 0); if (p != NULL) merror ("realloc (p, 0) failed."); p = malloc (0); if (p == NULL) merror ("malloc (0) failed."); p = realloc (p, 0); if (p != NULL) merror ("realloc (p, 0) failed."); return (errors != 0); } -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Thu Jul 8 12:02:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 08 Jul 1999 12:02:00 -0000 Subject: putenv/setenv Message-ID: Is anybody volunteering to look at the putenv/setenv problem? I've described the problem and a possible solution in a comment in sysdeps/generic/setenv.c. It's not hard. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@varesearch.com Fri Jul 9 16:28:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Fri, 09 Jul 1999 16:28:00 -0000 Subject: A getxxx_r version patch Message-ID: <19990709232852.2F64C3FC1@varesearch.com> Since we changed the return value of getxxx_r, I added a new version for each function and kept the old one. -- H.J. Lu (hjl@gnu.org) -- Fri Jul 9 14:36:25 1999 H.J. Lu * Versions.def (GLIBC_2.1.2): Added. * nss/getXXent_r.c: Make the new ABI GLIBC_2.1.2 and keep the old one as GLIBC_2.0. * nss/getXXbyYY_r.c: Likewise. * grp/Versions (getgrent_r, getgrgid_r, getgrnam_r): Added to GLIBC_2.1.2. * inet/Versions (getaliasbyname_r, getaliasent_r, gethostbyaddr_r, gethostbyname2_r, gethostbyname_r, gethostent_r, getnetbyaddr_r, getnetbyname_r, getnetent_r, getnetgrent_r, getprotobyname_r, getprotobynumber_r, getprotoent_r, getrpcbyname_r, getrpcbynumber_r, getrpcent_r, getservbyname_r): Likewise. * pwd/Versions (getpwent_r, getpwuid_r): Likewise. * shadow/Versions (getspent_r, getspnam_r): Likewise. Index: Versions.def =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/Versions.def,v retrieving revision 1.1.1.5 diff -u -p -r1.1.1.5 Versions.def --- Versions.def 1999/05/10 15:33:17 1.1.1.5 +++ Versions.def 1999/07/09 20:35:29 @@ -5,6 +5,7 @@ libc { GLIBC_2.0 GLIBC_2.1 GLIBC_2.0 GLIBC_2.1.1 GLIBC_2.1 + GLIBC_2.1.2 GLIBC_2.1.1 } libcrypt { GLIBC_2.0 Index: nss/getXXent_r.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/nss/getXXent_r.c,v retrieving revision 1.1.1.10 diff -u -p -r1.1.1.10 getXXent_r.c --- nss/getXXent_r.c 1999/06/27 01:14:34 1.1.1.10 +++ nss/getXXent_r.c 1999/07/09 21:08:58 @@ -290,5 +290,33 @@ INTERNAL (REENTRANT_GETNAME) (LOOKUP_TYP *result = status == NSS_STATUS_SUCCESS ? resbuf : NULL; return status == NSS_STATUS_SUCCESS ? 0 : errno; } +#if defined SHARED && DO_VERSIONING +#define OLD(name) OLD1 (name) +#define OLD1(name) __old_##name + +int +OLD (REENTRANT_GETNAME) (LOOKUP_TYPE *resbuf, char *buffer, size_t buflen, + LOOKUP_TYPE **result H_ERRNO_PARM) +{ + int ret = INTERNAL (REENTRANT_GETNAME) (resbuf, buffer, buflen, + result H_ERRNO_VAR); + + if (ret != 0) + ret = -1; + + return ret; +} + +#define do_symbol_version(real, name, version) \ + symbol_version(real, name, version) +do_symbol_version(OLD (REENTRANT_GETNAME), REENTRANT_GETNAME, + GLIBC_2.0); + +#define do_default_symbol_version(real, name, version) \ + default_symbol_version(real, name, version) +do_default_symbol_version(INTERNAL (REENTRANT_GETNAME), + REENTRANT_GETNAME, GLIBC_2.1.2); +#else #define do_weak_alias(n1, n2) weak_alias (n1, n2) do_weak_alias (INTERNAL (REENTRANT_GETNAME), REENTRANT_GETNAME) +#endif Index: nss/getXXbyYY_r.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/nss/getXXbyYY_r.c,v retrieving revision 1.1.1.15 diff -u -p -r1.1.1.15 getXXbyYY_r.c --- nss/getXXbyYY_r.c 1999/06/27 01:14:33 1.1.1.15 +++ nss/getXXbyYY_r.c 1999/07/09 21:09:05 @@ -208,5 +208,32 @@ done: return status == NSS_STATUS_SUCCESS ? 0 : errno; } +#if defined SHARED && DO_VERSIONING +#define OLD(name) OLD1 (name) +#define OLD1(name) __old_##name + +int +OLD (REENTRANT_NAME) (ADD_PARAMS, LOOKUP_TYPE *resbuf, char *buffer, + size_t buflen, LOOKUP_TYPE **result H_ERRNO_PARM) +{ + int ret = INTERNAL (REENTRANT_NAME) (ADD_VARIABLES, resbuf, buffer, + buflen, result H_ERRNO_VAR); + + if (ret != 0) + ret = -1; + + return ret; +} + +#define do_symbol_version(real, name, version) \ + symbol_version(real, name, version) +do_symbol_version(OLD (REENTRANT_NAME), REENTRANT_NAME, GLIBC_2.0); + +#define do_default_symbol_version(real, name, version) \ + default_symbol_version(real, name, version) +do_default_symbol_version(INTERNAL (REENTRANT_NAME), REENTRANT_NAME, + GLIBC_2.1.2); +#else #define do_weak_alias(n1, n2) weak_alias (n1, (n2)) do_weak_alias (INTERNAL (REENTRANT_NAME), REENTRANT_NAME) +#endif Index: grp/Versions =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/grp/Versions,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 Versions --- grp/Versions 1998/08/11 22:26:48 1.1.1.2 +++ grp/Versions 1999/07/09 20:30:13 @@ -20,4 +20,8 @@ libc { # p* putgrent; } + GLIBC_2.1.2 { + # g* + getgrent_r; getgrgid_r; getgrnam_r; + } } Index: inet/Versions =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/inet/Versions,v retrieving revision 1.1.1.2 diff -u -p -r1.1.1.2 Versions --- inet/Versions 1998/12/05 16:05:36 1.1.1.2 +++ inet/Versions 1999/07/09 20:31:55 @@ -54,4 +54,12 @@ libc { # i* if_freenameindex; if_indextoname; if_nameindex; if_nametoindex; } + GLIBC_2.1.2 { + # g* + getaliasbyname_r; getaliasent_r; gethostbyaddr_r; gethostbyname2_r; + gethostbyname_r; gethostent_r; getnetbyaddr_r; getnetbyname_r; + getnetent_r; getnetgrent_r; getprotobyname_r; getprotobynumber_r; + getprotoent_r; getrpcbyname_r; getrpcbynumber_r; getrpcent_r; + getservbyname_r; + } } Index: pwd/Versions =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/pwd/Versions,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Versions --- pwd/Versions 1998/07/15 00:20:03 1.1.1.1 +++ pwd/Versions 1999/07/09 20:25:45 @@ -12,4 +12,8 @@ libc { # p* putpwent; setpwent; } + GLIBC_2.1.2 { + # g* + getpwent_r; getpwuid_r; + } } Index: shadow/Versions =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/shadow/Versions,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 Versions --- shadow/Versions 1998/07/15 00:20:09 1.1.1.1 +++ shadow/Versions 1999/07/09 20:29:55 @@ -24,4 +24,8 @@ libc { # u* ulckpwdf; } + GLIBC_2.1.2 { + # g* + getspent_r; getspnam_r; + } } From drepper@cygnus.com Fri Jul 9 20:50:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 09 Jul 1999 20:50:00 -0000 Subject: A getxxx_r version patch References: <19990709213944.B199E3FC1@varesearch.com> Message-ID: Thanks, it's in. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From kettenis@wins.uva.nl Sat Jul 10 05:43:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Sat, 10 Jul 1999 05:43:00 -0000 Subject: A getxxx_r version patch References: <19990709232852.2F64C3FC1@varesearch.com> Message-ID: <199907101211.OAA00568@delius.kettenis.nl> Date: Fri, 9 Jul 1999 16:28:52 -0700 (PDT) From: hjl@varesearch.com (H.J. Lu) Since we changed the return value of getxxx_r, I added a new version for each function and kept the old one. I think you should also set errno since the new functions do not necessarily do this. The whole point of having getXXbyYY_r returning the error value is avoiding the use of thread-specific data. So instead of: if (ret != 0) ret = -1; we should use if (ret != 0) { __set_errno (ret); ret = -1; } Mark From hjl@lucon.org Sat Jul 10 08:15:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 10 Jul 1999 08:15:00 -0000 Subject: A getxxx_r version patch References: <199907101211.OAA00568@delius.kettenis.nl> Message-ID: <19990710151543.AC3C857B9@ocean.lucon.org> > > Date: Fri, 9 Jul 1999 16:28:52 -0700 (PDT) > From: hjl@varesearch.com (H.J. Lu) > > Since we changed the return value of getxxx_r, I added a new version > for each function and kept the old one. > > I think you should also set errno since the new functions do not > necessarily do this. The whole point of having getXXbyYY_r returning > the error value is avoiding the use of thread-specific data. > I don't know what you mean. The new functions return "errno" in case of errors. Why do you want to set "errno" with "errno"? -- H.J. Lu (hjl@gnu.org) From kukuk@suse.de Sat Jul 10 08:20:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Sat, 10 Jul 1999 08:20:00 -0000 Subject: A getxxx_r version patch References: <199907101211.OAA00568@delius.kettenis.nl> <19990710151543.AC3C857B9@ocean.lucon.org> Message-ID: <19990710172010.A10939@Wotan.suse.de> On Sat, Jul 10, H.J. Lu wrote: > > > > Date: Fri, 9 Jul 1999 16:28:52 -0700 (PDT) > > From: hjl@varesearch.com (H.J. Lu) > > > > Since we changed the return value of getxxx_r, I added a new version > > for each function and kept the old one. > > > > I think you should also set errno since the new functions do not > > necessarily do this. The whole point of having getXXbyYY_r returning > > the error value is avoiding the use of thread-specific data. > > > > I don't know what you mean. The new functions return "errno" in case > of errors. Why do you want to set "errno" with "errno"? The old functions sets errno and returns -1. But POSIX only says, that the functions should return the errno value, and not setting errno. So if the next functions or a later version will only return the errno value, and doesn't set errno, your "old" functions will not longer work. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Deutschherrenstr. 15-19 90429 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From hjl@lucon.org Sat Jul 10 08:28:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 10 Jul 1999 08:28:00 -0000 Subject: A getxxx_r version patch References: <19990710172010.A10939@Wotan.suse.de> Message-ID: <19990710152759.42D4857B9@ocean.lucon.org> > > > > > > I think you should also set errno since the new functions do not > > > necessarily do this. The whole point of having getXXbyYY_r returning > > > the error value is avoiding the use of thread-specific data. > > > > > > > I don't know what you mean. The new functions return "errno" in case > > of errors. Why do you want to set "errno" with "errno"? > > The old functions sets errno and returns -1. But POSIX only says, > that the functions should return the errno value, and not setting errno. > So if the next functions or a later version will only return the errno > value, and doesn't set errno, your "old" functions will not longer work. > My patch is based on the current implementation which does set errno. If we ever change this, we can deal it later. BTW, if we have to do that, it won't be the only place we have to change. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Sat Jul 10 09:24:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 10 Jul 1999 09:24:00 -0000 Subject: A getxxx_r version patch References: <19990709232852.2F64C3FC1@varesearch.com> <199907101211.OAA00568@delius.kettenis.nl> Message-ID: Mark Kettenis writes: > > if (ret != 0) > { > __set_errno (ret); > ret = -1; > } This already happens. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sat Jul 10 15:02:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 10 Jul 1999 15:02:00 -0000 Subject: binutils 2.9.4.0.8 is released. Message-ID: <19990710220232.B6DF657B9@ocean.lucon.org> This is the beta release of binutils 2.9.4.0.8 for Linux, which is based on binutils 1999 0710 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. Please report any bugs related to binutils 2.9.4.0.8 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.4.0.8.tar.gz. Source code. 2. binutils-2.9.4.0.7-2.9.4.0.8.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.4.0.8-1.src.rpm. Source RPM. 4. binutils-2.9.4.0.8-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 07/10/99 From hjl@varesearch.com Sun Jul 11 17:44:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Sun, 11 Jul 1999 17:44:00 -0000 Subject: A patch for nscd Message-ID: <19990712004406.560C93FC1@varesearch.com> nscd has its own get[a-z]*_r functions. But nscd uses the weak names to call those functions. As the result of my get[a-z]*_r version change, which makes get[a-z]*_r strong instead of weak, and a linker bug fix, the strong versions of get[a-z]*_r in libc.so are used. Here is a patch to use nscd's own get[a-z]*_r functions. -- H.J. Lu (hjl@gnu.org) --- Sun Jul 11 17:36:43 1999 H.J. Lu * nscd/grpcache.c: Add prefix "__" to get[a-z]*_r () to get nscd's own strong version of the get[a-z]*_r function. * nscd/hstcache.c: Likwise. * nscd/pwdcache.c: Likwise. Index: nscd/grpcache.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/nscd/grpcache.c,v retrieving revision 1.1.1.9 diff -u -p -r1.1.1.9 grpcache.c --- nscd/grpcache.c 1999/06/27 01:14:33 1.1.1.9 +++ nscd/grpcache.c 1999/07/12 00:29:58 @@ -208,7 +208,7 @@ addgrbyname (struct database *db, int fd if (debug_level > 0) dbg_log (_("Haven't found \"%s\" in group cache!"), key); - while (getgrnam_r (key, &resultbuf, buffer, buflen, &grp) != 0 + while (__getgrnam_r (key, &resultbuf, buffer, buflen, &grp) != 0 && errno == ERANGE) { errno = 0; @@ -236,7 +236,7 @@ addgrbygid (struct database *db, int fd, if (debug_level > 0) dbg_log (_("Haven't found \"%d\" in group cache!"), gid); - while (getgrgid_r (gid, &resultbuf, buffer, buflen, &grp) != 0 + while (__getgrgid_r (gid, &resultbuf, buffer, buflen, &grp) != 0 && errno == ERANGE) { errno = 0; Index: nscd/hstcache.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/nscd/hstcache.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 hstcache.c --- nscd/hstcache.c 1999/06/27 01:14:33 1.1.1.3 +++ nscd/hstcache.c 1999/07/12 00:30:53 @@ -329,8 +329,8 @@ addhstbyaddr (struct database *db, int f inet_ntop (AF_INET, key, buf, sizeof (buf))); } - while (gethostbyaddr_r (key, INADDRSZ, AF_INET, &resultbuf, buffer, buflen, - &hst, &h_errno) != 0 + while (__gethostbyaddr_r (key, INADDRSZ, AF_INET, &resultbuf, buffer, buflen, + &hst, &h_errno) != 0 && h_errno == NETDB_INTERNAL && errno == ERANGE) { @@ -396,8 +396,8 @@ addhstbyaddrv6 (struct database *db, int inet_ntop (AF_INET6, key, buf, sizeof (buf))); } - while (gethostbyaddr_r (key, IN6ADDRSZ, AF_INET6, &resultbuf, buffer, buflen, - &hst, &h_errno) != 0 + while (__gethostbyaddr_r (key, IN6ADDRSZ, AF_INET6, &resultbuf, buffer, buflen, + &hst, &h_errno) != 0 && h_errno == NETDB_INTERNAL && errno == ERANGE) { Index: nscd/pwdcache.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/nscd/pwdcache.c,v retrieving revision 1.1.1.6 diff -u -p -r1.1.1.6 pwdcache.c --- nscd/pwdcache.c 1999/06/27 01:14:33 1.1.1.6 +++ nscd/pwdcache.c 1999/07/12 00:31:29 @@ -206,7 +206,7 @@ addpwbyname (struct database *db, int fd if (debug_level > 0) dbg_log (_("Haven't found \"%s\" in password cache!"), key); - while (getpwnam_r (key, &resultbuf, buffer, buflen, &pwd) != 0 + while (__getpwnam_r (key, &resultbuf, buffer, buflen, &pwd) != 0 && errno == ERANGE) { errno = 0; @@ -234,7 +234,7 @@ addpwbyuid (struct database *db, int fd, if (debug_level > 0) dbg_log (_("Haven't found \"%d\" in password cache!"), uid); - while (getpwuid_r (uid, &resultbuf, buffer, buflen, &pwd) != 0 + while (__getpwuid_r (uid, &resultbuf, buffer, buflen, &pwd) != 0 && errno == ERANGE) { errno = 0; From hjl@varesearch.com Mon Jul 12 09:19:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Mon, 12 Jul 1999 09:19:00 -0000 Subject: A patch for nscd References: <199907120103.LAA00548@geoffk.wattle.id.au> Message-ID: <19990712161927.63B1D3FC1@varesearch.com> > > > nscd has its own get[a-z]*_r functions. But nscd uses the weak names > > to call those functions. As the result of my get[a-z]*_r version > > change, which makes get[a-z]*_r strong instead of weak, and a linker > > bug fix, the strong versions of get[a-z]*_r in libc.so are used. Here > > is a patch to use nscd's own get[a-z]*_r functions. > > Why is 'get[a-z]*_r' strong? Won't this affect static ISO C programs > that define their own? get.*_r is a weak aliase of __get[a-z]*_r. However, get.*_r is strong in libc.so with my get.*_r version patch. The latest linker will pick the strong version over the weak one even if the strong one is in shared library and the weak one is in .o file. Here is the updated patch. It seems to work for me now. -- H.J. Lu (hjl@gnu.org) --- Sun Jul 11 17:36:43 1999 H.J. Lu * nscd/grpcache.c: Add prefix "__" to get[a-z]*_r () to get nscd's own strong version of the get[a-z]*_r function. * nscd/hstcache.c: Likwise. * nscd/pwdcache.c: Likwise. Index: nscd/grpcache.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/nscd/grpcache.c,v retrieving revision 1.1.1.9 diff -u -p -r1.1.1.9 grpcache.c --- nscd/grpcache.c 1999/06/27 01:14:33 1.1.1.9 +++ nscd/grpcache.c 1999/07/12 00:29:58 @@ -208,7 +208,7 @@ addgrbyname (struct database *db, int fd if (debug_level > 0) dbg_log (_("Haven't found \"%s\" in group cache!"), key); - while (getgrnam_r (key, &resultbuf, buffer, buflen, &grp) != 0 + while (__getgrnam_r (key, &resultbuf, buffer, buflen, &grp) != 0 && errno == ERANGE) { errno = 0; @@ -236,7 +236,7 @@ addgrbygid (struct database *db, int fd, if (debug_level > 0) dbg_log (_("Haven't found \"%d\" in group cache!"), gid); - while (getgrgid_r (gid, &resultbuf, buffer, buflen, &grp) != 0 + while (__getgrgid_r (gid, &resultbuf, buffer, buflen, &grp) != 0 && errno == ERANGE) { errno = 0; Index: nscd/hstcache.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/nscd/hstcache.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 hstcache.c --- nscd/hstcache.c 1999/06/27 01:14:33 1.1.1.3 +++ nscd/hstcache.c 1999/07/12 16:11:27 @@ -296,8 +296,8 @@ addhstbyname (struct database *db, int f if (debug_level > 0) dbg_log (_("Haven't found \"%s\" in hosts cache!"), key); - while (gethostbyname2_r (key, AF_INET, &resultbuf, buffer, buflen, &hst, - &h_errno) != 0 + while (__gethostbyname2_r (key, AF_INET, &resultbuf, buffer, buflen, + &hst, &h_errno) != 0 && h_errno == NETDB_INTERNAL && errno == ERANGE) { @@ -329,8 +329,8 @@ addhstbyaddr (struct database *db, int f inet_ntop (AF_INET, key, buf, sizeof (buf))); } - while (gethostbyaddr_r (key, INADDRSZ, AF_INET, &resultbuf, buffer, buflen, - &hst, &h_errno) != 0 + while (__gethostbyaddr_r (key, INADDRSZ, AF_INET, &resultbuf, buffer, + buflen, &hst, &h_errno) != 0 && h_errno == NETDB_INTERNAL && errno == ERANGE) { @@ -363,8 +363,8 @@ addhstbynamev6 (struct database *db, int inet_ntop (AF_INET6, key, buf, sizeof (buf))); } - while (gethostbyname2_r (key, AF_INET6, &resultbuf, buffer, buflen, &hst, - &h_errno) != 0 + while (__gethostbyname2_r (key, AF_INET6, &resultbuf, buffer, buflen, + &hst, &h_errno) != 0 && h_errno == NETDB_INTERNAL && errno == ERANGE) { @@ -396,8 +396,8 @@ addhstbyaddrv6 (struct database *db, int inet_ntop (AF_INET6, key, buf, sizeof (buf))); } - while (gethostbyaddr_r (key, IN6ADDRSZ, AF_INET6, &resultbuf, buffer, buflen, - &hst, &h_errno) != 0 + while (__gethostbyaddr_r (key, IN6ADDRSZ, AF_INET6, &resultbuf, + buffer, buflen, &hst, &h_errno) != 0 && h_errno == NETDB_INTERNAL && errno == ERANGE) { Index: nscd/pwdcache.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/nscd/pwdcache.c,v retrieving revision 1.1.1.6 diff -u -p -r1.1.1.6 pwdcache.c --- nscd/pwdcache.c 1999/06/27 01:14:33 1.1.1.6 +++ nscd/pwdcache.c 1999/07/12 00:31:29 @@ -206,7 +206,7 @@ addpwbyname (struct database *db, int fd if (debug_level > 0) dbg_log (_("Haven't found \"%s\" in password cache!"), key); - while (getpwnam_r (key, &resultbuf, buffer, buflen, &pwd) != 0 + while (__getpwnam_r (key, &resultbuf, buffer, buflen, &pwd) != 0 && errno == ERANGE) { errno = 0; @@ -234,7 +234,7 @@ addpwbyuid (struct database *db, int fd, if (debug_level > 0) dbg_log (_("Haven't found \"%d\" in password cache!"), uid); - while (getpwuid_r (uid, &resultbuf, buffer, buflen, &pwd) != 0 + while (__getpwuid_r (uid, &resultbuf, buffer, buflen, &pwd) != 0 && errno == ERANGE) { errno = 0; From hjl@varesearch.com Mon Jul 12 11:08:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Mon, 12 Jul 1999 11:08:00 -0000 Subject: A question on nscd Message-ID: <19990712180806.95CE43FC1@varesearch.com> Hi, In nscd.init, there is # description: This is a daemon which handles passwd and group lookups \ # for running programs and cache the results for the next \ # query. You should start this daemon only if you use \ # slow Services like NIS or NIS+ I was wondering why nscd was only needed for NIS/NIS+. As far as I can tell, it is also useful for DNS. Did I miss something? Thanks. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Mon Jul 12 11:29:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 12 Jul 1999 11:29:00 -0000 Subject: A question on nscd References: <19990712180806.95CE43FC1@varesearch.com> Message-ID: hjl@varesearch.com (H.J. Lu) writes: > I was wondering why nscd was only needed for NIS/NIS+. As far as I can > tell, it is also useful for DNS. Did I miss something? When using DNS you are probably better off using a caching bind. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Mon Jul 12 12:01:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 12 Jul 1999 12:01:00 -0000 Subject: A question on nscd References: <19990712180806.95CE43FC1@varesearch.com> Message-ID: >>>>> H J Lu writes: > Hi, > In nscd.init, there is > # description: This is a daemon which handles passwd and group lookups \ > # for running programs and cache the results for the next \ > # query. You should start this daemon only if you use \ > # slow Services like NIS or NIS+ > I was wondering why nscd was only needed for NIS/NIS+. As far as I can > tell, it is also useful for DNS. Did I miss something? The description predates AFAIK the addition of host lookup to nscd and should be updated. You can use nscd for caching DNS queries. Most nameserver setups include already a caching name server. Therefore you've got to decide who caches the DNS queries: named, nscd - or both. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From hjl@varesearch.com Mon Jul 12 12:07:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Mon, 12 Jul 1999 12:07:00 -0000 Subject: A question on nscd References: Message-ID: <19990712190630.BBCA43FC1@varesearch.com> > > >>>>> H J Lu writes: > > > Hi, > > In nscd.init, there is > > > # description: This is a daemon which handles passwd and group lookups \ > > # for running programs and cache the results for the next \ > > # query. You should start this daemon only if you use \ > > # slow Services like NIS or NIS+ > > > I was wondering why nscd was only needed for NIS/NIS+. As far as I can > > tell, it is also useful for DNS. Did I miss something? > > The description predates AFAIK the addition of host lookup to nscd and > should be updated. > > You can use nscd for caching DNS queries. Most nameserver setups > include already a caching name server. Therefore you've got to decide > who caches the DNS queries: named, nscd - or both. > The things I like in nscd are unix domain socket and multi-thread. -- H.J. Lu (hjl@gnu.org) From jlarmour@cygnus.co.uk Mon Jul 12 12:22:00 1999 From: jlarmour@cygnus.co.uk (Jonathan Larmour) Date: Mon, 12 Jul 1999 12:22:00 -0000 Subject: A question on nscd References: <19990712190630.BBCA43FC1@varesearch.com> Message-ID: <378A4048.E4FFC9BB@cygnus.co.uk> "H.J. Lu" wrote: > > >>>>> H J Lu writes: > > > > > I was wondering why nscd was only needed for NIS/NIS+. As far as I can > > > tell, it is also useful for DNS. Did I miss something? > > > > The description predates AFAIK the addition of host lookup to nscd and > > should be updated. > > > > You can use nscd for caching DNS queries. Most nameserver setups > > include already a caching name server. Therefore you've got to decide > > who caches the DNS queries: named, nscd - or both. > > The things I like in nscd are unix domain socket and multi-thread. As I understand it, nscd doesn't use the DNS TTL data, and so is inferior to a caching BIND. Therefore it is better to avoid it if you are using DNS. Jifl -- Cygnus Solutions, 35 Cambridge Place, Cambridge, UK. Tel: +44 (1223) 728762 "I used to have an open mind but || Get yer free open source RTOS's here... my brains kept falling out." || http://sourceware.cygnus.com/ecos Help fight spam! http://spam.abuse.net/ These opinions are all my own fault From hjl@varesearch.com Mon Jul 12 12:29:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Mon, 12 Jul 1999 12:29:00 -0000 Subject: A question on nscd References: <378A4048.E4FFC9BB@cygnus.co.uk> Message-ID: <19990712192921.7D1CF3FC1@varesearch.com> > > > > The things I like in nscd are unix domain socket and multi-thread. > > As I understand it, nscd doesn't use the DNS TTL data, and so is inferior to > a caching BIND. Therefore it is better to avoid it if you are using DNS. > If it becomes a problem, we have to take another look. The problem I am working on is mountd. The Linux mountd does many DNS calls for each mount/umount request. When it gets many mount/umount request, those DNS calls slow it down. Of course, we can put those clients in /etc/hosts. But I like to see if nscd will help. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Mon Jul 12 18:16:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 12 Jul 1999 18:16:00 -0000 Subject: A patch for nscd References: <19990712161927.63B1D3FC1@varesearch.com> Message-ID: I've applied the patch. Thanks, From hjl@varesearch.com Mon Jul 12 19:28:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Mon, 12 Jul 1999 19:28:00 -0000 Subject: More malloc and emacs problem Message-ID: <19990713021449.9085B3FC1@varesearch.com> Hi, I ran into a different emacs 20.3 and malloc problem. it coredumps when you run the X-enabled version in the text mode when DISPLAY is not set. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Tue Jul 13 12:23:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Tue, 13 Jul 1999 12:23:00 -0000 Subject: cvs works Message-ID: Hi, I hope to do some major CVS archive reorganizations tonight. Lots of files will be moved around and to keep the history, I will do this in the CVS repository itself. In this time there better should be no checkins and if possible also no checkouts. Since the machine is hosting also a number of other projects we cannot disable cvs entirely. I might start around 7pm PST and will send some mail after I'm done. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Wed Jul 14 01:03:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 14 Jul 1999 01:03:00 -0000 Subject: hopefully done Message-ID: Hi, The reorganizations should now be done. Thanks to Jakub, it was easier than the enormous amount of patches might suggest. Jakub provided me even shell scripts to do the cvs work. The only thing I did was adding a few copyright comments here and there and moving some files in different directories. This might haven broken something. I cannot tell since I have not yet compiled anything with the new tree. So be aware. If you want you can send patches. Otherwise wait until I start compiling which will be one of the first things I do once I get up tomorrow (today) morning. For updating you should use the options -dP for update since there are new subdirs as well as now empty subdirs. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@varesearch.com Wed Jul 14 17:03:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Wed, 14 Jul 1999 17:03:00 -0000 Subject: autoconf is broken on glibc Message-ID: <19990714192014.712183FC1@varesearch.com> Hi, The C++ code test in autoconf is broken on glibc since autoconf puts #ifdef __cplusplus extern "C" void exit(int); #endif at the beginning of each C++ test. When from glibc is included in the C++ test, we have extern "C" { ... extern void exit (int __status) throw () ; ... }; Now all glibc based systemas are screwed due to this. -- H.J. Lu (hjl@gnu.org) From hjl@varesearch.com Wed Jul 14 17:03:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Wed, 14 Jul 1999 17:03:00 -0000 Subject: Your g++ breaks glibc. Message-ID: <19990714195521.1BA043FC1@varesearch.com> Hi, Your change: 1998-12-07 Jason Merrill * decl.c (init_decl_processing): If neither -fpermissive or -pedantic were specified, set flag_pedantic_errors. breaks glibc. That is a code fragment generated by autoconf. With gcc 2.95, I got # gcc -S bar.cc In file included from bar.cc:5: /usr/include/stdlib.h:520: declaration of `exit(int)' throws different exceptions bar.cc:2: previous declaration here egcs 1.1.2 only gives a warning. It should be fixed in gcc 2.95. How does this patch sound? --- ../../import/gcc-2.95/egcs/gcc/cp/decl.c Fri Jul 9 08:32:50 1999 +++ gcc/cp/decl.c Wed Jul 14 12:51:56 1999 @@ -3516,7 +3516,8 @@ duplicate_decls (newdecl, olddecl) TREE_TYPE (olddecl) = build_exception_variant (newtype, TYPE_RAISES_EXCEPTIONS (oldtype)); - if ((pedantic || ! DECL_IN_SYSTEM_HEADER (olddecl)) + if ((pedantic || (! DECL_IN_SYSTEM_HEADER (olddecl) + && ! DECL_IN_SYSTEM_HEADER (newdecl))) && DECL_SOURCE_LINE (olddecl) != 0 && flag_exceptions && ! compexcepttypes (TREE_TYPE (newdecl), TREE_TYPE (olddecl))) Thanks. -- H.J. Lu (hjl@gnu.org) --- extern "C" { void exit (int); }; #include From hjl@varesearch.com Wed Jul 14 17:03:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Wed, 14 Jul 1999 17:03:00 -0000 Subject: A bad gcc 2.95 bug Message-ID: <19990714193206.B31013FC1@varesearch.com> Hi, With egcs 1.1.2, I got # gcc foo.cc foo.cc:4: warning: declaration of `exit(int)' throws different exceptions foo.cc:3: warning: previous declaration here But with gcc 2.95 19990711, now I got # gcc foo.cc foo.cc:4: declaration of `exit(int)' throws different exceptions foo.cc:3: previous declaration here That is a bug fixed for egcs 1.1.2. Why does it return in gcc 2.95? It will screw up glibc. It has to be fixed in gcc 2.95. -- H.J. Lu (hjl@gnu.org) ---foo.cc- extern "C" { void exit (int); void exit (int) __attribute__ ((__noreturn__)); void exit (int) throw () __attribute__ ((__noreturn__)); }; From drepper@cygnus.com Wed Jul 14 18:26:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 14 Jul 1999 18:26:00 -0000 Subject: 2.1.2pre1 outlook Message-ID: Hi, I will be in Montreal next week and would like to use this quiet phase to have people test 2.1.2. I hope to make 2.1.2pre1 before or on Sunday. So, if you kow about any missing patches in the 2.1 branch or any bugs which have to be fixed please let me know ASAP. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Wed Jul 14 22:58:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Wed, 14 Jul 1999 22:58:00 -0000 Subject: 2.1.2pre1 outlook References: Message-ID: >>>>> Ulrich Drepper writes: > Hi, > I will be in Montreal next week and would like to use this quiet phase > to have people test 2.1.2. I hope to make 2.1.2pre1 before or on > Sunday. > So, if you kow about any missing patches in the 2.1 branch or any bugs > which have to be fixed please let me know ASAP. Please add the following two patches. That should be all except perhaps some platform specific fixes. Andreas 1999-07-13 Jakub Jelinek * sysdeps/unix/sysv/linux/shmat.c (shmat): Avoid casting a pointer to int. 1999-07-13 Andreas Schwab * elf/dl-runtime.c (fixup, profile_fixup): Call alloca to prevent inlining. Fixes PR libc/1198. --- glibc-2-1-branch/elf/dl-runtime.c Sun Feb 21 07:13:50 1999 +++ libc/elf/dl-runtime.c Thu Jul 15 06:56:22 1999 @@ -57,6 +57,12 @@ void *const rel_addr = (void *)(l->l_addr + reloc->r_offset); ElfW(Addr) value; + /* The use of `alloca' here looks ridiculous but it helps. The goal is + to prevent the function from being inlined and thus optimized out. + There is no official way to do this so we use this trick. gcc never + inlines functions which use `alloca'. */ + alloca (sizeof (int)); + /* Sanity check that we're really looking at a PLT relocation. */ assert (ELFW(R_TYPE)(reloc->r_info) == ELF_MACHINE_JMP_SLOT); @@ -110,6 +116,12 @@ ElfW(Addr) *resultp; ElfW(Addr) value; + /* The use of `alloca' here looks ridiculous but it helps. The goal is + to prevent the function from being inlined, and thus optimized out. + There is no official way to do this so we use this trick. gcc never + inlines functions which use `alloca'. */ + alloca (sizeof (int)); + /* This is the address in the array where we store the result of previous relocations. */ resultp = &l->l_reloc_result[reloc_offset / sizeof (PLTREL)]; --- glibc-2-1-branch/sysdeps/unix/sysv/linux/shmat.c Wed Dec 16 06:57:28 1998 +++ libc/sysdeps/unix/sysv/linux/shmat.c Thu Jul 15 06:56:45 1999 @@ -1,4 +1,4 @@ -/* Copyright (C) 1995, 1997, 1998 Free Software Foundation, Inc. +/* Copyright (C) 1995, 1997, 1998, 1999 Free Software Foundation, Inc. This file is part of the GNU C Library. Contributed by Ulrich Drepper , August 1995. @@ -33,11 +33,11 @@ const void *shmaddr; int shmflg; { - int retval; + long int retval; unsigned long raddr; - retval = INLINE_SYSCALL (ipc, 5, IPCOP_shmat, shmid, shmflg, (int) &raddr, - (void *) shmaddr); + retval = INLINE_SYSCALL (ipc, 5, IPCOP_shmat, shmid, shmflg, + (long int) &raddr, (void *) shmaddr); return ((unsigned long int) retval > -(unsigned long int) SHMLBA ? (void *) retval : (void *) raddr); } -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From hjl@varesearch.com Wed Jul 14 23:04:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Wed, 14 Jul 1999 23:04:00 -0000 Subject: A bad gcc 2.95 bug References: Message-ID: <19990715060352.4039D3FC1@varesearch.com> > > On Jul 14, 1999, hjl@varesearch.com (H.J. Lu) wrote: > > > Why does it return in gcc 2.95? > > gcc 2.95 has become much stricter about C++ rules. You need > -fpermissive to get it less strict. > It is a real bug. I posted a patch: http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00534.html http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00537.html H.J. From hjl@varesearch.com Wed Jul 14 23:50:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Wed, 14 Jul 1999 23:50:00 -0000 Subject: Your g++ breaks glibc. References: <19990714233738F.mitchell@codesourcery.com> Message-ID: <19990715064951.AB8803FC1@varesearch.com> > > >>>>> "Jeffrey" == Jeffrey A Law writes: > > Jeffrey> I've got conflicting reports from Jason and Alexandre > Jeffrey> about this one. I need a definitive answer before I wake > Jeffrey> up in the morning or it will not be in gcc-2.95. > > Both Jason and Alexandre are right. > > The code is indeed buggy: > > [except.spec] > > If any declaration of a function has an exception-specification, all > declarations, including the definition and an explicit specialization, > of that function shall have an exception-specification with the same > set of type-ids. > > It couldn't be any clearer. > > If autoconf is generating the code fragment H.J. shows, then autoconf > is broken. > > However, the patch should still go on the branch. After all, autoconf > is in widespread use. There is no non-conformance issue here since we > will still warn if -pedantic. > > H.J., please follow up with whatever tool is producing this bogus > code, and get that tool fixed. In the next major version, we should > It is ncurses 4.2. However, I believe the problem is in autoconf and I don't even know if there is a reasonable fix for autoconf since it may not know which one, extern "C" void exit(int); extern "C" void exit(int) throw (); to use for a given system. gcc 2.95 works with #include extern "C" void exit(int); but not extern "C" void exit(int); #include I don't see any reason to allow one and not the other. H.J. From pb@nexus.co.uk Thu Jul 15 04:41:00 1999 From: pb@nexus.co.uk (Philip Blundell) Date: Thu, 15 Jul 1999 04:41:00 -0000 Subject: 2.1.2pre1 outlook References: Message-ID: >So, if you kow about any missing patches in the 2.1 branch or any bugs >which have to be fixed please let me know ASAP. I think we need a patch to make the dynamic linker work with the ELF OSABI value that the new ARM binutils uses. I'll send one shortly. p. From pb@nexus.co.uk Thu Jul 15 10:12:00 1999 From: pb@nexus.co.uk (Philip Blundell) Date: Thu, 15 Jul 1999 10:12:00 -0000 Subject: 2.1.2pre1 outlook Message-ID: >I think we need a patch to make the dynamic linker work with the ELF OSABI >value that the new ARM binutils uses. I'll send one shortly. Here's that patch. It's against the 2.1 branch; if it's OK we should also install something morally equivalent in the mainline. p. 1999-07-15 Philip Blundell * elf/dl-load.c (_dl_map_object_from_fd): Use ELF_ABI_RECOGNIZED to decide whether an object's ABI is acceptable. (ELF_ABI_RECOGNIZED): New macro; provide default definition. * sysdeps/arm/dl-machine.h (ELF_ABI_RECOGNIZED): Define. --- elf/dl-load.c 1999/06/17 10:41:12 1.103.2.1 +++ elf/dl-load.c 1999/07/15 17:05:16 @@ -58,6 +58,12 @@ #define MAP_BASE_ADDR(l) 0 #endif +/* By default we accept only ELFOSABI_SYSV and an ABI version of 0. But + some systems may wish to do this differently. */ +#ifndef ELF_ABI_RECOGNIZED +#define ELF_ABI_RECOGNIZED(_h) \ + ((_h)[EI_OSABI] == ELFOSABI_SYSV && (_h)[EI_ABIVERSION] == 0) +#endif #include #if BYTE_ORDER == BIG_ENDIAN @@ -663,9 +669,7 @@ [EI_MAG3] = ELFMAG3, [EI_CLASS] = ELFW(CLASS), [EI_DATA] = byteorder, - [EI_VERSION] = EV_CURRENT, - [EI_OSABI] = ELFOSABI_SYSV, - [EI_ABIVERSION] = 0 + [EI_VERSION] = EV_CURRENT }; struct link_map *l = NULL; @@ -721,7 +725,7 @@ header = (void *) readbuf; /* Check the header for basic validity. */ - if (memcmp (header->e_ident, expected, EI_PAD) != 0) + if (memcmp (header->e_ident, expected, EI_OSABI) != 0) { /* Something is wrong. */ if (*(Elf32_Word *) &header->e_ident != @@ -746,10 +750,6 @@ LOSE (0, "ELF file version ident not " STRING(EV_CURRENT)); /* XXX We should be able so set system specific versions which are allowed here. */ - if (header->e_ident[EI_OSABI] != ELFOSABI_SYSV) - LOSE (0, "ELF file OS ABI not " STRING(ELFOSABI_SYSV)); - if (header->e_ident[EI_ABIVERSION] != 0) - LOSE (0, "ELF file ABI version not 0"); LOSE (0, "internal error"); } @@ -759,6 +759,8 @@ LOSE (0, "ELF file machine architecture not " ELF_MACHINE_NAME); if (header->e_phentsize != sizeof (ElfW(Phdr))) LOSE (0, "ELF file's phentsize not the expected size"); + if (! ELF_ABI_RECOGNIZED (header->e_ident)) + LOSE (0, "ELF file ABI not recognized"); #ifndef MAP_ANON # define MAP_ANON 0 --- sysdeps/arm/dl-machine.h 1999/06/13 09:23:47 1.12.2.1 +++ sysdeps/arm/dl-machine.h 1999/07/15 17:05:41 @@ -454,3 +454,8 @@ } #endif /* RESOLVE */ + +/* We have unusual requirements for ABI acceptance. */ +#define ELF_ABI_RECOGNIZED(_h) \ + (((_h)[EI_OSABI] == ELFOSABI_SYSV && (_h)[EI_ABIVERSION] == 0) \ + || ((_h)[EI_OSABI] == ELFOSABI_ARM && (_h)[EI_ABIVERSION] == 0)) From drepper@cygnus.com Thu Jul 15 11:13:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 15 Jul 1999 11:13:00 -0000 Subject: 2.1.2pre1 outlook References: Message-ID: Philip Blundell writes: > Here's that patch. It's against the 2.1 branch; if it's OK we should also > install something morally equivalent in the mainline. I don't like the patch in this way since it punishes other platforms as well. I'll see how I can rewrite it. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Thu Jul 15 11:41:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 15 Jul 1999 11:41:00 -0000 Subject: 2.1.2pre1 outlook References: Message-ID: Andreas Jaeger writes: > 1999-07-13 Jakub Jelinek > > * sysdeps/unix/sysv/linux/shmat.c (shmat): Avoid casting a pointer > to int. This one is not necesary since it only effects SPARC64 which does not work correctly with glibc 2.1 anyway. > 1999-07-13 Andreas Schwab > > * elf/dl-runtime.c (fixup, profile_fixup): Call alloca to prevent > inlining. Fixes PR libc/1198. This one I've added. Thanks, -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Thu Jul 15 14:05:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Thu, 15 Jul 1999 14:05:00 -0000 Subject: 2.1.2pre1 outlook References: Message-ID: >>>>> Ulrich Drepper writes: Ulrich> Andreas Jaeger writes: >> 1999-07-13 Jakub Jelinek >> >> * sysdeps/unix/sysv/linux/shmat.c (shmat): Avoid casting a pointer >> to int. Ulrich> This one is not necesary since it only effects SPARC64 which does not Ulrich> work correctly with glibc 2.1 anyway. Does it only affect sparc64? I thought it would affect every 64 bit platform including alpha. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Thu Jul 15 16:14:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 15 Jul 1999 16:14:00 -0000 Subject: 2.1.2pre1 outlook References: Message-ID: Andreas Jaeger writes: > Does it only affect sparc64? I thought it would affect every 64 bit > platform including alpha. There is only one other supported one (Alpha) and they don't use this code. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Thu Jul 15 22:54:00 1999 From: roland@frob.com (Roland McGrath) Date: Thu, 15 Jul 1999 22:54:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); Message-ID: <199907160554.BAA20280@frob.com> A friend is hitting the `assert (! "unexpected dynamic reloc type");' with some glibc and some weird shared objects on some platform (arm), and he suggested that the message would be more helpful if it mentioned the offending type code, or the name of the offending shared object, or both. Since the total set of reloc types on some of the newer platforms does seem to be a bit of a moving target, it seems like a good plan to expect this to be hit once in a while and make it a bit easier to figure out what's going on when it does. Any objections to changing this to use _dl_signal_error with a suitably composed message? From gafton@redhat.com Fri Jul 16 01:34:00 1999 From: gafton@redhat.com (Cristian Gafton) Date: Fri, 16 Jul 1999 01:34:00 -0000 Subject: dlopen problems Message-ID: I am having a hard time getting some perl modules to work because it seems that the dependency resolutions in the dynamic linker are not doing the right thing. Basically you have two libraries (lib1.so and lib2.so) that are both exporting the same symbol foo(). Then you have a program (main) that is linked dynamically against the first library, lib1. You have another library (module.so) linked against lib2 that acts like a loadable module. The programs does a dlopen on the module and calls a function() in the module. That function from the module depends on the foo() function from the library it is linked against (lib2). But instead of calling the lib2.so:foo() we end up calling the lib1:foo() from the module, because that is already resolved and ready to use. I have attached a small test case that shows up this broken behavior. What is bad is that no matter what I do I can not manage to get module.so to call the right foo() function - linking in statically lib2 into module.so does not help. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. From pb@nexus.co.uk Fri Jul 16 02:01:00 1999 From: pb@nexus.co.uk (Philip Blundell) Date: Fri, 16 Jul 1999 02:01:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); References: <199907160554.BAA20280@frob.com> Message-ID: >Any objections to changing this to use _dl_signal_error with >a suitably composed message? That sounds like a good idea to me. In the particular case of the problem your friend is having, chances are he has some shared object that was built without -fPIC, or with a buggy version of GCC that didn't do PIC quite right. This causes R_ARM_PC24 relocs to leak into shared objects where they can't be handled. I have considered on a couple of occasions adding an explicit error message to explain what's wrong, but never got around to it. p. From drepper@cygnus.com Fri Jul 16 07:53:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 16 Jul 1999 07:53:00 -0000 Subject: dlopen problems References: Message-ID: Cristian Gafton writes: > That function from the module depends on the foo() function from > the library it is linked against (lib2). But instead of calling the > lib2.so:foo() we end up calling the lib1:foo() from the module, because > that is already resolved and ready to use. That's exactly the right behaviour. If you want to prefer local resolution you have to set DT_SYMBOLIC. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gafton@redhat.com Fri Jul 16 10:26:00 1999 From: gafton@redhat.com (Cristian Gafton) Date: Fri, 16 Jul 1999 10:26:00 -0000 Subject: dlopen problems References: Message-ID: On 16 Jul 1999, Ulrich Drepper wrote: > > That function from the module depends on the foo() function from > > the library it is linked against (lib2). But instead of calling the > > lib2.so:foo() we end up calling the lib1:foo() from the module, because > > that is already resolved and ready to use. > > That's exactly the right behaviour. If you want to prefer local > resolution you have to set DT_SYMBOLIC. That doesn't work either. I have enable DT_SYMBOLIC for module.so and the same broken behavior exists. Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. From drepper@cygnus.com Fri Jul 16 16:20:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 16 Jul 1999 16:20:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); References: <199907160554.BAA20280@frob.com> Message-ID: Roland McGrath writes: > Any objections to changing this to use _dl_signal_error with > a suitably composed message? Well, maybe we should make it optional. The many strings will increment the code size and for platforms like x86 and m68k it won't be necessary since if there is an unknown tag it is an error in the binary. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Fri Jul 16 16:33:00 1999 From: roland@frob.com (Roland McGrath) Date: Fri, 16 Jul 1999 16:33:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); References: Message-ID: <199907162333.TAA04123@frob.com> > Well, maybe we should make it optional. The many strings will > increment the code size and for platforms like x86 and m68k it won't > be necessary since if there is an unknown tag it is an error in the > binary. That is exactly the point. You want to know which binary, as well as which type to look for. The string constants will probably be shorter than the existing one that the assert macro creates. Reloc types are one byte and hex is fine to output them, so the code to format the value will be tiny. From drepper@cygnus.com Fri Jul 16 16:41:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 16 Jul 1999 16:41:00 -0000 Subject: dlopen problems References: Message-ID: Cristian Gafton writes: > That doesn't work either. I have enable DT_SYMBOLIC for module.so and the > same broken behavior exists. I misunderstood the situation. The function you want to call is not in the object itself but instead in the dependency. The ld.so handles this correctly. There is no bug. This is the documented behaviour in the ELF specification. Several months ago we corrected the behaviour of ld.so to follow this rule. Before that your test program would have succeeded. But this is really wrong. What we want to do at some point is to define a new flag with the semantics you want. But for now there is no possbility except using dlopen(). -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Fri Jul 16 16:47:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 16 Jul 1999 16:47:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); References: <199907162333.TAA04123@frob.com> Message-ID: Roland McGrath writes: > That is exactly the point. You want to know which binary, as well as which > type to look for. I'm nto convinced that it is as short and simply. If it is, I've no problems. But otherwise you are hurting 99.9% of all programs in one of the inner loops. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Fri Jul 16 16:49:00 1999 From: roland@frob.com (Roland McGrath) Date: Fri, 16 Jul 1999 16:49:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); References: Message-ID: <199907162349.TAA04368@frob.com> > Roland McGrath writes: > > > That is exactly the point. You want to know which binary, as well as which > > type to look for. > > I'm nto convinced that it is as short and simply. If it is, I've no > problems. But otherwise you are hurting 99.9% of all programs in one > of the inner loops. Say what?? This is code that is never even reached unless there is a fatal problem. From drepper@cygnus.com Fri Jul 16 16:52:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 16 Jul 1999 16:52:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); References: <199907162349.TAA04368@frob.com> Message-ID: Roland McGrath writes: > Say what?? This is code that is never even reached unless there is a fatal > problem. You have to look how gcc generates code. Since gcc so far does not use block reordering, code for ifs are generated like this: cmp jump if not to label code for if label: Therefore a larger `if code' is polluting the icache significantly. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Fri Jul 16 16:58:00 1999 From: roland@frob.com (Roland McGrath) Date: Fri, 16 Jul 1999 16:58:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); References: Message-ID: <199907162358.TAA04521@frob.com> > Roland McGrath writes: > > > Say what?? This is code that is never even reached unless there is a fatal > > problem. > > You have to look how gcc generates code. Since gcc so far does not use > block reordering, code for ifs are generated like this: > > cmp > jump if not to label > > code for if > > label: > > Therefore a larger `if code' is polluting the icache significantly. I see. Well, I was already planning to use a call to a separate function to do the message formatting and panic, just to consolidate the code for all platforms. The current code calls __assert_fail, with four arguments. The bad-reloc-type panic function will need only two args (link_map and reloc), so the code will be smaller. From drepper@cygnus.com Fri Jul 16 17:02:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 16 Jul 1999 17:02:00 -0000 Subject: assert (! "unexpected dynamic reloc type"); References: <199907162358.TAA04521@frob.com> Message-ID: Roland McGrath writes: > I see. Well, I was already planning to use a call to a separate > function to do the message formatting and panic, just to consolidate > the code for all platforms. The current code calls __assert_fail, > with four arguments. The bad-reloc-type panic function will need > only two args (link_map and reloc), so the code will be smaller. If you clean things up this is fine. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From gafton@redhat.com Fri Jul 16 21:38:00 1999 From: gafton@redhat.com (Cristian Gafton) Date: Fri, 16 Jul 1999 21:38:00 -0000 Subject: dlopen problems References: Message-ID: On 16 Jul 1999, Ulrich Drepper wrote: > I misunderstood the situation. The function you want to call is not > in the object itself but instead in the dependency. > > The ld.so handles this correctly. There is no bug. This is the > documented behaviour in the ELF specification. > > Several months ago we corrected the behaviour of ld.so to follow this > rule. Before that your test program would have succeeded. But this > is really wrong. Well, the problem exists in real life - perl is linked against db2, which provides a dbopen(). It was possible before for perl to load a module that was written for reading databases created with db1 and linked against db1.85. Now the wrong dbopen will be choosen and there is really no way around that - nothing that can be done in the perl module to prevent the runtime linker from binding the wrong dbopen reference. Bsically we are ignoring dependencies the modules require by linking against the right db library. > What we want to do at some point is to define a new flag with the > semantics you want. But for now there is no possbility except using > dlopen(). I am willing to put in the work, so how should this be working? Cristian -- ---------------------------------------------------------------------- Cristian Gafton -- gafton@redhat.com -- Red Hat, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ UNIX is user friendly. It's just selective about who its friends are. From drepper@cygnus.com Sat Jul 17 12:15:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 17 Jul 1999 12:15:00 -0000 Subject: dlopen problems References: Message-ID: Cristian Gafton writes: > Bsically we are ignoring dependencies the modules require by linking > against the right db library. Nothing like this can be described by ELF in the moment. > I am willing to put in the work, so how should this be working? Well, then first change the BFD ELF backend. It must emit the information based on a flag ld gets. The rest is then glibc work. The only reason I haven't implemeted it so far is that I tried to avoid the BFD work. If you do it (and get the patch approved by rth) then I'll add the glibc stuff quickly. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sat Jul 17 23:52:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 17 Jul 1999 23:52:00 -0000 Subject: gcc 2.95 and Linux/alpha References: <29704.932278573@upchuck.cygnus.com> Message-ID: <19990718065158.EF12257BA@ocean.lucon.org> > > In message <19990718060756.86FC357BA@ocean.lucon.org>you write: > > What should I search? I looked at the bug mailing list archive. > > I didn't see any. > I don't remember offhand. I think it was in the main list though, not the > bugs list. The discussion started because someone asked if we should > bump up the version # for libstdc++ at which point someone pointed out a > problem linking recent g++ code with libstdc++ from our last release. > Wait, on Linux/alpha, gcc 2.95 made DWARF2 based EH as default. That means C++ ABI on linux/alpha is changed. But there are also problems with glibc since those changes may have to be in sync. It is a very tricky problem. I believe it only affects linux/alpha. Please talk to linux/alpha people about gcc 2.95. We can even just bump the c++ INTERFACE only for linux/alpha. But there still is a glibc problem since glibc compiled with egcs 1.1.2 is different from the one compiled with gcc 2.95. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Sun Jul 18 19:23:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 18 Jul 1999 19:23:00 -0000 Subject: glibc 2.1.2pre1 Message-ID: <199907190223.TAA16854@happy.cygnus.com> I managed to upload the 2.1.2pre1 tarballs to egcs and kernel.org. Maybe somebody can upload them to alpha (or Roland's script does this automatically, I don't know). Anyhow, somebody might want to take a look at the kernel.org directory. Since I uploaded the file first as glibc-2.1.2 the sign and bz2 automation over there produced new files with this name. Perhaps somebody can mail the adminstrator. OK, that's it for now, gotta run. From aj@arthur.rhein-neckar.de Sun Jul 18 23:28:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Sun, 18 Jul 1999 23:28:00 -0000 Subject: glibc 2.1.2pre1 References: <199907190223.TAA16854@happy.cygnus.com> Message-ID: >>>>> Ulrich Drepper writes: > I managed to upload the 2.1.2pre1 tarballs to egcs and kernel.org. Maybe > somebody can upload them to alpha (or Roland's script does this automatically, > I don't know). > Anyhow, somebody might want to take a look at the kernel.org > directory. Since I uploaded the file first as glibc-2.1.2 the sign > and bz2 automation over there produced new files with this name. > Perhaps somebody can mail the adminstrator. I've contacted hpa and hope he'll look into it. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From hjl@lucon.org Mon Jul 19 13:51:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Mon, 19 Jul 1999 13:51:00 -0000 Subject: binutils 2.9.5.0.3 is released. Message-ID: <19990719205057.8CB2057BA@ocean.lucon.org> This should fix the libc 5 problem. -- H.J. Lu (hjl@gnu.org) -- This is the beta release of binutils 2.9.5.0.3 for Linux, which is based on binutils 1999 0719 plus various changes. It is purely for Linux, although it has been tested on Solaris/Sparc and Solaris/x86 from time to time. I merged a MIPS gas patch from binutils 2.9.1.0.25 to the current binutils and there are many changes in MIPS/ELF in bfd. I'd like to hear reports on Linux/MIPS. Please report any bugs related to binutils 2.9.5.0.3 to hjl@lucon.org. For arm-linux targets, there are some important differences in behaviour between these tools and binutils 2.9.1.0.x. The linker emulation name has changed from elf32arm{26} to armelf_linux{26}. Also, the "-p" flag must be passed with the linker when working with object files (or static libraries) created using older versions of the assembler. If this flag is omitted the linker will silently generate bad output when given old input files. To get the correct behaviour from gcc, amend the *link section of your specs file as follows: *link: %{h*} %{version:-v} %{b} %{Wl,*:%*} %{static:-Bstatic} %{shared:-shared } %{symbolic:-Bsymbolic} %{rdynamic:-export-dynamic} %{!dynamic-linker: -dynamic-linker /lib/ld-linux.so.2} -X %{mbig-endian:-EB} %{mapcs-26:-m ar melf_linux26} %{!mapcs-26:-m armelf_linux} -p Changes from binutils 2.9.4.0.8: 1. Update from binutils 1999 0719. A libc 5 related bug fix. 2. Fix a typo in mips gas. Changes from binutils 2.9.4.0.7: 1. Update from binutils 1999 0710. A weak symbol bug http://egcs.cygnus.com/ml/egcs-bugs/1999-07/msg00129.html is fixed. Changes from binutils 2.9.4.0.6: 1. Update from binutils 1999 0626. Changes from binutils 2.9.4.0.5: 1. Update from binutils 1999 0620. 2. Remove my fwait fix and use the one in cvs. 3. Use "--only-section=section" instead of "--extract-section=section". for objcopy. Changes from binutils 2.9.4.0.4: 1. Update from binutils 1999 0612. 2. Remove various temporary fixes of mine since those bugs are fixed now. Changes from binutils 2.9.4.0.3: 1. Update from binutils 1999 0611. 2. Remove my ELF/Alpha bfd changes. 3. Use the local symbol copy fix in binutils 1999 0611. Changes from binutils 2.9.4.0.2: 1. Update from binutils 1999 0607. 2. Remove my Sparc hacks. 3. Fix local symbol copy. Changes from binutils 2.9.4.0.1: 1. Update from binutils 1999 0606. 2. Restore relocation overflow checking in binutils 2.9.1.0.25 so that Linux kernel can build. 3. Fix i370 for the new gas. Changes from binutils 1999 0605: 1. Fix a -Bsymbolic bug for Linux/alpha. 2. Add ELF/i370. 3. Fix 8/16-bit relocations for i386. 4. Add --redefine-sym=old_form=new_form to objcopy. 5. Add "-j section" for objcopy. 6. Fix i386 disassembler for fwait. 7. Fix a Sparc asm bug. 8. Add Ada demangle support. 9. Fix MIPS/ELF bugs. 10. Add some vxworks suppport. 11. Fix a.out assembler. The file list: 1. binutils-2.9.5.0.3.tar.gz. Source code. 2. binutils-2.9.4.0.8-2.9.5.0.3.diff.gz. Patch against the previous beta source code. 3. binutils-2.9.5.0.3-1.src.rpm. Source RPM. 4. binutils-2.9.5.0.3-1.i386.rpm. Binary RPM for RedHat 6.0. There are also bzip2 versions of tar and diff files. The primary ftp sites for the beta Linux binutils are: 1. ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta Thanks. H.J. Lu hjl@lucon.org 07/19/99 From drepper@cygnus.com Mon Jul 19 14:41:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 19 Jul 1999 14:41:00 -0000 Subject: glibc 2.1.2pre1 References: <199907190223.TAA16854@happy.cygnus.com> Message-ID: Andreas Jaeger writes: > I've contacted hpa and hope he'll look into it. In theorie a good idea, but he should also be here in Montreal. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Mon Jul 19 23:14:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 19 Jul 1999 23:14:00 -0000 Subject: glibc 2.1.2pre1 References: <199907190223.TAA16854@happy.cygnus.com> Message-ID: >>>>> Ulrich Drepper writes: > Andreas Jaeger writes: >> I've contacted hpa and hope he'll look into it. > In theorie a good idea, but he should also be here in Montreal. I didn't get an answer. I checked one ftp mirror and the file has disappeared. So everything should be fine now. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From jk@espy.org Tue Jul 20 09:19:00 1999 From: jk@espy.org (Joel Klecker) Date: Tue, 20 Jul 1999 09:19:00 -0000 Subject: Silly little patch: Update for timezone/README Message-ID: According to ChangeLog, the timezone directory was updated from tzdata1999d several months ago, but the README does not reflect this. Index: timezone/README =================================================================== RCS file: /glibc/cvsfiles/libc/timezone/README,v retrieving revision 1.5 diff -u -r1.5 README --- timezone/README 1999/03/29 00:18:54 1.5 +++ timezone/README 1999/07/18 15:43:31 @@ -8,7 +8,7 @@ northamerica southamerica pacificnew etcetera factory backward systemv solar87 solar88 solar89 iso3166.tab zone.tab leapseconds yearistype -come from the tzdata1999c package by Arthur David Olson et.al. +come from the tzdata1999d package by Arthur David Olson et.al. These packages may be found at ftp://elsie.nci.nih.gov/pub/ . Commentary should be addressed to tz@elsie.nci.nih.gov. -- Joel Klecker (aka Espy) Debian GNU/Linux Developer From kettenis@wins.uva.nl Wed Jul 21 03:10:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Wed, 21 Jul 1999 03:10:00 -0000 Subject: DB 2.7.x is not binary compatible with DB 2.4.x Message-ID: <199907211010.MAA21097@landau.wins.uva.nl> I've verified that DB 2.7.5 (the version on the main branch) is not binary compatible with DB 2.4.14 (the version included with 2.1.x). Sendmail cannot create the aliases database (/etc/aliases.db) anymore. If you compare db.h between those versions (using the CVS web browser on sourceware) you'll see that a lot of flags have been renumbered. In particular the DB_TRUNCATE flag, which is causing my sendmail troubles. This means that we should either bump the libdb soname, or use versioning to create functions that map the old flags onto the new ones. I think the latter involves quite some work, and is not guaranteed to result in total binary compatibility. So personally, I'm in favour of bumping the soname. Mark From drepper@cygnus.com Wed Jul 21 05:50:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 21 Jul 1999 05:50:00 -0000 Subject: DB 2.7.x is not binary compatible with DB 2.4.x References: <199907211010.MAA21097@landau.wins.uva.nl> Message-ID: Mark Kettenis writes: > This means that we should either bump the libdb soname, or use > versioning to create functions that map the old flags onto the new > ones. None of this. First, you are really stupid installing this libc version. The warning in configure isn't there for fun. It's not only about the locale suff, other changes (including the db stuff) is included. Second, db/db2 will be removed from glibc soon. Then you can do whatever you want. I for myself will probably stay with 2.4. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Wed Jul 21 07:27:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Wed, 21 Jul 1999 07:27:00 -0000 Subject: [Gurusamy Sarathy ] ferror() after fread() on a FILE* opened for write References: Message-ID: <19990721142711.8AE8957BA@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > |> How about this patch? > > I have already checked this in for libc-2.2. It doesn't change anything > for fread anyway, only fgetc. > What do you mean by that? Have you tried my patch with your program? -- H.J. Lu (hjl@gnu.org) From schwab@suse.de Wed Jul 21 07:33:00 1999 From: schwab@suse.de (Andreas Schwab) Date: Wed, 21 Jul 1999 07:33:00 -0000 Subject: [Gurusamy Sarathy ] ferror() after fread() on a FILE* opened for write References: <19990721142711.8AE8957BA@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: |> > |> > hjl@lucon.org (H.J. Lu) writes: |> > |> > |> How about this patch? |> > |> > I have already checked this in for libc-2.2. It doesn't change anything |> > for fread anyway, only fgetc. |> > |> |> What do you mean by that? Have you tried my patch with your program? What do you mean with "your program"? -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From kettenis@wins.uva.nl Wed Jul 21 08:08:00 1999 From: kettenis@wins.uva.nl (Mark Kettenis) Date: Wed, 21 Jul 1999 08:08:00 -0000 Subject: DB 2.7.x is not binary compatible with DB 2.4.x References: <199907211010.MAA21097@landau.wins.uva.nl> Message-ID: <199907211508.RAA22132@landau.wins.uva.nl> From: Ulrich Drepper Date: 21 Jul 1999 05:31:23 -0700 Mark Kettenis writes: > This means that we should either bump the libdb soname, or use > versioning to create functions that map the old flags onto the new > ones. None of this. First, you are really stupid installing this libc version. The warning in configure isn't there for fun. It's not only about the locale suff, other changes (including the db stuff) is included. Sorry, but I want to make sure that the development version keeps working on the Hurd. If I don't do this regularly it becomes very hard to track down problems when things break. The easiest way to make sure that the core servers keep working is actually installing libc. Of course this isn't a "production" system and of course I have made a backup first. Please understand that I'm not whining that things are broken. I just wanted to make sure that you're aware of the problems with DB. Second, db/db2 will be removed from glibc soon. Then you can do whatever you want. I for myself will probably stay with 2.4. Just curious, but what's the reason for dropping db/db2? Mark From hjl@lucon.org Wed Jul 21 08:08:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Wed, 21 Jul 1999 08:08:00 -0000 Subject: [Gurusamy Sarathy ] ferror() after fread() on a FILE* opened for write References: Message-ID: <19990721150806.B4B9D57BA@ocean.lucon.org> This patch should pass the test. The problem is _IO_file_xsgetn and _IO_XXX_file_xsputn may call read/write directly. -- H.J. Lu (hjl@gnu.org) ---- Wed Jul 21 08:03:47 1999 H.J. Lu * libio/fileops.c (_IO_new_file_underflow): Set the error flag if fp is not opened for read. * libio/oldfileops.c (_IO_old_file_underflow): Likewise. * libio/fileops.c (_IO_new_file_xsputn): Set the error flag and return 0 if f is not opened for write. * libio/oldfileops.c (_IO_old_file_xsputn): Likewise. * libio/fileops.c (_IO_file_xsgetn): Set the error flag and return 0 if f is not opened for read. Index: libio/fileops.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/libio/fileops.c,v retrieving revision 1.10 diff -u -p -r1.10 fileops.c --- libio/fileops.c 1999/05/01 22:41:30 1.10 +++ libio/fileops.c 1999/07/21 14:58:22 @@ -349,6 +349,7 @@ _IO_new_file_underflow (fp) if (fp->_flags & _IO_NO_READS) { __set_errno (EBADF); + fp->_flags |= _IO_ERR_SEEN; return EOF; } if (fp->_IO_read_ptr < fp->_IO_read_end) @@ -745,6 +746,13 @@ _IO_new_file_xsputn (f, data, n) int must_flush = 0; _IO_size_t count; + if (f->_flags & _IO_NO_WRITES) + { + __set_errno (EBADF); + f->_flags |= _IO_ERR_SEEN; + return 0; + } + if (n <= 0) return 0; /* This is an optimized implementation. @@ -833,6 +841,13 @@ _IO_file_xsgetn (fp, data, n) register _IO_size_t want, have; register _IO_ssize_t count; register char *s = data; + + if (fp->_flags & _IO_NO_READS) + { + __set_errno (EBADF); + fp->_flags |= _IO_ERR_SEEN; + return 0; + } want = n; Index: libio/oldfileops.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/libio/oldfileops.c,v retrieving revision 1.2 diff -u -p -r1.2 oldfileops.c --- libio/oldfileops.c 1999/05/01 22:41:30 1.2 +++ libio/oldfileops.c 1999/07/21 14:59:15 @@ -313,6 +313,7 @@ _IO_old_file_underflow (fp) if (fp->_flags & _IO_NO_READS) { __set_errno (EBADF); + fp->_flags |= _IO_ERR_SEEN; return EOF; } if (fp->_IO_read_ptr < fp->_IO_read_end) @@ -668,6 +669,13 @@ _IO_old_file_xsputn (f, data, n) int must_flush = 0; _IO_size_t count; + if (f->_flags & _IO_NO_WRITES) + { + __set_errno (EBADF); + f->_flags |= _IO_ERR_SEEN; + return 0; + } + if (n <= 0) return 0; /* This is an optimized implementation. From drepper@cygnus.com Wed Jul 21 08:59:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 21 Jul 1999 08:59:00 -0000 Subject: DB 2.7.x is not binary compatible with DB 2.4.x References: <199907211010.MAA21097@landau.wins.uva.nl> <199907211508.RAA22132@landau.wins.uva.nl> Message-ID: Mark Kettenis writes: > Just curious, but what's the reason for dropping db/db2? You have to ask after making a remark about the problems? I have no control over the sources and have to live with the consequences. And everybody comes whining to me about te problems they have with db. It's not necessary. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Wed Jul 21 09:00:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 21 Jul 1999 09:00:00 -0000 Subject: [Gurusamy Sarathy ] ferror() after fread() on a FILE* opened for write References: <19990721150806.B4B9D57BA@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > This patch should pass the test. The problem is _IO_file_xsgetn > and _IO_XXX_file_xsputn may call read/write directly. This is not necessary. Don't add it. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From aj@arthur.rhein-neckar.de Wed Jul 21 09:45:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Wed, 21 Jul 1999 09:45:00 -0000 Subject: [Gurusamy Sarathy ] ferror() after fread() on a FILE* opened for write References: <19990721150806.B4B9D57BA@ocean.lucon.org> Message-ID: >>>>> Ulrich Drepper writes: Uli> hjl@lucon.org (H.J. Lu) writes: >> This patch should pass the test. The problem is _IO_file_xsgetn >> and _IO_XXX_file_xsputn may call read/write directly. Uli> This is not necessary. Don't add it. Are you sure? Check the current Posix draft of the Austin Group for fread/fgetc and fwrite/fputc. They explicitly mention EBADF for: The filedescriptor underlying stream is not a valid file descriptor open for reading (writing with fwrite/fputc). But this is marked as a new addition. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From schwab@suse.de Wed Jul 21 09:53:00 1999 From: schwab@suse.de (Andreas Schwab) Date: Wed, 21 Jul 1999 09:53:00 -0000 Subject: [Gurusamy Sarathy ] ferror() after fread() on a FILE* opened for write References: <19990721150806.B4B9D57BA@ocean.lucon.org> Message-ID: Andreas Jaeger writes: |> >>>>> Ulrich Drepper writes: |> |> Uli> hjl@lucon.org (H.J. Lu) writes: |> >> This patch should pass the test. The problem is _IO_file_xsgetn |> >> and _IO_XXX_file_xsputn may call read/write directly. |> |> Uli> This is not necessary. Don't add it. |> |> Are you sure? Check the current Posix draft of the Austin Group for |> fread/fgetc and fwrite/fputc. They explicitly mention EBADF for: |> |> The filedescriptor underlying stream is not a valid file descriptor |> open for reading (writing with fwrite/fputc). If you use std{in,out,err} then the underlying fd _is_ valid for both read and write (until you change that with freopen). Andreas. -- Andreas Schwab "And now for something schwab@suse.de completely different." SuSE GmbH, Schanz????ckerstr. 10, D-90443 N????rnberg From drepper@cygnus.com Wed Jul 21 15:25:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 21 Jul 1999 15:25:00 -0000 Subject: [Gurusamy Sarathy ] ferror() after fread() on a FILE* opened for write References: <19990721150806.B4B9D57BA@ocean.lucon.org> Message-ID: Andreas Jaeger writes: > Are you sure? Check the current Posix draft of the Austin Group for > fread/fgetc and fwrite/fputc. They explicitly mention EBADF for: OK, it's nowadays referring to getc. (We are working through the XSH stuff only tomorrow so I haven't read it). In this light the changes should be added. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Thu Jul 22 09:35:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Thu, 22 Jul 1999 09:35:00 -0000 Subject: 3.3.4b References: Message-ID: <19990722163514.325AA57B9@ocean.lucon.org> > > XFree86 3.3.4b is available > > please check the following > > - PAM support (this is for people using Red Hat or SuSE 6.2) > - glibc-2.1.2 changes I was told that all getxxx_r functions, which return int, in the latest and final POSIX.1b would return 0 on success and errno on error. glibc 2.1.2 will follow the latest and final POSIX.1b. I believe this patch is safe for POSIX and none-POSIX implemenations. Thanks. H.J. ---- --- ../../../import/xfree86/beta/xc/include/Xos_r.h Thu Jul 22 09:24:50 1999 +++ xc/include/Xos_r.h Tue Jul 20 11:08:04 1999 @@ -282,14 +282,14 @@ typedef struct { # if defined(_POSIX_REENTRANT_FUNCTIONS) || !defined(SVR4) || defined(Lynx) # ifndef Lynx # define _XGetpwuid(u,p) \ -((getpwuid_r((u),&(p).pws,(p).pwbuf,sizeof((p).pwbuf)) == -1) ? NULL : &(p).pws) +((getpwuid_r((u),&(p).pws,(p).pwbuf,sizeof((p).pwbuf)) == 0) ? &(p).pws : NULL) # define _XGetpwnam(u,p) \ -((getpwnam_r((u),&(p).pws,(p).pwbuf,sizeof((p).pwbuf)) == -1) ? NULL : &(p).pws) +((getpwnam_r((u),&(p).pws,(p).pwbuf,sizeof((p).pwbuf)) == 0) ? &(p).pws : NULL) # else /* Lynx */ # define _XGetpwuid(u,p) \ -((getpwuid_r(&(p).pws,(u),(p).pwbuf,sizeof((p).pwbuf)) == -1) ? NULL : &(p).pws) +((getpwuid_r(&(p).pws,(u),(p).pwbuf,sizeof((p).pwbuf)) == 0) ? &(p).pws : NULL) # define _XGetpwnam(u,p) \ -((getpwnam_r(&(p).pws,(u),(p).pwbuf,sizeof((p).pwbuf)) == -1) ? NULL : &(p).pws) +((getpwnam_r(&(p).pws,(u),(p).pwbuf,sizeof((p).pwbuf)) == 0) ? &(p).pws : NULL) # endif # else /* SVR4 */ # define _XGetpwuid(u,p) \ @@ -312,11 +312,11 @@ typedef struct { } _Xgetpwparams; typedef int _Xgetpwret; # define _XGetpwuid(u,p) \ -((getpwuid_r((u),&(p).pws,(p).pwbuf,sizeof((p).pwbuf),&(p).pwp) == -1) ? \ - NULL : (p).pwp) +((getpwuid_r((u),&(p).pws,(p).pwbuf,sizeof((p).pwbuf),&(p).pwp) == 0) ? \ + (p).pwp : NULL) # define _XGetpwnam(u,p) \ -((getpwnam_r((u),&(p).pws,(p).pwbuf,sizeof((p).pwbuf),&(p).pwp) == -1) ? \ - NULL : (p).pwp) +((getpwnam_r((u),&(p).pws,(p).pwbuf,sizeof((p).pwbuf),&(p).pwp) == 0) ? \ + (p).pwp : NULL) #endif /* X_INCLUDE_PWD_H */ #if defined(X_INCLUDE_PWD_H) && !defined(_XOS_INCLUDED_PWD_H) @@ -452,33 +452,15 @@ typedef struct { struct servent sent; struct servent_data sdata; } _Xgetservbynameparams; -/* - * glibc-2.1.2 changes the getXXbyY_r functions to return errno instead of -1 - * in case of an error (this supposedly conforms to the latest POSIX) - * this change is conditionalized for Linux only, to be on the save side, but - * it should be correct for all implementations - */ -#if defined(linux) # define _XGethostbyname(h,hp) \ (bzero((char*)&(hp).hdata,sizeof((hp).hdata)), \ - ((gethostbyname_r((h),&(hp).hent,&(hp).hdata) == 0) ? &(hp).hent : NULL)) + ((gethostbyname_r((h),&(hp).hent,&(hp).hdata) == 0) ? &(hp).hent) : NULL) # define _XGethostbyaddr(a,al,t,hp) \ (bzero((char*)&(hp).hdata,sizeof((hp).hdata)), \ - ((gethostbyaddr_r((a),(al),(t),&(hp).hent,&(hp).hdata) == 0) ? &(hp).hent : NULL)) + ((gethostbyaddr_r((a),(al),(t),&(hp).hent,&(hp).hdata) == 0) ? &(hp).hent) : NULL) # define _XGetservbyname(s,p,sp) \ (bzero((char*)&(sp).sdata,sizeof((sp).sdata)), \ ((getservbyname_r((s),(p),&(sp).sent,&(sp).sdata) == 0) ? &(sp).sent : NULL) ) -# else -# define _XGethostbyname(h,hp) \ - (bzero((char*)&(hp).hdata,sizeof((hp).hdata)), \ - ((gethostbyname_r((h),&(hp).hent,&(hp).hdata) == -1) ? NULL : &(hp).hent)) -# define _XGethostbyaddr(a,al,t,hp) \ - (bzero((char*)&(hp).hdata,sizeof((hp).hdata)), \ - ((gethostbyaddr_r((a),(al),(t),&(hp).hent,&(hp).hdata) == -1) ? NULL : &(hp).hent)) -# define _XGetservbyname(s,p,sp) \ - (bzero((char*)&(sp).sdata,sizeof((sp).sdata)), \ - ((getservbyname_r((s),(p),&(sp).sent,&(sp).sdata) == -1) ? NULL : &(sp).sent) ) -# endif # endif # ifdef X_POSIX_THREAD_SAFE_FUNCTIONS # undef X_POSIX_THREAD_SAFE_FUNCTIONS @@ -723,9 +705,9 @@ typedef struct { # endif } _Xttynameparams; -# define _XGetlogin(p) (getlogin_r((p).buf, sizeof((p).buf)) ? NULL : (p).buf) +# define _XGetlogin(p) (getlogin_r((p).buf, sizeof((p).buf)) == 0 ? (p).buf : NULL) # define _XTtyname(f,p) \ - (ttyname_r((f), (p).buf, sizeof((p).buf)) ? NULL : (p).buf) + (ttyname_r((f), (p).buf, sizeof((p).buf)) == 0 ? (p).buf : NULL) #else /* Pre-POSIX API. @@ -1106,11 +1088,11 @@ typedef struct { } _Xgetgrparams; #define _XGetgrgid(g,p) \ - ((getgrgid_r((g), &(p).grp, (p).buf, sizeof((p).buf), &(p).result) ? \ - NULL : (p).result)) + ((getgrgid_r((g), &(p).grp, (p).buf, sizeof((p).buf), &(p).result) == 0 ? \ + (p).result) : NULL) #define _XGetgrnam(n,p) \ - ((getgrnam_r((n), &(p).grp, (p).buf, sizeof((p).buf), &(p).result) ? \ - NULL : (p).result)) + ((getgrnam_r((n), &(p).grp, (p).buf, sizeof((p).buf), &(p).result) == 0 ? \ + (p).result) : NULL) #endif #if defined(X_INCLUDE_GRP_H) && !defined(_XOS_INCLUDED_GRP_H) From hjl@lucon.org Thu Jul 22 14:03:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Thu, 22 Jul 1999 14:03:00 -0000 Subject: __setfpucw in glibc 2.0.7 Message-ID: <19990722210318.28D3F57B9@ocean.lucon.org> Hi, __setfpucw is the only function available in glibc 2.0.7 to control the FPU at the run-time. There is in glibc 2.1. But it is not available in glibc 2.0. I believe we should export it in glibc 2.1.2. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Fri Jul 23 16:01:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 23 Jul 1999 16:01:00 -0000 Subject: ELF changes Message-ID: Hi, First, I'm back. Thanks to Andreas for taking care of the checkins. Next, I've checked in (most of) the patches I've been working on over the last week. They are updating the ld.so to be closer to the next revision of the ELF specification. Unfortunately, the specification is not yet publically available so please don't ask whether I can send it. I've a few more changes but they need a bit more testing. About the changes I've checked in I'm also not 100% sure whether they work. We will find out as soon as the linker has been updated and we can test it. I'll start the linker work sometime soon. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Sat Jul 24 11:03:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 24 Jul 1999 11:03:00 -0000 Subject: __setfpucw in glibc 2.0.7 References: <19990722210318.28D3F57B9@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > __setfpucw is the only function available in glibc 2.0.7 > to control the FPU at the run-time. There is in > glibc 2.1. But it is not available in glibc 2.0. I believe > we should export it in glibc 2.1.2. No. Nobody outside the libc should have used it. This function is not portable. Therefore people should have used asms which at least is portable on machines of the same architecure. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sat Jul 24 11:09:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 24 Jul 1999 11:09:00 -0000 Subject: __setfpucw in glibc 2.0.7 References: Message-ID: <19990724180949.E954957B9@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > > __setfpucw is the only function available in glibc 2.0.7 > > to control the FPU at the run-time. There is in > > glibc 2.1. But it is not available in glibc 2.0. I believe > > we should export it in glibc 2.1.2. > > No. Nobody outside the libc should have used it. This function is > not portable. Therefore people should have used asms which at least > is portable on machines of the same architecure. > It is in glibc 2.0 and it is used by some programs. It doesn't make any senses to break existing binaries. At least, it should be global as the glibc 2.0 symbol and local as the glibc 2.1 symbol so that ld won't use it. People have been complaining about the Linux library upgrade. Why don't we try to avoid the binary incompatibility as much as we can? -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Sat Jul 24 11:25:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 24 Jul 1999 11:25:00 -0000 Subject: __setfpucw in glibc 2.0.7 References: <19990724180949.E954957B9@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > It is in glibc 2.0 and it is used by some programs. And it never must have been used. > Why don't we try to avoid the binary incompatibility as much as we > can? People must use the functions which are designed for it. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From kukuk@suse.de Sat Jul 24 12:06:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Sat, 24 Jul 1999 12:06:00 -0000 Subject: __setfpucw in glibc 2.0.7 References: <19990724180949.E954957B9@ocean.lucon.org> Message-ID: <19990724210532.A20628@Wotan.suse.de> On Sat, Jul 24, H.J. Lu wrote: > > > > hjl@lucon.org (H.J. Lu) writes: > > > > > __setfpucw is the only function available in glibc 2.0.7 > > > to control the FPU at the run-time. There is in > > > glibc 2.1. But it is not available in glibc 2.0. I believe > > > we should export it in glibc 2.1.2. > > > > No. Nobody outside the libc should have used it. This function is > > not portable. Therefore people should have used asms which at least > > is portable on machines of the same architecure. > > > > It is in glibc 2.0 and it is used by some programs. It > doesn't make any senses to break existing binaries. At > least, it should be global as the glibc 2.0 symbol > and local as the glibc 2.1 symbol so that ld won't use > it. People have been complaining about the Linux library > upgrade. Why don't we try to avoid the binary incompatibility > as much as we can? As far as I know, on our 6 SuSE Linux 6.2 CDs is only one program which uses __setfpucw. And for this I use the same workaround as for the applixware binaries. It would be really interesting to know how many programs are affected. It looks for me we waste more time in discussing this than we would need to fix this few programs. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From hjl@lucon.org Sat Jul 24 12:58:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 24 Jul 1999 12:58:00 -0000 Subject: __setfpucw in glibc 2.0.7 References: <19990724210532.A20628@Wotan.suse.de> Message-ID: <19990724195826.466EE57B9@ocean.lucon.org> > > As far as I know, on our 6 SuSE Linux 6.2 CDs is only one program > which uses __setfpucw. And for this I use the same workaround as > for the applixware binaries. > I was told quake used it. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Sat Jul 24 15:20:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 24 Jul 1999 15:20:00 -0000 Subject: more ELF changes Message-ID: Hi, I've checked in another bunch of ELF changes. With these changes we should now follow the upcoming ELF specification. Again, the new functionality is not yet tested as te linker cannot emit it yet. But it doesn't break existing programs. I had to change the RTLD_START code. This means that port maintainer for architectures != ix86 have something to do. The change are trivial and I probably could very well do it myself but I'll leave it to you. The changes are that before calling the initializers one by one there must be a similar loop before this which calls the pre-initializers. The function pointers can be found by calling _dl_preinit_next. Very simple. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From roland@frob.com Sat Jul 24 15:59:00 1999 From: roland@frob.com (Roland McGrath) Date: Sat, 24 Jul 1999 15:59:00 -0000 Subject: more ELF changes References: Message-ID: <199907242259.SAA10186@frob.com> Why don't you just change _dl_init_next to return the preinits and then the inits? From drepper@cygnus.com Sat Jul 24 17:28:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 24 Jul 1999 17:28:00 -0000 Subject: more ELF changes References: <199907242259.SAA10186@frob.com> Message-ID: Roland McGrath writes: > Why don't you just change _dl_init_next to return the preinits and then the > inits? Bookkeeping seems to bemore complicated. It's already quite complicated as it is with the different kind of initializers and the way the _dl_init_next functions are working (at, the whole function is called quite often) they should be kept simple and not have many ifs distinguishing runs of the preinit and the init. But I want to overhaul the init handling anyhow. There is no reason to do that much in assembly. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From geoffk@ozemail.com.au Sun Jul 25 06:50:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Sun, 25 Jul 1999 06:50:00 -0000 Subject: more ELF changes References: <199907242259.SAA10186@frob.com> Message-ID: <199907251349.XAA00772@geoffk.wattle.id.au> > From: Ulrich Drepper > Date: 24 Jul 1999 17:28:29 -0700 > But I want to overhaul the init handling anyhow. There is no reason > to do that much in assembly. My suggestion would be to do it in _dl_start. Pass all init functions argc, argv, and envp. This is what dlopen does anyway, so there is no point trying to do anything tricky in the startup code, because it won't work properly when the library is dlopen()ed (and we don't in fact do anything tricky now, anyway). Then you can eliminate init_first.h, which requires assembler on most targets for no particular reason; ld.so has already worked out where argv etc. are before init-first.h is run. -- Geoffrey Keating From roland@frob.com Sun Jul 25 09:53:00 1999 From: roland@frob.com (Roland McGrath) Date: Sun, 25 Jul 1999 09:53:00 -0000 Subject: more ELF changes References: <199907251349.XAA00772@geoffk.wattle.id.au> Message-ID: <199907251653.MAA00807@frob.com> > My suggestion would be to do it in _dl_start. Pass all init functions > argc, argv, and envp. This is what dlopen does anyway, so there is no > point trying to do anything tricky in the startup code, because it > won't work properly when the library is dlopen()ed (and we don't in > fact do anything tricky now, anyway). We do do something tricky in libc on the Hurd. See sysdeps/mach/hurd/i386/init-first.c; it switches stacks. It's not reasonable for DT_INIT functions in general to do tricky things, because they might be run via dlopen. But libc itself reasonably expects always to be the first library initialized, and so it can do tricky things. From drepper@cygnus.com Sun Jul 25 19:43:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sun, 25 Jul 1999 19:43:00 -0000 Subject: libio fix Message-ID: I've checked in (among other things) a patch which should help solving many of the reported libio incompatibility problems. The reason often was that a stream was opened with an old fopen() and close with a new fclose() or vice versa. This should work now. Andreas, this should also help for this one PR with this Apache/PHP problem. Let me know if you see progress or regressions. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From kukuk@suse.de Mon Jul 26 06:52:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Mon, 26 Jul 1999 06:52:00 -0000 Subject: german ftp site for glibc-crypt Message-ID: <19990726155154.A21317@Wotan.suse.de> Hello, I have a login on ftp.gwdg.de and could put glibc-crypt on ftp://ftp.gwdg.de/pub/linux/glibc Since I have a login it is no problem to update it regulary. Where could I find now the current crypt sources ? I think glibc-crypt-2.1.tar.gz is the latest one, or I????m wrong ? Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From aj@arthur.rhein-neckar.de Mon Jul 26 08:12:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 26 Jul 1999 08:12:00 -0000 Subject: german ftp site for glibc-crypt References: <19990726155154.A21317@Wotan.suse.de> Message-ID: >>>>> Thorsten Kukuk writes: > Hello, > I have a login on ftp.gwdg.de and could put glibc-crypt on > ftp://ftp.gwdg.de/pub/linux/glibc > Since I have a login it is no problem to update it regulary. Thanks! > Where could I find now the current crypt sources ? I think > glibc-crypt-2.1.tar.gz is the latest one, or I????m wrong ? Please put glibc-crypt-2.1.tar.gz, glibc-crypt-2.1.1.tar.gz (which is identical to the 2.1 version except the name change) from: http://www.ozemail.com.au/~geoffk/glibc-crypt and also the latest glibc-crypt 2.0.6/7 version you have there. If this is really our final location (I do hope so!), we should update README.template, FAQ.in and manual/install.texi for both glibc 2.1 and 2.2 branches. Andreas -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From kukuk@suse.de Mon Jul 26 08:58:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Mon, 26 Jul 1999 08:58:00 -0000 Subject: german ftp site for glibc-crypt References: <19990726155154.A21317@Wotan.suse.de> Message-ID: <19990726175753.A30761@Wotan.suse.de> On Mon, Jul 26, Andreas Jaeger wrote: > >>>>> Thorsten Kukuk writes: > > > Hello, > > > I have a login on ftp.gwdg.de and could put glibc-crypt on > > ftp://ftp.gwdg.de/pub/linux/glibc > > > Since I have a login it is no problem to update it regulary. > Thanks! > > > Where could I find now the current crypt sources ? I think > > glibc-crypt-2.1.tar.gz is the latest one, or I????m wrong ? > Please put glibc-crypt-2.1.tar.gz, glibc-crypt-2.1.1.tar.gz (which is > identical to the 2.1 version except the name change) from: > http://www.ozemail.com.au/~geoffk/glibc-crypt > > and also the latest glibc-crypt 2.0.6/7 version you have there. I have put all sources for 2.0.5, 2.0.6, 2.0.7pre6, 2.1 and 2.1.1 in ftp://ftp.gwdg.de/pub/linux/glibc/2.1 ftp://ftp.gwdg.de/pub/linux/glibc/2.1.1 ftp://ftp.gwdg.de/pub/linux/glibc/2.0.5 ftp://ftp.gwdg.de/pub/linux/glibc/2.0 ... It will be mirrord all 10 hours from my local directory to the server, so it could be that not all is there yet. > If this is really our final location (I do hope so!), we should update > README.template, FAQ.in and manual/install.texi for both glibc 2.1 and > 2.2 branches. We should try to find some mirrors. ftp.gwdg.de is a very fast ftp server, but not for all in the world. Since I have a login and the disks we use are from SuSE, I think we could use it as our final location in the moment. At least we could use it much longer then all the other sites we have problems with in the moment. Andreas, could you shange the docu ? Thanks, Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From hjl@lucon.org Mon Jul 26 09:02:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Mon, 26 Jul 1999 09:02:00 -0000 Subject: xlock and glibc 2.1.2 Message-ID: <19990726160159.A352557B9@ocean.lucon.org> Did anyone have problem with xlock? xlock dumps core after running for a while with the recent glibc 2.1.2. It didn't happen before. Any ideas? -- H.J. Lu (hjl@gnu.org) From aj@arthur.rhein-neckar.de Mon Jul 26 09:54:00 1999 From: aj@arthur.rhein-neckar.de (Andreas Jaeger) Date: Mon, 26 Jul 1999 09:54:00 -0000 Subject: german ftp site for glibc-crypt References: <19990726155154.A21317@Wotan.suse.de> <19990726175753.A30761@Wotan.suse.de> Message-ID: >>>>> Thorsten Kukuk writes: Thorsten> Andreas, could you shange the docu ? I feared that I had to do it:-). I'm appending a patch for glibc 2.1 and 2.2. Uli, please recreate README, INSTALL and FAQ. Andreas 1999-07-26 Andreas Jaeger * README.template (configurations): The crypt add-on has a new ftp side. * manual/install.texi (Installation): Likewise. --- manual/install.texi.~1~ Sun Jun 6 21:01:56 1999 +++ manual/install.texi Mon Jul 26 18:41:09 1999 @@ -26,7 +26,8 @@ Support for the @code{crypt} function is distributed separately because of United States export restrictions. If you are outside the US or Canada, you must get @code{crypt} support from a site outside the US, -such as @samp{ftp.ifi.uio.no}. +such as @samp{ftp.gwdg.de}. @samp{ftp.gwdg.de} has the crypt +distribution in @code{pub/linux/glibc}. @c Check this please someone: (Most non-US mirrors of @samp{ftp.gnu.org} will have it too.) The file you need is @file{glibc-crypt-@var{VERSION}.tar.gz}. --- FAQ.in.~1~ Fri Jul 9 06:43:43 1999 +++ FAQ.in Mon Jul 26 18:37:41 1999 @@ -458,8 +458,8 @@ The functions are available, as an add-on (see ?addon). People in the US may get it from the same place they got GNU libc from. People outside the -US should get the code from ftp.funet.fi [128.214.248.6] in the directory -pub/gnu/funet, or another archive site outside the USA. The README explains +US should get the code from ftp.gwdg.de [134.76.11.100] in the directory +pub/linux/glibc, or another archive site outside the USA. The README explains how to install the sources. If you already have the crypt code on your system the reason for the failure --- README.template.~1~ Sun Feb 7 13:28:56 1999 +++ README.template Mon Jul 26 18:38:43 1999 @@ -57,10 +57,10 @@ unpack the crypt distribution along with the rest of the C library and build; you can also build the library without getting crypt. Users outside the USA can get the crypt distribution via anonymous FTP from -ftp.funet.fi [128.214.248.6] in the directory pub/gnu/funet, or +ftp.gwdg.de [134.76.11.100] in the directory pub/linux/glibc, or another archive site outside the USA. Archive maintainers are encouraged to copy this distribution to their archives outside the -USA. Please get it from ftp.funet.fi; transferring this distribution +USA. Please get it from ftp.gwdg.de; transferring this distribution from ftp.gnu.org (or any other site in the USA) to a site outside the USA is in violation of US export laws. -- Andreas Jaeger aj@arthur.rhein-neckar.de jaeger@informatik.uni-kl.de for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de From drepper@cygnus.com Mon Jul 26 18:56:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 26 Jul 1999 18:56:00 -0000 Subject: german ftp site for glibc-crypt References: <19990726155154.A21317@Wotan.suse.de> <19990726175753.A30761@Wotan.suse.de> Message-ID: Andreas Jaeger writes: > I feared that I had to do it:-). I'm appending a patch for glibc 2.1 > and 2.2. Uli, please recreate README, INSTALL and FAQ. OK. README will be regenerated with the next release. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Mon Jul 26 22:55:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Mon, 26 Jul 1999 22:55:00 -0000 Subject: [PATCH] Allow Elf_Symndx size not match ELF arch size References: <19990726184904.U5667@mff.cuni.cz> Message-ID: Jakub send a patch to correct the handling of the .hash setion entries in ELF files. The current code assumeed different types Elf32_Symndx and Elf64_Symndx. This is not correct (ccording to the ELF specs) and most 64 bit platforms also are not using it this way. The only exception is Linux/Alpha. Therefore I've changed Jakub's patch slightly. The types Elf{32,64}_Symndx are gone. I don't think anybody used them. Instead in link.h there is a definition of Elf_Symndx. There is none in elf.h. But this is ok IMO since it's always a 32 bit type with the one exception one has to know about. If you think this change is a problem speak up now. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@varesearch.com Wed Jul 28 10:28:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Wed, 28 Jul 1999 10:28:00 -0000 Subject: wcsmbs/wctob.c change? Message-ID: <19990728172832.1A6CA3FC1@varesearch.com> Hi, Ulrich, You changed wcsmbs/wctob.c with those "__" in glibc 2.1.2. But you didn't change iconv/gconv.h. It won't even compile. Should we bring over those "__" changes from glibc 2.2 or we should just fix the bug in 2.1.2 without those "__" changes? -- H.J. Lu (hjl@gnu.org) From hjl@varesearch.com Wed Jul 28 10:43:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Wed, 28 Jul 1999 10:43:00 -0000 Subject: glibc 2.1.2 in CVS is broken. Message-ID: <19990728174254.A3B5C3FC1@varesearch.com> Hi, Ulrich, glibc 2.1.2 in CVS is broken since you put in some codes from glibc 2.2 and left some other changes which those codes depend on. Please check out glibc 2.1.2 in CVS and do a build. You will see what I mean. Thanks. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Wed Jul 28 10:53:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Wed, 28 Jul 1999 10:53:00 -0000 Subject: wcsmbs/wctob.c change? References: <19990728172832.1A6CA3FC1@varesearch.com> Message-ID: hjl@varesearch.com (H.J. Lu) writes: > Hi, Ulrich, > > You changed wcsmbs/wctob.c with those "__" in glibc 2.1.2. Will be fixed later today. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From kukuk@suse.de Thu Jul 29 10:08:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Thu, 29 Jul 1999 10:08:00 -0000 Subject: make check failed in inl-tester Message-ID: <19990729190826.A953@Wotan.suse.de> Hello, If I configure the current glibc 2.2 snapshot for i386-pc-linux-gnu, I get the following error from if I run make check: cat inl-tester.out: memset flunked test 2 memset flunked test 3 memset flunked test 4 memset flunked test 6 4 errors. configure for i686-pc-linux-gnu works without problems. I think this is from the following patch from Uli: sysdeps/i386/bits/string.h: Fix aliasing problems. I couldn????t connect to cvs in the moment. Maybe somebody has fixed this when I'm back tomorrow ;) Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@cygnus.com Thu Jul 29 10:13:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 29 Jul 1999 10:13:00 -0000 Subject: make check failed in inl-tester References: <19990729190826.A953@Wotan.suse.de> Message-ID: Thorsten Kukuk writes: > If I configure the current glibc 2.2 snapshot for i386-pc-linux-gnu, > I get the following error from if I run make check: I've fixed a problem with memset. Give it another try. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From scottb@netwinder.org Thu Jul 29 10:28:00 1999 From: scottb@netwinder.org (scottb) Date: Thu, 29 Jul 1999 10:28:00 -0000 Subject: anoncvs.cygnus.com Message-ID: <37A08EA3.249528D@netwinder.org> This server is not accepting CVS connections. Is CVS down for maintenance? Scott From hjl@varesearch.com Thu Jul 29 10:33:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Thu, 29 Jul 1999 10:33:00 -0000 Subject: A static, none thread patch Message-ID: <19990729173339.30C743FC1@varesearch.com> While working on ia64 which is static only and has no threads, the patch here is needed. You can verify it by doing # .../configure --prefix=/usr --disable-profile --disable-shared --disable-sanity-checks --disable-versioning -without-pic-default --enable-static-nss --enable-add-ons=crypt on ia32. BTW, I cannot do cvs check out. I got cvs [checkout aborted]: connect to glibc.cygnus.com:2401 failed: Connection refused Any ideas? Thanks. -- H.J. Lu (hjl@gnu.org) --- Thu Jul 29 10:20:53 1999 H.J. Lu * sysdeps/generic/bits/libc-lock.h (__libc_cleanup_end): New. * libio/iofputs.c (fputs_unlocked): Weak aliase if _IO_MTSAFE_IO is not defined. * libio/iofgets.c (fgets_unlocked): Likewise. * libio/iofread.c (fread_unlocked): Likewise. * libio/iofwrite.c (fwrite_unlocked): Likewise. * malloc/malloc.c (ptmalloc_init): Make sure __libc_pagesize is initiailized. * elf/dl-load.c (_dl_init_paths): Set up rtld_search_dirs only if necessary. Check SHARED instead of PIC. Index: sysdeps/generic/bits/libc-lock.h =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/sysdeps/generic/bits/libc-lock.h,v retrieving revision 1.1.1.1 diff -u -p -r1.1.1.1 libc-lock.h --- sysdeps/generic/bits/libc-lock.h 1997/11/06 17:04:25 1.1.1.1 +++ sysdeps/generic/bits/libc-lock.h 1999/07/29 06:42:52 @@ -90,6 +90,8 @@ /* End critical region with cleanup. */ #define __libc_cleanup_region_end(DOIT) +/* Sometimes we have to exit the block in the middle. */ +#define __libc_cleanup_end(DOIT) /* We need portable names for some of the functions. */ #define __libc_mutex_unlock Index: libio/iofputs.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/libio/iofputs.c,v retrieving revision 1.1.1.3 diff -u -p -r1.1.1.3 iofputs.c --- libio/iofputs.c 1998/06/13 18:30:45 1.1.1.3 +++ libio/iofputs.c 1999/07/29 07:07:25 @@ -48,3 +48,7 @@ _IO_fputs (str, fp) #ifdef weak_alias weak_alias (_IO_fputs, fputs) #endif + +#ifndef _IO_MTSAFE_IO +weak_alias (_IO_fputs, fputs_unlocked) +#endif Index: libio/iofgets.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/libio/iofgets.c,v retrieving revision 1.1.1.5 diff -u -p -r1.1.1.5 iofgets.c --- libio/iofgets.c 1998/11/09 16:02:25 1.1.1.5 +++ libio/iofgets.c 1999/07/29 07:09:09 @@ -65,3 +65,7 @@ _IO_fgets (buf, n, fp) #ifdef weak_alias weak_alias (_IO_fgets, fgets) #endif + +#ifndef _IO_MTSAFE_IO +weak_alias (_IO_fgets, fgets_unlocked) +#endif Index: libio/iofread.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/libio/iofread.c,v retrieving revision 1.1.1.4 diff -u -p -r1.1.1.4 iofread.c --- libio/iofread.c 1998/11/13 23:44:17 1.1.1.4 +++ libio/iofread.c 1999/07/29 07:09:43 @@ -48,3 +48,7 @@ _IO_fread (buf, size, count, fp) #ifdef weak_alias weak_alias (_IO_fread, fread) #endif + +#ifndef _IO_MTSAFE_IO +weak_alias (_IO_fread, fread_unlocked) +#endif Index: libio/iofwrite.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/libio/iofwrite.c,v retrieving revision 1.1.1.4 diff -u -p -r1.1.1.4 iofwrite.c --- libio/iofwrite.c 1998/07/15 00:17:53 1.1.1.4 +++ libio/iofwrite.c 1999/07/29 07:11:07 @@ -53,3 +53,7 @@ _IO_fwrite (buf, size, count, fp) #ifdef weak_alias weak_alias (_IO_fwrite, fwrite) #endif + +#ifndef _IO_MTSAFE_IO +weak_alias (_IO_fwrite, fwrite_unlocked) +#endif Index: malloc/malloc.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/malloc/malloc.c,v retrieving revision 1.1.1.24 diff -u -p -r1.1.1.24 malloc.c --- malloc/malloc.c 1999/07/28 16:45:14 1.1.1.24 +++ malloc/malloc.c 1999/07/29 15:54:21 @@ -1663,7 +1663,6 @@ ptmalloc_init __MALLOC_P((void)) /* Initialize the pthreads interface. */ if (__pthread_initialize != NULL) __pthread_initialize(); - __libc_pagesize = __getpagesize(); #endif mutex_init(&main_arena.mutex); mutex_init(&list_lock); @@ -1671,6 +1670,9 @@ ptmalloc_init __MALLOC_P((void)) tsd_setspecific(arena_key, (Void_t *)&main_arena); thread_atfork(ptmalloc_lock_all, ptmalloc_unlock_all, ptmalloc_init_all); #endif /* !defined NO_THREADS */ +#ifdef _LIBC + __libc_pagesize = __getpagesize(); +#endif #if defined _LIBC || defined MALLOC_HOOKS if((s = getenv("MALLOC_TRIM_THRESHOLD_"))) mALLOPt(M_TRIM_THRESHOLD, atoi(s)); Index: elf/dl-load.c =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/elf/dl-load.c,v retrieving revision 1.1.1.41 diff -u -p -r1.1.1.41 dl-load.c --- elf/dl-load.c 1999/06/27 01:13:39 1.1.1.41 +++ elf/dl-load.c 1999/07/29 16:58:43 @@ -500,7 +500,7 @@ _dl_init_paths (const char *llp) const char *strp; struct r_search_path_elem *pelem, **aelem; size_t round_size; -#ifdef PIC +#ifdef SHARED struct link_map *l; #endif @@ -518,52 +518,58 @@ _dl_init_paths (const char *llp) if (rtld_search_dirs == NULL) _dl_signal_error (ENOMEM, NULL, "cannot create search path array"); - round_size = ((2 * sizeof (struct r_search_path_elem) - 1 - + ncapstr * sizeof (enum r_dir_status)) - / sizeof (struct r_search_path_elem)); - - rtld_search_dirs[0] = (struct r_search_path_elem *) - malloc ((sizeof (system_dirs) / sizeof (system_dirs[0]) - 1) - * round_size * sizeof (struct r_search_path_elem)); - if (rtld_search_dirs[0] == NULL) - _dl_signal_error (ENOMEM, NULL, "cannot create cache for search path"); - - pelem = all_dirs = rtld_search_dirs[0]; - strp = system_dirs; - idx = 0; - - do + if (sizeof (system_dirs) / sizeof (system_dirs[0]) > 1) { - size_t cnt; - - *aelem++ = pelem; - - pelem->what = "system search path"; - pelem->where = NULL; - - pelem->dirname = strp; - pelem->dirnamelen = system_dirs_len[idx]; - strp += system_dirs_len[idx] + 1; - - if (pelem->dirname[0] != '/') - for (cnt = 0; cnt < ncapstr; ++cnt) - pelem->status[cnt] = existing; - else - for (cnt = 0; cnt < ncapstr; ++cnt) - pelem->status[cnt] = unknown; - - pelem->next = (++idx == (sizeof (system_dirs_len) - / sizeof (system_dirs_len[0])) - ? NULL : (pelem + round_size)); - - pelem += round_size; + round_size = ((2 * sizeof (struct r_search_path_elem) - 1 + + ncapstr * sizeof (enum r_dir_status)) + / sizeof (struct r_search_path_elem)); + + rtld_search_dirs[0] = (struct r_search_path_elem *) + malloc ((sizeof (system_dirs) / sizeof (system_dirs[0]) - 1) + * round_size * sizeof (struct r_search_path_elem)); + if (rtld_search_dirs[0] == NULL) + _dl_signal_error (ENOMEM, NULL, "cannot create cache for search path"); + + pelem = all_dirs = rtld_search_dirs[0]; + strp = system_dirs; + idx = 0; + + do + { + size_t cnt; + + *aelem++ = pelem; + + pelem->what = "system search path"; + pelem->where = NULL; + + pelem->dirname = strp; + pelem->dirnamelen = system_dirs_len[idx]; + strp += system_dirs_len[idx] + 1; + + if (pelem->dirname[0] != '/') + for (cnt = 0; cnt < ncapstr; ++cnt) + pelem->status[cnt] = existing; + else + for (cnt = 0; cnt < ncapstr; ++cnt) + pelem->status[cnt] = unknown; + + pelem->next = (++idx == (sizeof (system_dirs_len) + / sizeof (system_dirs_len[0])) + ? NULL : (pelem + round_size)); + + pelem += round_size; + } + while (idx < sizeof (system_dirs_len) + / sizeof (system_dirs_len[0])); } - while (idx < sizeof (system_dirs_len) / sizeof (system_dirs_len[0])); + else + rtld_search_dirs[0] = NULL; max_dirnamelen = SYSTEM_DIRS_MAX_LEN; *aelem = NULL; -#ifdef PIC +#ifdef SHARED /* This points to the map of the main object. */ l = _dl_loaded; if (l != NULL) @@ -580,7 +586,7 @@ _dl_init_paths (const char *llp) else l->l_rpath_dirs = NULL; } -#endif /* PIC */ +#endif /* SHARED */ if (llp != NULL && *llp != '\0') { From drepper@cygnus.com Thu Jul 29 10:33:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 29 Jul 1999 10:33:00 -0000 Subject: anoncvs.cygnus.com References: <37A08EA3.249528D@netwinder.org> Message-ID: scottb writes: > This server is not accepting CVS connections. Is CVS down for > maintenance? Don't know. I can ask when I'm in the office. The server now limits the number of anonymous users allowed at one time. In fact, it decides about this based on the system load. If the load is higher than 15 the connections are refused. We had to add this since the server constantly ran with load > 40. So, maybe this i s what you are seeing. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Thu Jul 29 12:49:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Thu, 29 Jul 1999 12:49:00 -0000 Subject: suseconds_t and struct timeval Message-ID: <19990729194852.261BD57BA@ocean.lucon.org> Hi, According to the Unix standard, suseconds_t should be used in struct timeval. Why doesn't glibc use it? -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Thu Jul 29 13:04:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 29 Jul 1999 13:04:00 -0000 Subject: suseconds_t and struct timeval References: <19990729194852.261BD57BA@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > According to the Unix standard, suseconds_t should be used in > struct timeval. Why doesn't glibc use it? Why don't you first look before complaining? -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Thu Jul 29 13:38:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Thu, 29 Jul 1999 13:38:00 -0000 Subject: suseconds_t and struct timeval References: Message-ID: <19990729203754.C34DB57BA@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > > According to the Unix standard, suseconds_t should be used in > > struct timeval. Why doesn't glibc use it? > > Why don't you first look before complaining? > I did, yesterday's glibc 2.1.2 in CVS. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Thu Jul 29 13:43:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 29 Jul 1999 13:43:00 -0000 Subject: putenv Message-ID: I've now fixed the putenv implementation and at the same time found and fixed a bug in unsetenv. I also wrote a little test suite for these functions which people hopefully will extend (hint hint). -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From drepper@cygnus.com Thu Jul 29 13:47:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 29 Jul 1999 13:47:00 -0000 Subject: suseconds_t and struct timeval References: <19990729203754.C34DB57BA@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > I did, yesterday's glibc 2.1.2 in CVS. This is not the development branch. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@varesearch.com Thu Jul 29 14:50:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Thu, 29 Jul 1999 14:50:00 -0000 Subject: Another libc patch Message-ID: <19990729215025.4DC783FC1@varesearch.com> Here is the patch I found out while working on ia64. -- H.J. Lu (hjl@gnu.org) --- Thu Jul 29 14:15:11 1999 H.J. Lu * stdlib/mbtowc.c: Include . * stdlib/wctomb.c: Likewise. * sysdeps/unix/sysv/linux/fstatfs64.c: Likewise. * sysdeps/unix/sysv/linux/statfs64.c: Likewise. * iconv/gconv_open.c: Likewise. * misc/mntent_r.c: Include . * elf/dl-runtime.c: Likewise. * misc/qefgcvt.c: Handle LDBL_MANT_DIG == DBL_MANT_DIG. * misc/qefgcvt_r.c: Likewise. * Makeconfig (CPPFLAGS-.os): Add -DSHARED. --- /work/gnu/import/glibc-2.1/libc/stdlib/mbtowc.c Wed Jul 28 16:15:03 1999 +++ stdlib/mbtowc.c Thu Jul 29 13:03:29 1999 @@ -19,6 +19,7 @@ #include #include #include +#include #include --- /work/gnu/import/glibc-2.1/libc/stdlib/wctomb.c Wed Jul 28 16:15:03 1999 +++ stdlib/wctomb.c Thu Jul 29 13:03:53 1999 @@ -17,6 +17,7 @@ Boston, MA 02111-1307, USA. */ #include +#include #include #include #include --- /work/gnu/import/glibc-2.1/libc/sysdeps/unix/sysv/linux/fstatfs64.c Sat Dec 26 17:33:38 1998 +++ sysdeps/unix/sysv/linux/fstatfs64.c Thu Jul 29 13:10:59 1999 @@ -20,6 +20,7 @@ #include #include #include +#include /* Return information about the filesystem on which FD resides. */ int --- /work/gnu/import/glibc-2.1/libc/sysdeps/unix/sysv/linux/statfs64.c Sat Dec 26 17:33:38 1998 +++ sysdeps/unix/sysv/linux/statfs64.c Thu Jul 29 13:11:04 1999 @@ -20,6 +20,7 @@ #include #include #include +#include /* Return information about the filesystem on which FILE resides. */ int --- /work/gnu/import/glibc-2.1/libc/iconv/gconv_open.c Wed Apr 28 14:42:24 1999 +++ iconv/gconv_open.c Thu Jul 29 14:19:01 1999 @@ -20,6 +20,7 @@ #include #include +#include #include --- /work/gnu/import/glibc-2.1/libc/misc/mntent_r.c Wed Jul 28 09:28:26 1999 +++ misc/mntent_r.c Thu Jul 29 13:04:57 1999 @@ -20,6 +20,7 @@ #include #include #include +#include #include #ifdef USE_IN_LIBIO --- /work/gnu/import/glibc-2.1/libc/elf/dl-runtime.c Thu Jul 15 15:36:44 1999 +++ elf/dl-runtime.c Thu Jul 29 14:22:07 1999 @@ -18,6 +18,7 @@ Boston, MA 02111-1307, USA. */ #include +#include #include #include "dynamic-link.h" --- /work/gnu/import/glibc-2.1/libc/misc/qefgcvt.c Wed Jul 28 16:15:03 1999 +++ misc/qefgcvt.c Thu Jul 29 13:58:02 1999 @@ -19,6 +19,7 @@ #include +#if LDBL_MANT_DIG != DBL_MANT_DIG #define FLOAT_TYPE long double #define FUNC_PREFIX q #define FLOAT_FMT_FLAG "L" @@ -34,3 +35,36 @@ #endif #include "efgcvt.c" +#else +#include + +char * +qfcvt (value, ndigit, decpt, sign) + long double value; + int ndigit; + int *decpt; + int *sign; +{ + return fcvt (value, ndigit, decpt, sign); +} + + +char * +qecvt (value, ndigit, decpt, sign) + long double value; + int ndigit; + int *decpt; + int *sign; +{ + return ecvt (value, ndigit, decpt, sign); +} + +char * +qgcvt (value, ndigit, buf) + long double value; + int ndigit; + char *buf; +{ + return gcvt (value, ndigit, buf); +} +#endif --- /work/gnu/import/glibc-2.1/libc/misc/qefgcvt_r.c Wed Jul 28 16:15:03 1999 +++ misc/qefgcvt_r.c Thu Jul 29 13:58:12 1999 @@ -20,6 +20,7 @@ #include +#if LDBL_MANT_DIG != DBL_MANT_DIG #define FLOAT_TYPE long double #define FUNC_PREFIX q #define FLOAT_FMT_FLAG "L" @@ -32,3 +33,30 @@ #endif #include "efgcvt_r.c" +#else +#include + +int +qfcvt_r (value, ndigit, decpt, sign, buf, len) + long double value; + int ndigit; + int *decpt; + int *sign; + char *buf; + size_t len; +{ + return fcvt_r (value, ndigit, decpt, sign, buf, len); +} + +int +qecvt_r (value, ndigit, decpt, sign, buf, len) + long double value; + int ndigit; + int *decpt; + int *sign; + char *buf; + size_t len; +{ + return ecvt_r (value, ndigit, decpt, sign, buf, len); +} +#endif --- /work/gnu/import/glibc-2.1/libc/Makeconfig Sun Jun 13 10:12:32 1999 +++ Makeconfig Thu Jul 29 12:04:08 1999 @@ -598,7 +598,7 @@ ifeq (yes,$(build-shared)) # Under --enable-shared, we will build a shared library of PIC objects. # The PIC object files are named foo.os. object-suffixes += .os -CPPFLAGS-.os = -DPIC +CPPFLAGS-.os = -DPIC -DSHARED CFLAGS-.os = $(filter %frame-pointer,$(+cflags)) $(pic-ccflag) libtype.os := lib%_pic.a # This can be changed by a sysdep makefile From drepper@cygnus.com Thu Jul 29 15:05:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 29 Jul 1999 15:05:00 -0000 Subject: Another libc patch References: <19990729215025.4DC783FC1@varesearch.com> Message-ID: hjl@varesearch.com (H.J. Lu) writes: > * stdlib/mbtowc.c: Include . > * stdlib/wctomb.c: Likewise. > * sysdeps/unix/sysv/linux/fstatfs64.c: Likewise. > * sysdeps/unix/sysv/linux/statfs64.c: Likewise. > * iconv/gconv_open.c: Likewise. I simply ignore your patches if you don't tell me why. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@varesearch.com Thu Jul 29 15:08:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Thu, 29 Jul 1999 15:08:00 -0000 Subject: Another libc patch References: Message-ID: <19990729220813.B251E3FC1@varesearch.com> > > hjl@varesearch.com (H.J. Lu) writes: > > > * stdlib/mbtowc.c: Include . > > * stdlib/wctomb.c: Likewise. > > * sysdeps/unix/sysv/linux/fstatfs64.c: Likewise. > > * sysdeps/unix/sysv/linux/statfs64.c: Likewise. > > * iconv/gconv_open.c: Likewise. > > I simply ignore your patches if you don't tell me why. > They all use string functions, memxxx. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Thu Jul 29 23:34:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Thu, 29 Jul 1999 23:34:00 -0000 Subject: A static, none thread patch References: <19990729173339.30C743FC1@varesearch.com> Message-ID: I have added the patch except for this: > * elf/dl-load.c (_dl_init_paths): Set up rtld_search_dirs only > if necessary. If there are no system dirs something is wrong. > Check SHARED instead of PIC. I won't add this isolated patch. And I'm still not convinced it's really necesary. And HJ: Please finally learn that I do read the mailing list and don't send me the patches twice. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Fri Jul 30 07:35:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Fri, 30 Jul 1999 07:35:00 -0000 Subject: A static, none thread patch References: Message-ID: <19990730143358.3585757B9@ocean.lucon.org> > > I have added the patch except for this: > I'd like to see them in 2.1.2 branch. I cannot use 2.2 for ia64. I need a known working, stable C library for ia64. > > * elf/dl-load.c (_dl_init_paths): Set up rtld_search_dirs only > > if necessary. > > If there are no system dirs something is wrong. As I said, I got it when I configured glibc as static only on ia32. I got ----trusted-dirs.h--- #define SYSTEM_DIRS \ "" #define SYSTEM_DIRS_LEN \ 0 #define SYSTEM_DIRS_MAX_LEN 0 ---- Maybe it is due to there is no run-time linker configured. > > > Check SHARED instead of PIC. > > I won't add this isolated patch. And I'm still not convinced it's > really necesary. > I will see if it is needed for ia64 when everything is there. Thanks. H.J. From hjl@varesearch.com Fri Jul 30 07:43:00 1999 From: hjl@varesearch.com (H.J. Lu) Date: Fri, 30 Jul 1999 07:43:00 -0000 Subject: More none thread patch for glibc Message-ID: <19990730144249.5E3463FC1@varesearch.com> It turned out we may need all those xxx_unlocked functions if thread is not available. Here is the rest of patch. Thanks. -- H.J. Lu (hjl@gnu.org) -- Fri Jul 30 07:38:26 1999 H.J. Lu * libio/iofflush.c (fflush_unlocked): Weak aliase if _IO_MTSAFE_IO is not defined. * libio/clearerr.c (clearerr_unlocked): Likewise. * libio/feof.c (feof_unlocked): Likewise. * libio/ferror.c (ferror_unlocked): Likewise. * libio/fputc.c (fputc_unlocked): Likewise. * libio/getc.c (getc_unlocked, fgetc_unlocked): Likewise. * libio/getchar.c (getchar_unlocked): Likewise. * libio/putc.c (putc_unlocked): Likewise. * libio/putchar.c (putchar_unlocked): Likewise. --- /work/gnu/import/glibc-2.1/libc/libio/iofflush.c Sun Jun 7 06:47:16 1998 +++ libio/iofflush.c Thu Jul 29 15:52:08 1999 @@ -47,4 +47,8 @@ _IO_fflush (fp) #ifdef weak_alias weak_alias (_IO_fflush, fflush) + +#ifndef _IO_MTSAFE_IO +weak_alias (_IO_fflush, fflush_unlocked) +#endif #endif --- /work/gnu/import/glibc-2.1/libc/libio/clearerr.c Mon Feb 24 21:16:00 1997 +++ libio/clearerr.c Thu Jul 29 15:49:09 1999 @@ -28,3 +28,7 @@ clearerr (fp) _IO_clearerr (fp); _IO_funlockfile (fp); } + +#if defined weak_alias && !defined _IO_MTSAFE_IO +weak_alias (clearerr, clearerr_unlocked) +#endif --- /work/gnu/import/glibc-2.1/libc/libio/feof.c Tue Aug 19 20:39:59 1997 +++ libio/feof.c Thu Jul 29 15:52:44 1999 @@ -40,4 +40,9 @@ _IO_feof (fp) #ifdef weak_alias weak_alias (_IO_feof, feof) + +#ifndef _IO_MTSAFE_IO +#undef feof_unlocked +weak_alias (_IO_feof, feof_unlocked) +#endif #endif --- /work/gnu/import/glibc-2.1/libc/libio/ferror.c Tue Aug 19 20:39:59 1997 +++ libio/ferror.c Thu Jul 29 15:52:51 1999 @@ -40,4 +40,9 @@ _IO_ferror (fp) #ifdef weak_alias weak_alias (_IO_ferror, ferror) + +#ifndef _IO_MTSAFE_IO +#undef ferror_unlocked +weak_alias (_IO_ferror, ferror_unlocked) +#endif #endif --- /work/gnu/import/glibc-2.1/libc/libio/fputc.c Sun Jun 7 06:47:04 1998 +++ libio/fputc.c Thu Jul 29 15:52:56 1999 @@ -40,3 +40,8 @@ fputc (c, fp) _IO_cleanup_region_end (0); return result; } + +#if defined weak_alias && !defined _IO_MTSAFE_IO +#undef fputc_unlocked +weak_alias (fputc, fputc_unlocked) +#endif --- /work/gnu/import/glibc-2.1/libc/libio/getc.c Tue Jan 26 12:46:42 1999 +++ libio/getc.c Thu Jul 29 15:53:01 1999 @@ -47,4 +47,10 @@ _IO_getc (fp) #ifdef weak_alias weak_alias (_IO_getc, getc) weak_alias (_IO_getc, fgetc) + +#ifndef _IO_MTSAFE_IO +#undef getc_unlocked +weak_alias (_IO_getc, getc_unlocked) +weak_alias (_IO_getc, fgetc_unlocked) +#endif #endif --- /work/gnu/import/glibc-2.1/libc/libio/getchar.c Sun Jun 7 06:47:14 1998 +++ libio/getchar.c Thu Jul 29 15:53:05 1999 @@ -39,3 +39,8 @@ getchar () _IO_cleanup_region_end (0); return result; } + +#if defined weak_alias && !defined _IO_MTSAFE_IO +#undef getchar_unlocked +weak_alias (getchar, getchar_unlocked) +#endif --- /work/gnu/import/glibc-2.1/libc/libio/putc.c Sun Jun 7 06:47:39 1998 +++ libio/putc.c Thu Jul 29 15:54:19 1999 @@ -40,4 +40,9 @@ _IO_putc (c, fp) #ifdef weak_alias weak_alias (_IO_putc, putc) + +#ifndef _IO_MTSAFE_IO +#undef putc_unlocked +weak_alias (_IO_putc, putc_unlocked) +#endif #endif --- /work/gnu/import/glibc-2.1/libc/libio/putchar.c Sun Jun 7 06:47:40 1998 +++ libio/putchar.c Thu Jul 29 15:55:07 1999 @@ -34,3 +34,8 @@ putchar (c) _IO_cleanup_region_end (0); return result; } + +#if defined weak_alias && !defined _IO_MTSAFE_IO +#undef putchar_unlocked +weak_alias (putchar, putchar_unlocked) +#endif From roland@frob.com Fri Jul 30 07:57:00 1999 From: roland@frob.com (Roland McGrath) Date: Fri, 30 Jul 1999 07:57:00 -0000 Subject: A static, none thread patch References: <19990730143358.3585757B9@ocean.lucon.org> Message-ID: <199907301457.KAA14406@frob.com> > > > * elf/dl-load.c (_dl_init_paths): Set up rtld_search_dirs only > > > if necessary. > > > > If there are no system dirs something is wrong. > > As I said, I got it when I configured glibc as static only on ia32. > I got This is the bug. If you are building the elf subdir at all, even static-only, you need a definition for this (for libdl.a to use). The right fix is probably just to move the default-rpath definition in Makeconfig out of the $(build-shared) conditional, since it's in fact needed any time elf/ is built whether shared or static. From drepper@cygnus.com Fri Jul 30 22:20:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 30 Jul 1999 22:20:00 -0000 Subject: interesting change Message-ID: First, sorry for the broken patch I've added. HJ's malloc patch was buggy and I haven't tested it before I added it. It should be back to normal now. Then, to end the working week I walked into rth's office and complained about gcc limiting me to write good code. The result: an hour later we he had a patch which solved the problem. It is now in the egcs mainline. The problem to solve was the handling of tables with addresses of local labels. I introduced this in vfprintf.c. Ever since the data section was big because of the tables which had to be relocated and therefore couldn't be made read-only. Also, there were runtime relocations. This is now gone and the data section is slim again and startup time got better again. I hope I got the configure test and the conditionals right. But you'll certainly let me know. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From kukuk@suse.de Fri Jul 30 23:04:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Fri, 30 Jul 1999 23:04:00 -0000 Subject: interesting change References: Message-ID: <19990731080219.A6381@Wotan.suse.de> On Fri, Jul 30, Ulrich Drepper wrote: > First, sorry for the broken patch I've added. HJ's malloc patch was > buggy and I haven't tested it before I added it. It should be back to > normal now. There are some more problems with the your __libc_pagesize optimization. The list of commercial applications crashing with this patch enlarges every week. It seems all of this application uses it's own malloc functions. The both biggest Applications are StarOffice 5.1 and CA UniCenter TNG f????r Linux. Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@cygnus.com Fri Jul 30 23:18:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Fri, 30 Jul 1999 23:18:00 -0000 Subject: interesting change References: <19990731080219.A6381@Wotan.suse.de> Message-ID: Thorsten Kukuk writes: > There are some more problems with the your __libc_pagesize optimization. > The list of commercial applications crashing with this patch enlarges > every week. > It seems all of this application uses it's own malloc functions. Well, if they are using their own malloc, how can this be a problem? The initialization happens at the right time. It can only be that these application do something forbidden. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From kukuk@suse.de Fri Jul 30 23:52:00 1999 From: kukuk@suse.de (Thorsten Kukuk) Date: Fri, 30 Jul 1999 23:52:00 -0000 Subject: interesting change References: <19990731080219.A6381@Wotan.suse.de> Message-ID: <19990731085101.A9440@Wotan.suse.de> On Fri, Jul 30, Ulrich Drepper wrote: > Thorsten Kukuk writes: > > > There are some more problems with the your __libc_pagesize optimization. > > The list of commercial applications crashing with this patch enlarges > > every week. > > It seems all of this application uses it's own malloc functions. > > Well, if they are using their own malloc, how can this be a problem? > The initialization happens at the right time. It can only be that > these application do something forbidden. Maybe our own glibc functins are using our own malloc ? I only know the following: - As far as I know all of this software has it's own malloc - It always crashes in one of our malloc functions - __libc_pagesize is initialized when it crashes - If I revert the __libc_pagesize patch all Application works. - I haven't found a program with source where I could debug it. My only ideas about this: 1. One of our malloc function was called before the crash in a way that __libc_pagesize is not set the first time. 2. The application malloc changes pagesize ? (Don't think this is possible, but ...) Thorsten -- Thorsten Kukuk http://www.suse.de/~kukuk/ kukuk@suse.de SuSE GmbH Schanzaeckerstr. 10 90443 Nuernberg Linux is like a Vorlon. It is incredibly powerful, gives terse, cryptic answers and has a lot of things going on in the background. From drepper@cygnus.com Sat Jul 31 00:00:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 31 Jul 1999 00:00:00 -0000 Subject: interesting change References: <19990731080219.A6381@Wotan.suse.de> <19990731085101.A9440@Wotan.suse.de> Message-ID: Thorsten Kukuk writes: > 1. One of our malloc function was called before the crash in > a way that __libc_pagesize is not set the first time. The value is set in a constructor which runs before any application code. Except if the application somehow inluences the constructors which does not only break mallo.c > 2. The application malloc changes pagesize ? (Don't think this > is possible, but ...) No, this is not possible. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sat Jul 31 11:34:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 31 Jul 1999 11:34:00 -0000 Subject: gcc 2.95 and glibc 2.1.2 1999 0728 Message-ID: <19990731183308.13FF357BA@ocean.lucon.org> Hi, Something is wrong with gcc 2.95 and glibc 2.1.2 1999 0728. After I used gcc 2.95 to compile glibc 2.1.2 1999 0728 on i686, the resulting shared glibc no longer works right. Even the existing egcs 1.1.2 binary will generate wrong code. I am looking into it now. -- H.J. Lu (hjl@gnu.org) From hjl@lucon.org Sat Jul 31 12:51:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 31 Jul 1999 12:51:00 -0000 Subject: ./string/bits/string2.h in glibc 2.1.2 is bad Message-ID: <19990731195031.1F24457BA@ocean.lucon.org> Hi, ./string/bits/string2.h in glibc 2.1.2 1999 0728 is bad. The one in glibc 2.1.2 1999 0711 is ok. It generates the wrong code for makeinfo.c in gcc 2.95 when compiled with -O2 using egcs 1.1.2. -- H.J. Lu (hjl@gnu.org) From drepper@cygnus.com Sat Jul 31 12:57:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 31 Jul 1999 12:57:00 -0000 Subject: ./string/bits/string2.h in glibc 2.1.2 is bad References: <19990731195031.1F24457BA@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > ./string/bits/string2.h in glibc 2.1.2 1999 0728 is bad. The one > in glibc 2.1.2 1999 0711 is ok. It generates the wrong code for > makeinfo.c in gcc 2.95 when compiled with -O2 using egcs 1.1.2. No, the old one is not correct. I haven't seen any problems with the new one. As usual, tell me *what* is failing,, and that that it is failing. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sat Jul 31 14:39:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 31 Jul 1999 14:39:00 -0000 Subject: ./string/bits/string2.h in glibc 2.1.2 is bad References: Message-ID: <19990731213753.6D1C357BA@ocean.lucon.org> > > hjl@lucon.org (H.J. Lu) writes: > > > ./string/bits/string2.h in glibc 2.1.2 1999 0728 is bad. The one > > in glibc 2.1.2 1999 0711 is ok. It generates the wrong code for > > makeinfo.c in gcc 2.95 when compiled with -O2 using egcs 1.1.2. > > No, the old one is not correct. I haven't seen any problems with the > new one. As usual, tell me *what* is failing,, and that that it is > failing. > I have said that makeinfo in gcc 2.95 was miscompiled with -O2. Here is the patch for the typo. Please double check your change to string/bits/string2.h to see if there are any more obvious typos. Thanks. H.J. --- Sat Jul 31 14:33:23 1999 H.J. Lu * string/bits/string2.h (__strcpy_small): Fix a typo. Index: string/bits/string2.h =================================================================== RCS file: /work/cvs/gnu/glibc-2.1/string/bits/string2.h,v retrieving revision 1.1.1.23 diff -u -p -r1.1.1.23 string2.h --- string/bits/string2.h 1999/07/28 16:41:11 1.1.1.23 +++ string/bits/string2.h 1999/07/31 21:32:38 @@ -442,7 +442,7 @@ __strcpy_small (char *__dest, case 8: __u->__ui = __src0_4; __u = (void *) __u + 4; - __u->__usi = __src4_4; + __u->__ui = __src4_4; break; } return __dest; From drepper@cygnus.com Sat Jul 31 15:32:00 1999 From: drepper@cygnus.com (Ulrich Drepper) Date: Sat, 31 Jul 1999 15:32:00 -0000 Subject: ./string/bits/string2.h in glibc 2.1.2 is bad References: <19990731213753.6D1C357BA@ocean.lucon.org> Message-ID: hjl@lucon.org (H.J. Lu) writes: > Please double check your change to string/bits/string2.h to see if > there are any more obvious typos. Thanks for the patch. It's in. And there is no such problem anymore. And I'll add an appropriate test case to the testsuite. -- ---------------. drepper at gnu.org ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Cygnus Solutions `--' drepper at cygnus.com `------------------------ From hjl@lucon.org Sat Jul 31 15:56:00 1999 From: hjl@lucon.org (H.J. Lu) Date: Sat, 31 Jul 1999 15:56:00 -0000 Subject: ldconfig 1999-07-31 References: <19990609211301.C949@mff.cuni.cz> Message-ID: <19990731225448.A769B57BA@ocean.lucon.org> Hi, I put the new ldconfig for glibc 2 at ftp://ftp.varesearch.com/pub/support/hjl/glibc/ldconfig-1999-07-31.tar.gz --- This is a modified ldconfig for glibc 2 based on ldconfig.c in ld.so 1.9.10. ldconfig.c and readelf.c should be copied to libc/elf in the glibc 2 source tree by hand. The glibc 2 configure/build/install processes will pick them up automatically. H.J. hjl@lucon.org 07/31/99 From geoffk@ozemail.com.au Sat Jul 31 20:42:00 1999 From: geoffk@ozemail.com.au (Geoff Keating) Date: Sat, 31 Jul 1999 20:42:00 -0000 Subject: interesting change References: <19990731080219.A6381@Wotan.suse.de> <19990731085101.A9440@Wotan.suse.de> Message-ID: <199907310741.RAA00956@gluttony.geoffk.wattle.id.au> > Mailing-List: contact libc-hacker-help@sourceware.cygnus.com; run by ezmlm > List-Unsubscribe: < mailto:libc-hacker-unsubscribe-geoffk=discus.anu.edu.au@sourceware.cygnus.com > > List-Archive: < http://sourceware.cygnus.com/ml/libc-hacker/ > > List-Help: < mailto:libc-hacker-help@sourceware.cygnus.com >, > < http://sourceware.cygnus.com/ml/#faqs > > Cc: libc-hacker@sourceware.cygnus.com > Reply-To: drepper@cygnus.com (Ulrich Drepper) > From: Ulrich Drepper > Date: 30 Jul 1999 23:56:06 -0700 > > Thorsten Kukuk writes: > > > 1. One of our malloc function was called before the crash in > > a way that __libc_pagesize is not set the first time. > > The value is set in a constructor which runs before any application > code. Except if the application somehow inluences the constructors > which does not only break mallo.c It's possible that ld.so has started calling the wrong malloc() again. There's a short window when ld.so musn't call malloc(), because it will get the application's malloc before it has run the constructors. The easiest way to find this is to have a small application: void *malloc(size_t m) { write (STDOUT_FILENO, "malloc called\n", 14); return 0; } void _start(void) { write (STDOUT_FILENO, "ok to call malloc after this\n", 29); _exit(0); } -- Geoffrey Keating