Latest Bugs & Tasks

Syndicate content Haiku
Trac Timeline
Updated: 1 hour 12 min ago

Ticket #10655 (Jam help target does not contain info on how to build haiku targets with ...) closed

Mon, 2014-03-10 07:24
fixed:

Applied in hrev47003. There were some indentation problems, and some lines were still too long, but I fixed them myself.

Categories: Development

Ticket #7916 (C++11 thread support is broken.) closed

Mon, 2014-03-10 07:15
fixed:

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...)

Categories: Development

Ticket #10628 (KDL: assert failed in scheduler code) closed

Sun, 2014-03-09 20:37
fixed:

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.

Categories: Development

Ticket #10659 (Handle gcc 4.8.1's DWARF output) closed

Sun, 2014-03-09 14:15
fixed:

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.

Categories: Development

Ticket #10661 (Deskbar crash killing unresponsive Terminal) created

Sun, 2014-03-09 00:27

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.

Categories: Development

Ticket #10660 (Intel i965Q resolution) created

Sat, 2014-03-08 20:11

I have a Dell Optiplex 745 with an integrated Intel i965Q (82Q963/Q965 Integrated Graphics Controller)
device/type 0x3
device/subtype 0x0
device/interface 0x0
device/vendor 0x8086
device/id 0x2992

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.

Categories: Development

Ticket #10659 (Handle gcc 4.8.1's DWARF output) created

Sat, 2014-03-08 15:29

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.

Categories: Development

Ticket #10658 (spam) closed

Sat, 2014-03-08 09:58
junk
Categories: Development

Ticket #10657 (spam) closed

Sat, 2014-03-08 09:57
junk
Categories: Development

Ticket #10658 (spam) created

Sat, 2014-03-08 09:32

spam

Categories: Development

Ticket #10657 (spam) created

Sat, 2014-03-08 09:26

spam

Categories: Development

Ticket #10065 (Jam clean fails) reopened

Sat, 2014-03-08 04:38

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_