Opened 8 years ago

Closed 8 years ago

Last modified 7 years ago

#12592 closed bug (no change required)

yab no longetr runs or compiles ... regression

Reported by: bbjimmy Owned by: waddlesplash
Priority: normal Milestone: Unscheduled
Component: Kits/Interface Kit Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

I updated to hrev 50032

type yab in a terminal:

runtime_loader: /boot/home/config/non-packaged/lib/libyab.so: Could not resolve symbol 'DrawLabelQ28BPrivate12BControlLookP5BViewPCcG5BRectRC5BRectRC9rgb_colorUlRC10BAlignment' resolve symbol "DrawLabelQ28BPrivate12BControlLookP5BViewPCcG5BRectRC5BRectRC9rgb_colorUlRC10BAlignment" returned: -2147478780 runtime_loader: /boot/home/config/non-packaged/lib/libyab.so: Troubles relocating: Symbol not found

attempt to compile yab:

g++ -O -I. -DHAVE_CONFIG -DUNIX -DHAIKU -DLIBRARY_PATH=\"finddir B_USER_SETTINGS_DIRECTORY/yab\" -c column/ColumnListView.cpp -o column/ColumnListView.o /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColumnListView.cpp: In method `void BPrivate::TitleView::DrawTitle(BView *, BRect, BColumn *, bool)': /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColumnListView.cpp:2409: call of overloaded `mix_color (rgb_color, rgb_color, int)' is ambiguous /boot/system/develop/headers/os/interface/GraphicsDefs.h:93: candidates are: struct rgb_color mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColorTools.h:87: struct rgb_color BExperimental::mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColumnListView.cpp:2422: call of overloaded `mix_color (rgb_color, rgb_color, int)' is ambiguous /boot/system/develop/headers/os/interface/GraphicsDefs.h:93: candidates are: struct rgb_color mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColorTools.h:87: struct rgb_color BExperimental::mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColumnListView.cpp:2423: call of overloaded `mix_color (rgb_color &, rgb_color, int)' is ambiguous /boot/system/develop/headers/os/interface/GraphicsDefs.h:93: candidates are: struct rgb_color mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColorTools.h:87: struct rgb_color BExperimental::mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColumnListView.cpp:2425: call of overloaded `mix_color (rgb_color &, rgb_color, int)' is ambiguous /boot/system/develop/headers/os/interface/GraphicsDefs.h:93: candidates are: struct rgb_color mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColorTools.h:87: struct rgb_color BExperimental::mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColumnListView.cpp:2431: call of overloaded `mix_color (rgb_color &, rgb_color, int)' is ambiguous /boot/system/develop/headers/os/interface/GraphicsDefs.h:93: candidates are: struct rgb_color mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColorTools.h:87: struct rgb_color BExperimental::mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColumnListView.cpp:2432: call of overloaded `mix_color (rgb_color &, rgb_color, int)' is ambiguous /boot/system/develop/headers/os/interface/GraphicsDefs.h:93: candidates are: struct rgb_color mix_color(rgb_color, rgb_color, unsigned char) /boot/home/Desktop/GetLatest-yab/YAB/src/column/ColorTools.h:87: struct rgb_color BExperimental::mix_color(rgb_color, rgb_color, unsigned char) make: * [column/ColumnListView.o] Error 1

it seems that the ciolor updates from the loon messed with yab.

Change History (26)

comment:1 by pulkomandy, 8 years ago

Component: - GeneralKits/Interface Kit
Owner: changed from nobody to waddlesplash
Status: newassigned

Is the ColumnListView a copy of the one from Haiku? If that's the case, you could remove it from YAB sources and use the version provided by Haiku (in headers/private/interface and libcolumnlistview). That will fix the build. I wonder if we should make ColumnListView a public API, since it seems its external interface is more stable than its internals (use of BControlLook in this case).

(reassigning to waddlesplash since he merged those changes)

comment:2 by waddlesplash, 8 years ago

I haven't made any APIs public before, but I'll look into it. Makes sense to me.

comment:3 by lorglas, 8 years ago

older programs taht were tied with yab are also no longer function. Thus, it is not necessarily at the columnbox. tihs error comes at program Dateimeister:

runtime_loader: /boot/system/apps/Dateimeister/dateimeister: Could not resolve symbol 'DrawLabelQ28BPrivate12BControlLookP5BViewPCcG5BRectRC5BRectRC9rgb_colorUlRC10BAlignment' resolve symbol "DrawLabelQ28BPrivate12BControlLookP5BViewPCcG5BRectRC5BRectRC9rgb_colorUlRC10BAlignment" returned: -2147478780 runtime_loader: /boot/system/apps/Dateimeister/dateimeister: Troubles relocating: Symbol not found

comment:4 by bbjimmy, 8 years ago

It doesn't look like it is from haiku:

/* / / File: ColumnListView.cpp / / Description: Experimental multi-column list view. / / Copyright 2000+, Be Incorporated, All Rights Reserved / By Jeff Bush / */

comment:5 by pulkomandy, 8 years ago

The same comment appears here: http://cgit.haiku-os.org/haiku/tree/src/kits/interface/ColumnListView.cpp

This file probably comes from OpenTracker.

However, it does not call BControlLook::DrawLabel, so the "symbol not found" error comes from elsewhere.

comment:6 by lorglas, 8 years ago

The problem is that the Controllook from yab missing const rgbcolor* textColor in line 1684 (BControlLook::DrawLabel.

i change it to BControlLook::DrawLabel(BView* view, const char* label, BRect rect,

const BRect& updateRect, const rgb_color& base, uint32 flags, const rgb_color* textColor)

and i can compile yab. i used yab 1.7.4.5 fot this test. I think in the other yab Version it would be same problem, but the old program which are bind doesnt't. I hope it can be help.

comment:7 by bbjimmy, 8 years ago

I don't think this is the cause, I tried Lorglas' change on hrev50032 and have the same issues. On my previous install, hrev49974 it worked, but on hrev50032 the issue is the same even with this change.

comment:8 by bbjimmy, 8 years ago

My guess is the changes made in headers/os/interface/ControlLook.h, regarding DrawLabel

comment:9 by jessicah, 8 years ago

Should be able to recompile after removing the definition of mix_color in ColorTools.h (/boot/home/Desktop/GetLatest-yab/YAB/src/column/ColorTools.h:87), since it's now defined as a public function in the OS headers after looncraz's merge.

The changes to DrawLabel should be source compatible, as the newly added parameter is optional.

comment:10 by bbjimmy, 8 years ago

This works and fixes yab, but will not repair all the built / bound programs out there, or make a yab that will run on earlier versions of haiku. Are the devs content with breaking binary compatability with all the existing yab programs? It wouldn't bother me if there was a new haiku release to go with the change, but without it it makes a mess.

comment:11 by pulkomandy, 8 years ago

BControlLook is still a private API. The header clearly states "this is an experimental API and may change! Be prepared to recompile your software in a next version of Haiku." Which is just what happened here.

comment:12 by bbjimmy, 8 years ago

This issue seems to be exhibited by more than just yab and yab apps:

/boot/system/data/deskbar/menu/Applications/DocumentViewer
runtime_loader: /boot/system/apps/DocumentViewer: Could not resolve symbol '_ZN13BExperimental9mix_colorE9rgb_colorS0_h'
resolve symbol "_ZN13BExperimental9mix_colorE9rgb_colorS0_h" returned: -2147478780
runtime_loader: /boot/system/apps/DocumentViewer: Troubles relocating: Symbol not found

in reply to:  12 comment:13 by humdinger, 8 years ago

Replying to bbjimmy:

This issue seems to be exhibited by more than just yab and yab apps:

/boot/system/data/deskbar/menu/Applications/DocumentViewer

A rebuilt package was uploaded with hrev50055.

comment:14 by waddlesplash, 8 years ago

Since the packages were rebuilt, should this be closed as fixed?

comment:15 by bbjimmy, 8 years ago

yab itself now runs, but programs built/bound with older yab versions still will not run. I have no information on the number of these that may not be available in source to re-build/bind.

comment:16 by waddlesplash, 8 years ago

Resolution: no change required
Status: assignedclosed

Well, since they used a private API, that's not our problem.

Also, isn't the "binding" process rather trivial? Can't a Yab program be extracted from a bound binary?

comment:17 by lelldorin, 8 years ago

Also, isn't the "binding" process rather trivial? Can't a Yab program be extracted from a bound binary?<

And the copyright issues of these programs? I does not think that this would be the right way.

Solution to: no change required gesetzt

Status to: assigned nach closed geändert<

With closing this ticket without any changes, only to say to the people who made the yab apps to rebuild anything is not a good way, but not the first time to kill older program written for Haiku.

It is so it is, and i think this is not the last time.

I just deside to rebuild anything after a new official release of Haiku, so people who download and install haiku today can use my apps (not onlylong time haiku users).

Last edited 8 years ago by lelldorin (previous) (diff)

comment:18 by bbjimmy, 8 years ago

If it is so trivial to retrieve source code, then maybe you can help me retrieve the source code from a project of mine that I lost while updating yab? http://fatelk.com/repo/packages/beshare_info-1.0.2.0-1-x86_gcc2.hpkg

comment:19 by pulkomandy, 8 years ago

It is not exactly trivial (what about having a look before you assume it is?)

The sourcecode is not stored as plaintext in the ELF file (as strings finds). However, there is the list of yab keywords and I suspect there is a tokenized version of the source. So, it could be possible to extract that, and then rebuild the source by parsing the tokens. The extraction shouldn't be too hard:

objdump -wx program | grep myProg
# Get the start address and the size

# Compute the stop address (start + size) and ask objdump to dump the area:
objdump -sw BeShare_Info --start-address=0x013280 --stop-address=0x13BC5|less

This will get you an hex dump of the tokenized program. Then, you would need to convert it back to binary, then de-tokenize this (I'm not sure if yab provide a tool for that, but it should be possible to write one).

in reply to:  18 comment:20 by lelldorin, 8 years ago

Replying to bbjimmy:

If it is so trivial to retrieve source code, then maybe you can help me retrieve the source code from a project of mine that I lost while updating yab? http://fatelk.com/repo/packages/beshare_info-1.0.2.0-1-x86_gcc2.hpkg <

For the future here a tip to prevent data lose

http://besly.de/menu/search/archiv/dev/lelldorin-yab-script_eng.html

comment:21 by lelldorin, 8 years ago

Ok sience the latest build of yab, the coloring of buttons using the low or high (i does not remeber at the moment that i need to set) color does not run anymore.

comment:22 by bbjimmy, 8 years ago

I think what you are looking at is this: https://dev.haiku-os.org/ticket/12787

Version 0, edited 8 years ago by bbjimmy (next)

comment:23 by lelldorin, 7 years ago

Is there a way to update the yab version from the HaikuDepot? The HaikuPorts version does not run on current running haiku systems.

comment:24 by humdinger, 7 years ago

I see that in HaikuDepot yab 1.7.5.2 is available while there's a 1.7.5.3 recipe. Does that version work?
Can't wait for those buildbots... :)

comment:25 by lorglas, 7 years ago

I think it would make sense if the bug with the colored button would be solved. Furthermore, the question arises to me whether changes to the haiku api up to R1 or not. If not, you could clean up yab and enter new possibilities.

Last edited 7 years ago by lorglas (previous) (diff)

comment:26 by pulkomandy, 7 years ago

We will freeze the API for the R1 branch when we release beta 1. Until then, changes are allowed.

Note: See TracTickets for help on using tickets.