>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
[email protected]:/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:
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "[email protected]"
