Opened 10 years ago

Closed 10 years ago

#3402 closed bug (invalid)

elf_resolve_symbol: could not resolve symbol '_ZNK9BTextView7ArchiveEP8BMessageb'

Reported by: monni Owned by: bonefish
Priority: normal Milestone: R1
Component: System/runtime_loader Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

runtime_loader: elf_resolve_symbol: could not resolve symbol '_ZNK9BTextView7ArchiveEP8BMessageb'

resolve symbol "_ZNK9BTextView7ArchiveEP8BMessageb" returned: -2147478780

System: hrev29126 hybrid: gcc2 base, gcc4 system libraries + devkit

Application doesn't start unless /system/lib/gcc4 is linked to ./lib

http://www.raasu.org/tools/haiku/BeShare2.28-gcc4.zip

Change History (9)

comment:1 Changed 10 years ago by stippi

Haiku does not aim to be compatible with previous GCC4 packages. So BeShare needs to be rebuilt. I would mark this as invalid. Or is this a new BeShare package?

comment:2 Changed 10 years ago by monni

It's built with latest gcc4 package available for Haiku (4.3.3-haiku-090129) and it is latest BeShare version ever made.

comment:3 Changed 10 years ago by stippi

Ah, ok then. Not invalid. :-)

comment:4 Changed 10 years ago by mt

Building gcc4 BeShare in gcc2/gcc4 hybrid system?
Gcc4 apps need to link with gcc4 version of startup library (crti.o and init_term_dyn.o), but default gcc2/gcc4 hybrid mode, these libraries and other necessary parts are gcc2's. (I think /boot/develop/lib and /boot/develop/header are needed to modify, please see build/jam/OptionalPackages. )

comment:5 Changed 10 years ago by anevilyak

That's not the issue here though. Besides, building gcc4 apps under gcc2 haiku is generally not going to go well since it's not going to look in the gcc4/ subdirs when compiling/linking. Either way, this is unrelated to the startup library.

comment:6 Changed 10 years ago by monni

Compiling/Linking is not a problem under gcc2 as it can be taken care in Makefiles... adding -L/system/lib/gcc4 in LFLAGS and -lstdc++ in LIBS is enough to get a binary. Like I said in the description, it can even run the app if symlink is created as ./lib to /system/lib/gcc4... So the only problem is that runtime_loader fails to load "alternative" system libraries automagically even though it should support that.

comment:7 Changed 10 years ago by monni

Trace log:

KERN: rld: load ./BeShare-gcc4.x86
KERN: Comment 0
KERN: GCC version 4.3.3?
KERN: Comment 1
KERN: GCC version 2.95.3?
KERN: Comment 2
KERN: GCC version 2.95.3?
KERN: Comment 3
KERN: GCC version 4.3.3?
KERN: Comment 4
KERN: GCC version 4.3.3?
KERN: Comment 5
KERN: GCC version 4.3.3?
KERN: Comment 6
KERN: GCC version 4.3.3?
KERN: Comment 7
KERN: GCC version 4.3.3?
KERN: Comment 8
KERN: GCC version 4.3.3?
KERN: Comment 9
KERN: GCC version 4.3.3?
KERN: Comment 10
KERN: GCC version 4.3.3?
KERN: Comment 11
KERN: GCC version 4.3.3?
KERN: Comment 12
KERN: GCC version 4.3.3?
KERN: Comment 13
KERN: GCC version 4.3.3?
KERN: Comment 14
KERN: GCC version 4.3.3?
KERN: Comment 15
KERN: GCC version 4.3.3?
KERN: Comment 16
KERN: GCC version 4.3.3?
KERN: Comment 17
KERN: GCC version 4.3.3?
KERN: Comment 18
KERN: GCC version 4.3.3?
KERN: Comment 19
KERN: GCC version 4.3.3?
KERN: GCC version 2.95.3

comment:8 Changed 10 years ago by anevilyak

Owner: changed from axeld to bonefish

Ingo, any ideas?

comment:9 in reply to:  8 Changed 10 years ago by bonefish

Resolution: invalid
Status: newclosed

Replying to anevilyak:

Ingo, any ideas?

Absolutely! :-)

The executable has been partially compiled with gcc 2.95.3 (maybe it's just the wrong glue code?), so the runtime loader uses the gcc 2.95.3 compatible library directories.

Note: See TracTickets for help on using tickets.