>Number:         22754
>Category:       port-mips
>Synopsis:       mips ld.elf_so picks weak alias over strong alias
>Confidential:   no
>Severity:       serious
>Priority:       high
>Responsible:    port-mips-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 12 09:13:00 UTC 2003
>Closed-Date:
>Last-Modified:
>Originator:     Havard Eidnes
>Release:        NetBSD 1.6Z Sep 8 2003
>Organization:
>Environment:
System: NetBSD viola.urc.uninett.no 1.6Z NetBSD 1.6Z (VIOLA) #3: Mon Sep  8 14:44:31 CEST 2003  he@viola.urc.uninett.no:/usr/obj/sys/arch/sgimips/compile/VIOLA sgimips
Architecture: mips
Machine: sgimips
>Description:
	During an attempt at building X11 sets for -current sgimips, I
	stumbled across this problem that the "makekeys" program dumps
	core.  The program is compiled like this:

gcc -o makekeys -O2 -ansi -Dasm=__asm    -I../.. -I../../exports/include  -DCSRG_BASED   -DFUNCPROTO=15 -DNARROWPROTO -DXTHREADS  -D_REENTRANT -DXUSE_MTSAFE_API -DXNO_MTSAFE_PWDAPI  -DUSE_NBSD_THREADLIB   -DHAS_SNPRINTF -DLIBX11  util/makekeys.c -L/usr/X11R6/lib -lpthread   -Wl,-rpath,/usr/X11R6/lib -Wl,-rpath-link,../../exports/lib -Wl,-rpath,/lib

	and it fails with

./makekeys < ../../exports/include/X11/keysymdef.h > ks_tables_h
[1]   Abort trap (core dumped) ./makekeys <../....

*** Failed target:  ks_tables.h
*** Failed command: ./makekeys < ../../exports/include/X11/keysymdef.h > ks_tables_h
*** Error code 134

Stop.

	(which doesn't stop the make job, BTW; I thouhgt it should
	have...)

	The stack backtrace in the core dump looks like this:

(gdb) where
#0  0x3007e364 in kill ()
#1  0x30081ee4 in __libc_mutex_unlock ()
#2  0x3011621c in __cxa_atexit ()
#3  0x301165a0 in atexit ()
#4  0x400b80 in _rtld_setup ()
#5  0x4009bc in _start ()
#6  0x2650 in rtld_start ()
#7  0x2650 in rtld_start ()
#8  0x2650 in rtld_start ()
#9  0x2650 in rtld_start ()

	etc. etc. (rtld_start repeats -- another bug?)

	I've single-stepped through the startup of the program, and it
	appears that the debugger thinks that __libc_mutex_lock and
	__libc_mutex_unlock is the same thing due to the definition of
	both as a weak alias for __libc_mutex_catchall_stub:

__weak_alias(__libc_mutex_lock,__libc_mutex_catchall_stub)
__weak_alias(__libc_mutex_unlock,__libc_mutex_catchall_stub)

	and __libc_mutex_catchall_stub checks to see if the program is
	threaded, and if so, aborts, as observed.

	However, __libc_mutex_lock is defined as a strong alias in
	libpthread's pthread_mutex.c:

__strong_alias(__libc_mutex_lock,pthread_mutex_lock)

	and I would have thought that that binding should have been
	preferred over the weak alias?  (I'm threading on thin ice
	here, but other platforms appear to do this in the expected
	manner.)


>How-To-Repeat:
	Try to build X11 on -current sgimips; watch the makekeys
	program fail as shown above.

>Fix:
	I do not know, sorry.

	I do however think that the problem observed in PR#19183 is
	related to this problem (wrong malloc/free used in tcsh when
	the user supplies his own versions).
>Release-Note:
>Audit-Trail:
>Unformatted: