Does anyone have any experience with running C++ applications that use the boost libraries on uclibc-based systems? Is it even possible? Which C++ standard library would you use? Is uclibc++ usable with boost?
A:
I have not tried but I don't know anything about uclibc that would prevent Boost from working.
Try it and see what happens, I would say.
Zan Lynx
2008-11-21 19:07:17
Boost requires a standard C++ library, if I were to try it, which C++ library would I use?
bmdhacks
2008-11-21 19:11:03
Furthermore, "trying it" is a bit of a pain for embedded systems. Are you saying I should fire up my cross-compiler and spend hours and hours trying to get boost and a c++ library working? If I hit any roadblocks, do I just spend more time with it, or do I conclude that it's doable?
bmdhacks
2008-11-21 19:21:20
Based on the amount of information in the original question, "try it" is the only answer you should expect to get."Is it possible to run KDE 4 on my computer, please answer without me providing any specs about my computer."
Max Lybbert
2008-11-21 21:44:37
That's silly. Are you saying that nobody has ever used any boost libraries on a uclibc system? I don't need an answer to any specifics, I'm just wondering if anyone has even attempted any facet of this task before wasting my time in a fruitless persuit. Why is that unreasonable?
bmdhacks
2008-11-21 22:26:46
+2
A:
We are using many of the Boost libraries (thread, filesystem, signals, function, bind, any, asio, smart_ptr, tuple) on an Arcom Vulcan which is admittedly pretty powerful for an embedded device (64M RAM, 533MHz XScale). Everything works beautifully.
GCC 3.4 but we're not using uclib++ (Arcom provides a toolchain which includes libstd++).
Many embedded devices will happily run many of the Boost libraries, assuming decent compiler support. Just take care with usage. The Boost libraries raise the level of abstraction and it can be easy to use more resources than you think.
MattyT
2008-11-21 23:21:27
Thanks for the info. Do you suspect that Arcom's libstdc++ is the GNU library? Does your system include glibc for libc?
bmdhacks
2008-11-21 23:28:44
Yeah, Arcom's libstdc++ is the GNU version. And yes, we use glibc. uclib ought to also work but we haven't (yet) gone down that path.
MattyT
2008-11-24 00:06:36
Thanks for the info, but I'm more interested in uclibc-based systems. Once you start using glibc and GNU libstdc++, you're pretty much the same as good ole RedHat on x86. It's possible that glibc and GNU libstdc++ are the only ways to use boost, but I'm hoping somebody knows if that's the case.
bmdhacks
2008-11-24 16:38:39
oops - sorry, my mouse is playing up and I docked a point. I've tried to add it on again but it won't let me set it to zero - so you are now +1 (even though you didn't actually answer the question - about using uclibc).
Dipstick
2009-02-20 19:20:48
+1
A:
I googled "uclibc stlport". It seems there are at least a few versions of uclibc for which stlport can be compiled (see this). Given that, i'd say Boost is just a few compilation steps away. I have read a message by David Abrahams (who is an active member of the boost community) that says that Boost does not depend directly on the used libc. But some libraries may still cause problems, Boost.Python for instance, since it depends on something else (Python in my example) that might be difficult to compile with uclibc.
Hope this helps
Benoît
2009-02-20 19:28:31
Thanks for the first reasonable answer. You got me half-way there, which is very helpful. I'm still holding out for somebody with practical experience or evidence of this actually being deployed, considering the large bounty I've offered.
bmdhacks
2009-02-25 16:48:12
+2
A:
We use Boost together with GCC 2.95.3, libstdc++ and STLport on an ARMv4 platform running uClinux. Some parts of Boost are not compatible with GCC 2.x but the ones that are works well in our particular case. The libraries that we use the most are *date_time*, bind, function, tuple and thread.
Some of the libraries we had issues with were lambda, *shared_pointer* and format. These issues were most likely caused by our version of GCC since it has problems when you have too many includes or deep levels of template structures.
If possible I would recommend you to run the boost test suite with your particular toolchain to ensure compatibility. At the very least you could compile a native toolchain in order to ensure that your library versions are compatible.
We have not used uClibc++ because that is not what our toolchain provider recommends so I cannot comment on that particular combination.
David Holm
2009-02-25 17:18:04
Can you clarify using both STLport and libstdc++ together? Which one does boost link to?
bmdhacks
2009-02-27 01:47:29