misc/180568: r251672 breaks applications which depends on dlopen("libc.so")

[Taku YAMAMOTO]

>Number:         180568
>Category:       misc
>Synopsis:       r251672 breaks applications which depends on dlopen("libc.so")
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Jul 15 06:20:00 UTC 2013
>Closed-Date:
>Last-Modified:
>Originator:     Taku YAMAMOTO
>Release:        10-current as of r252907
>Organization:
Unique Vision Company, Japan
>Environment:
FreeBSD biotite.tackymt.homeip.net 10.0-CURRENT FreeBSD 10.0-CURRENT #274 r+410f38ed-dirty: Sun Jul 14 10:53:03 JST 2013     taku at biotite.tackymt.homeip.net:/home/taku/work/build/biotite/usr/src/sys/BIOTITE  i386
>Description:
After r251672 /usr/lib/libc.so becomes a plain ASCII text file which contains a linker script.

Unfortunately, now dlopen("libc.so") fails because it's not an ELF file, resulting applications which depend on dlopen("libc.so") get broken.

Applications which are broken by r251672 currently I know includes, but potentially not limited to:
 - Firefox (it boots, but exhibits broken behaviour)
 - Mono applications which P/Invoke libc functions (ends up with System.DllNotFoundException: libc.so)
>How-To-Repeat:
Firefox case:
Launch Firefox with libmap.conf empty.
Firefox boots, but it won't load the previous session, URL bar won't navigate us anywhere, etc.

Mono applications which use libgdiplus, or anything which P/Invoke's libc's functions:
Launch such applications with libmap.conf empty.
They ends up with: System.DllNotFoundException: libc.so
>Fix:
Note this is only a workaround!

Put the following line into libmap.conf:
libc.so	libc.so.7


>Release-Note:
>Audit-Trail:
>Unformatted: