Latest Bugs & Tasks
Applied in hrev47003. There were some indentation problems, and some lines were still too long, but I fixed them myself.
In hrev47000 I modified our pthread_equal to compare two NULL thread ids equal. This solves my issue. The initial problem is gone too, as compiling the program works, and it even runs without crashing (wether it makes sense or not is another problem...)
Should be fixed in hrev46999. Being caused by a race condition this assertion fail probably was not easy to reproduce (and verify that it is indeed fixed) so I am closing this ticket now, reopen if needed.
Fixed .debug_types handling in hrev46998. Hypothetically our gcc could still be configured to pass -fdebug-types-section by default, but that isn't a hurdle for this ticket.
Applied in hrev46995, thanks!
I had two Terminal windows open, and one of them (not sure about the other, now) for some reason would no longer respond to keypresses, even though it was just sitting at the bash prompt. No CPU peg or anything like that. Anyway, I held down the special keys and clicked Terminal in the Deskbar, at which point Deskbar crashed. Attached is the crash report. hrev46922.
Fixed in hrev46994.
I have a Dell Optiplex 745 with an integrated Intel i965Q (82Q963/Q965 Integrated Graphics Controller)
I cant set a native resolution, if i boot up first time, i have to use Failsafe Videomode with, lets say 1024x768, after that i can start without using it, but iam bound to 1024x768. If i want to change to 1440x900 i get a very strange output. (This "trick" works with any VESA resolution). The TFT is connected per VGA.
Along with its switch over to DWARF 4 by default, gcc 4.8.1 has started generating info entries corresponding to rvalue reference types, which we don't currently handle. This needs to be addressed.
Furthermore, it seems it's generating DWARF 4 output without generating a separate debug_types section, which the current implementation did not anticipate. Needs further investigation.
Fixed in hrev46989.
This is actually still an issue. (one I see quite often)
The issue is due to the lack of a libroot_build.so and the usage of rm_attrs to erase files on clean. There is a situation that can exist where libroot_build.so is missing, thus rm_attrs fails to execute...
Clean clean Clean clean /home/kallisti5/Code/haiku/generated.arm/objects/linux/x86_64/release/tools/rm_attrs: error while loading shared libraries: libroot_build.so: cannot open shared object file: No such file or directory export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/kallisti5/Code/haiku/generated.arm/objects/linux/lib ; /home/kallisti5/Code/haiku/build/scripts/rm_attrs /home/kallisti5/Code/haiku/generated.arm/objects/linux/x86_64/release/tools/rm_attrs -f "/home/kallisti5/Code/haiku/generated.arm/objects/haiku/arm/release/system/libroot/posix/string/bzero.o" "/home/kallisti5/Code/haiku/generated.arm/objects/haiku/arm/release/system/libroot/posix/string/ffs.o" "/home/kallisti5/Code/haiku/generated.arm/objects/haiku/arm/release/system/libroot/posix/string/memccpy.o" "/home/kallisti5/Code/haiku/generated.arm/objects/haiku/arm/release/system/libroot/posix/string/memchr.o"...
I think the solution is to check for the existence of generated.arm/objects/linux/lib/libroot_build.so before attempting to use rm_attrs. Maybe if libroot_build.so is missing, the clean will attempt to build it.. or just fall back to rm vs rm_attrs.
The change needs to occur in build/jam/BuildSetup ~line 530.
We know the directory where libroot_build.so *should* be (HOST_