In article [EMAIL PROTECTED], Jim Bloom [EMAIL PROTECTED] wrote:
[when dllockinit() should be called]
It should be called somewhere between the starting of the process
and the creation of the second thread. There is no problem if there
is only one thread.
THREAD Create would be fine as
The other possibility would be to fix the wine port so it calls
dllockinit() to set up locking. I don't know for sure how hard that
would be, but it's probably a feasible solution.
To be honest, I'd be the most comfortable with this solution but also
trust John's skills with the linker
In article [EMAIL PROTECTED],
Jordan K. Hubbard [EMAIL PROTECTED] wrote:
The other possibility would be to fix the wine port so it calls
dllockinit() to set up locking. I don't know for sure how hard that
would be, but it's probably a feasible solution.
To be honest, I'd be the most
In article [EMAIL PROTECTED] you write:
In article [EMAIL PROTECTED],
Jordan K. Hubbard [EMAIL PROTECTED] wrote:
The other possibility would be to fix the wine port so it calls
dllockinit() to set up locking. I don't know for sure how hard that
would be, but it's probably a feasible
NOTE: Take everything I say here as general info. I haven't used these thread
packages, but have used others in the past.
It should be called somewhere between the starting of the process and the
creation of the second thread. There is no problem if there is only one thread.
THREAD Create
In article [EMAIL PROTECTED],
Donn Miller [EMAIL PROTECTED] wrote:
John Polstra wrote:
Below is a patch for "src/libexec/rtld-elf" which should fix the
assert failures in wine. I'd appreciate hearing from anybody who
tests this with multithreaded packages such as wine, JDK, Mozilla,
John Polstra wrote:
In article [EMAIL PROTECTED],
Donn Miller wrote:
OK, here's some of the errors I get with Mozilla. It looks like it
happens when Gdk runs out os SysV shared memory. Otherwise, if I
don't get the "Gdk-WARNING **: shmget failed!", the ld.so erros never
occur,
In article [EMAIL PROTECTED],
Donn Miller [EMAIL PROTECTED] wrote:
I just reverted back to the "normal" version of ld-elf.so, the version
without the patch. Mozilla doesn't have the problem with the
"non-patch" version. So, maybe it isn't the application. Or, maybe the
original,
John Polstra wrote:
Below is a patch for "src/libexec/rtld-elf" which should fix the
assert failures in wine. I'd appreciate hearing from anybody who
tests this with multithreaded packages such as wine, JDK, Mozilla,
and linuxthreads.
[snipped patch]
OK, here's some of the errors I get
Below is a patch for "src/libexec/rtld-elf" which should fix the
assert failures in wine. I'd appreciate hearing from anybody who
tests this with multithreaded packages such as wine, JDK, Mozilla,
and linuxthreads.
Just a reminder -- be extra careful when messing with the dynamic
linker. It's
In article [EMAIL PROTECTED],
Donn Miller [EMAIL PROTECTED] wrote:
This time it happens with a recent cvs version of wine (about 1 week
old).
$ wine -desktop 780x560 ./iew31.exe
Could not stat /mnt/fd0, ignoring drive A:
ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:54
John Polstra wrote:
In article [EMAIL PROTECTED],
Donn Miller [EMAIL PROTECTED] wrote:
This time it happens with a recent cvs version of wine (about 1 week
old).
$ wine -desktop 780x560 ./iew31.exe
Could not stat /mnt/fd0, ignoring drive A:
ld-elf.so.1: assert failed:
In article [EMAIL PROTECTED],
Donn Miller [EMAIL PROTECTED] wrote:
Here's the backtrace from gdb:
(gdb) backtrace
#0 0x2805ce30 in kill () from /usr/libexec/ld-elf.so.1
#1 0x2805ca0d in abort () from /usr/libexec/ld-elf.so.1
#2 0x28053c6e in lockdflt_acquire () from
This time it happens with a recent cvs version of wine (about 1 week
old).
$ wine -desktop 780x560 ./iew31.exe
Could not stat /mnt/fd0, ignoring drive A:
ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/lockdflt.c:54
wine: can't exec './iew31.exe': invalid exe file
Terminated
My version
14 matches
Mail list logo
