Opened 11 years ago

Closed 11 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 by stippi, 11 years ago

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 by monni, 11 years ago

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 by stippi, 11 years ago

Ah, ok then. Not invalid. :-)

comment:4 by mt, 11 years ago

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 by anevilyak, 11 years ago

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 by monni, 11 years ago

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 by monni, 11 years ago

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 by anevilyak, 11 years ago

Owner: changed from axeld to bonefish

Ingo, any ideas?

in reply to:  8 comment:9 by bonefish, 11 years ago

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.