Opened 15 years ago
Closed 15 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: | ||
| 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
Change History (9)
comment:1 by , 15 years ago
comment:2 by , 15 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:4 by , 15 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 , 15 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 , 15 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 , 15 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:9 by , 15 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
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.
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?