Opened 5 years ago

Closed 4 years ago

Last modified 4 years ago

#11187 closed bug (no change required)

Problem running gcc4 app in a gcc2 hybrid.

Reported by: modeenf Owned by: nobody
Priority: normal Milestone: R1
Component: - General Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by modeenf)

I can't run an application that I built on the same system. It complains that it can't find libstdc++.so.6 so I'm thinking that running plain app and from a package both run it in gcc2 mode that don't have libstdc++.so.6.

Attachments (1)

strace.txt (124.6 KB) - added by modeenf 5 years ago.
the result of a strace -l

Download all attachments as: .zip

Change History (9)

comment:1 Changed 5 years ago by modeenf

Description: modified (diff)

comment:2 Changed 5 years ago by modeenf

From a mail from Ingo Please verify

  • that libstdc++.so.6 is in /system/lib/x86 (and isn't just a dead symlink),
  • that /system/lib (or /boot/system/lib) is in LIBRARY_PATH,
  • that the application you are launching is indeed marked with gcc 2 ABI.

The latter can be done with objdump. Enter objdump -D /path/to/app (pipe to less or a file, if you like) and find the definition of symbol _gSharedObjectHaikuABI (there's probably only one occurrence anyway). It should look like:

00068028 <_gSharedObjectHaikuABI>:

68028: 00 00 add %al,(%eax) 6802a: 04 00 add $0x0,%al

The addresses (first column) may differ. The disassembly in the right column is irrelevant (it's a data symbol, not code). The hex dump in the middle column is the interesting info. "00 00 04 00" means it's gcc 4 ABI, "02 00 02 00" would be gcc 2. It's 04 00 so that looks ok.

If the symbol value is correct, the runtime loader should be able to correctly identify the executable's ABI. If LIBRARY_PATH is correct, it should search the libraries in the correct subdirectories. And if the library is in the correct directory, it should be found.

If everything looks good and the application still cannot be started, please run it with "strace -l" and put the output someplace we can look at it.

CU, Ingo

Changed 5 years ago by modeenf

Attachment: strace.txt added

the result of a strace -l

comment:3 Changed 4 years ago by korli

modeenf, is there any actual errors with this run of strace? Because I couldn't find any.

comment:4 Changed 4 years ago by modeenf

The problem I had was that the I would start a program that was built from my system in the same system but got a libstdc++.so.6 not found. Now I don't realy recal what program I was working with.. Nice that I wrote that ;)

We can close this for now. If I get it again I will make a new ticet :)

comment:5 Changed 4 years ago by modeenf

Resolution: no change required
Status: newclosed

comment:6 Changed 4 years ago by pulkomandy

From the strace it looks like it was vmware guest add-on, which is known to be tricky to build, as it needs both a deskbar addon (should be gcc2) and the vmware libs (which build only with gcc4).

comment:7 Changed 4 years ago by diver

Hmm, are you sure? VMware add-ons compile fine on gcc2, the same goes for virtualbox guest additions.

comment:8 Changed 4 years ago by pulkomandy

Maybe it was fixed since then (I think mmu_man worked on this).

Note: See TracTickets for help on using tickets.