elf_resolve_symbol: could not resolve symbol '_ZNK9BTextView7ArchiveEP8BMessageb'

[monni]

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

[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?

[monni]

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

[stippi]

Ah, ok then. Not invalid. :-)

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

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

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

[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

[anevilyak]

Ingo, any ideas?

[bonefish]

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.