Summary: | multiple threading libraries cause symbol mixing/ambiguity and resultant crashes/instability | ||
---|---|---|---|
Product: | Gentoo/Alt | Reporter: | Joe Peterson (RETIRED) <lavajoe> |
Component: | FreeBSD | Assignee: | Gentoo/BSD Team <bsd+disabled> |
Status: | RESOLVED FIXED | ||
Severity: | critical | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | FreeBSD | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 193695 | ||
Bug Blocks: | |||
Attachments: |
freebsd-lib-6.2-r3.ebuild
freebsd-lib-6.2-r3.ebuild freebsd-lib-6.2-r3.ebuild Move libthr to / freebsd-lib-6.2-r3.euild freebsd-lib freebsd-lib-6.2-r2.ebuild |
Description
Joe Peterson (RETIRED)
2007-09-16 17:55:36 UTC
Created attachment 131069 [details, diff]
freebsd-lib-6.2-r3.ebuild
This ebuild patch will re-link the libs as described; I am testing this setup now.
I have been testing two g/fbsd systems with this patch installed. One uses GCC 4.1.2, and the other 4.2.0, and both now use Xorg 1.4 (one upgraded while patch installed). Both systems also have had 'emerge system' performed. Both have worked flawlessly, so I recommend incorporating this patch into freebsd-lib until the specific cause of the symbol mixing is determined. When the symbols are confused, we know segfaults can result, but I suspect even worse insidious issues could result from the corruption of the %%gs register contents. Created attachment 131821 [details, diff]
freebsd-lib-6.2-r3.ebuild
New version of the ebuild that does not build libpthread or libc_r (done with make options). It then does not need to remove these libs before making the symlinks.
Created attachment 131840 [details, diff]
freebsd-lib-6.2-r3.ebuild
I think is is better so that bins built against libpthread.so.2 still work.
Also, we need to move libthr to / now.
Created attachment 131841 [details, diff]
Move libthr to /
Created attachment 131864 [details, diff]
freebsd-lib-6.2-r3.euild
Created attachment 131934 [details, diff]
freebsd-lib
Preserve old libs is probably better.
Hmm, only thing I don't like about preserving the libs is that some people will have them and some won't. For example, they are gone now on my sys, so I will not get them back by re-installing freebsd-lib... So freebsd-lib is not then as consistent machine to machine. Also, the latest patch doesn't build libc_r, but it also does not link it to libthr. Did you intend to get rid of it completely? That might be OK (it's not in 7.0-CURRENT at all anyway)... Created attachment 132001 [details, diff]
freebsd-lib-6.2-r2.ebuild
Roy, what do you think of this patch?
In portage now, hope we haven't broken too much! |