can't resolve symbols: Buildroot library mismatch

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey all,

I'm hoping someone a bit more familiar with buildroot and/or standard Linux Environment variables than myself can answer a question.

I'm running a fairly standard buildroot-generated rootfs. I haven't altered the core in any way, just plonked some more apps on top.

If I compile something outside the buildroot tree but using the buildroot-built toolchain, running the app always starts with a list of unresolved symbols. EG I just built php using the buildroot toolchain, now:

-sh-3.2# php --version
php: can't resolve symbol 'mblen'
php: can't resolve symbol '__avr32_s32_to_f32'
PHP 5.1.6 (cgi-fcgi) (built: Feb 18 2008 12:09:29)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies

To access the buildroot toolchain I just have the staging_dir/bin at the head of my PATH. So; I'm using the buildroot toolchain, buildroot libraries on target, what more do I have to do to get them to actually match up nice?

As an aside, compiling PHP with same config as above, just using the current Atmel-supplied openSUSE toolchain results in the less satisfactory output

-sh-3.2# php --version
php: can't resolve symbol 'mblen'
php: can't resolve symbol '__avr32_s32_to_f32'
Segmentation Fault

So it would seem that the openSUSE toolchain is fairly Ronnied at the moment.

Thx,
-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Alright so I uninstalled anything which comes in an RPM as indeed even with the buildroot-built compiler it was still using the rpm'd libraries. So cool, it /seems/ I now can build new executables which don't refer to undefined symbols. But what I have on my hands are all the libraries I've compiled in the last few months (and there's a bunch of them) which still themselves have references to, eg, __avr32_s32_to_f32.

Now please oh clever masses, please don't tell me I have to recompile all my everythingness. Anyone?

Thx,
-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You have to recompile everything against your new uClibc and header files ;)

What I do, and happens to work for me, is to "export PATH=/path/to/buildroot/staging_dir/bin:$PATH". And then go about compiling stuff outside Buildroot.

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's precisely what I have done. But all libraries I've compiled over the last few months, before doing that, now have to be recompiled? Can I force buildroot to bake me a library from which all my cruft can resolve it's symbols? Pweese? O_O

And if I can't and these functions are no longer implemented in the c library then surely the library interface has changed so why isn't my library loader bitching about version magic?

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

uClibc version in Buildroot is 0.9.29 and in the .rpm's are 0.9.28.something. The .config is also a bit different. AFAIK work is ongoing to get the .rpm's and .deb's up to speed with latest uClibc (0.9.29).

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hce wrote:
uClibc version in Buildroot is 0.9.29 and in the .rpm's are 0.9.28.something. The .config is also a bit different.
Sorry to labour the point, but is there a config option I can use for uClibc 0.9.29 which will supply the needed symbols and unbreak everything I've built in the last ages? I mean, when if I were to "apt-get upgrade libc6" I won't break every binary and library on my system (though sure I might break the occasional one for various buggy reasons). To me that kinda seems what's analogous to happening here. Not to worry, I guess I'll just bite the bullet and rebuild everything. Or better, glue them in to buildroot.
hce wrote:
AFAIK work is ongoing to get the .rpm's and .deb's up to speed with latest uClibc (0.9.29).
Cool. And hopefully work to stop the resulting binaries segfaulting incorrectly too ;-).

As an aside, does anyone have a procedure for disassembling a binary and matching the instructions therein with the dmesg output which reports something like "Segmentation fault PC=0xdeadbeef"?

Thx,
-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Sorry to labour the point, but is there a config option I can use for uClibc 0.9.29 which will supply the needed symbols and unbreak everything I've built in the last ages?

Your best call is to change the target/device/Atmel/uClibc.config.avr32 to match the one used in the .rpm's.

Quote:
I mean, when if I were to "apt-get upgrade libc6" I won't break every binary and library on my system (though sure I might break the occasional one for various buggy reasons).

You have never experienced a ABI change in the libc for you disto, lucky you ;)

Quote:
As an aside, does anyone have a procedure for disassembling a binary and matching the instructions therein with the dmesg output which reports something like "Segmentation fault PC=0xdeadbeef"?

I usually increase the core dump size (ulimit -c 1000000), and backtrace the core dump on my build computer. That is the nifty with Buildroot, all the libraries are properly built and installed into staging dir.

Very short howto to backtrace a core dump:

avr32-linux-gdb /path/to/your/application/which/crashed
set solib-absolute-prefix /path/to/buildroot/staging_dir
core-file /path/to/crashed/application/core/file
backtrace

Hans-Christian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
I mean, when if I were to "apt-get upgrade libc6" I won't break every binary and library on my system (though sure I might break the occasional one for various buggy reasons).

Unfortunately, glibc and uClibc have a different philosophy with regards to backwards compatibility. While glibc tries to ensure binary compatibility between different versions, uClibc will easily sacrifice binary compatibility if there are a few bytes to be saved. At least that's my understanding. uClibc 0.9.29 isn't binary-compatible with 0.9.28, and the developers are completely aware of this.

And I think the uClibc philosophy is actually what you want on most embedded systems -- the library is small, keeping the flash, RAM and cache footprint down, and when the time comes, you upgrade the whole system at once, not one library at a time.

hce wrote:
I usually increase the core dump size (ulimit -c 1000000), and backtrace the core dump on my build computer. That is the nifty with Buildroot, all the libraries are properly built and installed into staging dir.

Is there a way you can keep unstripped binaries around too? Even if the binaries installed on the target are stripped, gdb is happy if you give it an unstripped binary instead.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hce wrote:
Quote:
I mean, when if I were to "apt-get upgrade libc6" I won't break every binary and library on my system (though sure I might break the occasional one for various buggy reasons).

You have never experienced a ABI change in the libc for you disto, lucky you ;)
Indeed I have not. And if I ever do that distro will be put straight in Benny's Big Black distro Bin. At the moment all that's in there is Ubuntu for shipping 7.10 without an ATI driver which supports Xinerama and no alternatives for my hardware :twisted:
hce wrote:
I usually increase the core dump size (ulimit -c 1000000), and backtrace the core dump on my build computer. That is the nifty with Buildroot, all the libraries are properly built and installed into staging dir.
Cheers, I'll see if I can find out why the openSUSE toolchain builds incorrect binaries and whether it's likely to affect other builds :-)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how wrote:
squidgit wrote:
I mean, when if I were to "apt-get upgrade libc6" I won't break every binary and library on my system (though sure I might break the occasional one for various buggy reasons).

Unfortunately, glibc and uClibc have a different philosophy with regards to backwards compatibility. While glibc tries to ensure binary compatibility between different versions, uClibc will easily sacrifice binary compatibility if there are a few bytes to be saved. At least that's my understanding. uClibc 0.9.29 isn't binary-compatible with 0.9.28, and the developers are completely aware of this.
Fair enough, and now I am too!

You know, each time I run in to a problem like this I gain a little more respect for M$. I love the fact that the EXE file format is actually a completely valid COM executable too but the COM program bundled inside each and every EXE just prints that "This program requires Microsoft Windows" message.

Of course this overhead is unacceptable in an embedded environment but it still amuses me :-D

how wrote:
And I think the uClibc philosophy is actually what you want on most embedded systems -- the library is small, keeping the flash, RAM and cache footprint down, and when the time comes, you upgrade the whole system at once, not one library at a time.
Yeah, seems fair enough. I'd still appreciate a version magic complaint rather than just failing to resolve symbols but you get what you get :-)

Putting everything I need to compile ever in Buildroot and rebuilding at every lib version change is making more and more sense.

-S.