Still cannot cross-build boost libs
I am trying to use linux-x86 platform to cross-build for linux-ppc. I have followed Vladimir’s suggestion to specify my cross-compiler/archiver by updating user-config.jam with: using gcc : : /path/to/my/linux-ppc-g++ : <archiver>/path/to/my/linux-ppc-ar ; I have confirmed this works IF I build one of the [header-only] example programs. This proves that user-config.jam (located in my home directory) is being found, and the compiler/archiver are specified correctly, since the resulting executable runs on the correct target (ppc) platform. However, when attempting to apply the same user-config.jam file to build boost/serialization, it appears my cross-compiler/archiver directives are ignored, and the resulting libraries are in the native x86 format, since attempting to build a program with one of them using my ppc-g++ compiler produces a spew of link errors. Modifying my makefile to use the native g++ compiler permits a successful linkage with the boost/serialization library, and the resulting executable runs fine on the x86 platform. The command I used to build boost/serialization is: bjam --toolset=gcc --with-serialization --prefix=/my/prefix/path --exec-prefix=/my/exec-prefix/path/linux_ppc --libdir=/my/exec-prefix/path/linux_ppc/lib install I also saved the output from the build, but can’t see any clues to explain where things went wrong. Any ideas why I seem to be so close, but still cannot produce boost library binaries for the desired target platform?
Found the cause of my previous trouble, and can now cross-build library for my target PowerPC platform. However, my attempt to build and run the serialization example program demo_xml_save.cpp resulted in a segmentation fault with the backtrace below. This effort is proving to be so problematic every step of the way, that I believe I will have to abandon my decision to use the boost library entirely, and instead implement my own clunky dump methods for every object I had hoped to serialize. Unfortunate, but I don't have time for all the nonsense. #0 0x0ff69004 in std::basic_ios<char, std::char_traits<char> >::widen(char) const () from /usr/lib/libstdc++.so.5 #1 0x0ff956f0 in std::ostream::operator<<(long)() from /usr/lib/libstdc++.so.5 #2 0x0ff95ba4 in std::ostream::operator<<(int)() from/usr/lib/libstdc++.so.5 #3 0x1000b9b8 in save<int> (this=0x7ffff480, t=@0x7ffff240) at .../include/boost-1_34_1/boost/archive/basic_text_oprimitive.hpp:84 #4 0x1000b860 in save<int> (this=0x7ffff470, t=@0x7ffff240) at .../include/boost-1_34_1/boost/archive/xml_oarchive.hpp:56 #5 0x10026ed0 in boost::archive::basic_xml_oarchive<boost::archive::xml_oarchive>:: write_attribute(char const*, int, char const*) (this=0x7ffff470, attribute_name=0x10032738 "version", t=4, conjunction=0x10032740 "=\"") at boost/archive/impl/basic_xml_oarchive.ipp:68 #6 0x10026e04 in boost::archive::basic_xml_oarchive<boost::archive::xml_oarchive>::init() (this=0x7ffff470) at boost/archive/impl/basic_xml_oarchive.ipp:218 #7 0x10026c74 in boost::archive::xml_oarchive_impl<boost::archive::xml_oarchive>:: xml_oarchive_impl(std::ostream&, unsigned) (this=0x7ffff470, os_=@0x7ffff350, flags=0) at boost/archive/impl/xml_oarchive_impl.ipp:113 #8 0x10026b94 in boost::archive::xml_oarchive_impl<boost::archive::xml_oarchive>:: xml_oarchive_impl(std::ostream&, unsigned)() at boost/archive/impl/xml_oarchive_impl.ipp:104 #9 0x100052c0 in boost::archive::xml_oarchive::xml_oarchive(std::ostream&, unsigned) (this=0x7ffff470, os=@0x7ffff350, flags=0)at .../include/boost-1_34_1/boost/archive/xml_oarchive.hpp:100 #10 0x1000417c in boost::archive::xml_oarchive::xml_oarchive(std::ostream&, unsigned) () at .../include/boost-1_34_1/boost/serialization/void_cast.hpp:169 #11 0x10001ed0 in save_schedule(bus_schedule const&, char const*) (s=@0x7ffff4e0, filename=0x1005327c "demo_save.xml") at demo_xml_save.cpp:22 #12 0x10002abc in main (argc=1, argv=0x7ffff724) at demo_xml_save.cpp:86
Bruce Reid wrote:
Found the cause of my previous trouble, and can now cross-build library for my target PowerPC platform.
What was the cause?
However, my attempt to build and run the serialization example program demo_xml_save.cpp resulted in a segmentation fault with the backtrace below.
This effort is proving to be so problematic every step of the way, that I believe I will have to abandon my decision to use the boost library entirely, and instead implement my own clunky dump methods for every object I had hoped to serialize. Unfortunate, but I don't have time for all the nonsense.
#0 0x0ff69004 in std::basic_ios<char, std::char_traits<char> #>::widen(char) const () from /usr/lib/libstdc++.so.5 #1 0x0ff956f0 in std::ostream::operator<<(long)() from #/usr/lib/libstdc++.so.5 #2 0x0ff95ba4 in std::ostream::operator<<(int)() #from/usr/lib/libstdc++.so.5
Weird. Are you sure the version of libstdc++ on the PowerPC system where you run this is the same as included with your cross-compiler? - Volodya
Vladimir Prus <ghost <at> cs.msu.su> writes:
Bruce Reid wrote:
Found the cause of my previous trouble, and can now cross-build library for my target PowerPC platform.
What was the cause?
My operator error. The makefile was pointing to libraries built from a previous failed attempt, and after successfully cross-building them in a different location, I forgot to update the makefile.
However, my attempt to build and run the serialization example program demo_xml_save.cpp resulted in a segmentation fault with the backtrace below.
#0 0x0ff69004 in std::basic_ios<char, std::char_traits<char> #>::widen(char) const () from /usr/lib/libstdc++.so.5 #1 0x0ff956f0 in std::ostream::operator<<(long)() from #/usr/lib/libstdc++.so.5 #2 0x0ff95ba4 in std::ostream::operator<<(int)() #from/usr/lib/libstdc++.so.5
Weird. Are you sure the version of libstdc++ on the PowerPC system where you run this is the same as included with your cross-compiler?
A large amount of software has been built for this embedded PowerPC application using the same set of tools without any libstdc++ compatibility issues, so I'm fairly confident the problem lies elsewhere, though I don't have a clue where, and can't afford any more time spent on this approach.
- Volodya
Hi! Bruce Reid schrieb:
This effort is proving to be so problematic every step of the way, that I believe I will have to abandon my decision to use the boost library entirely, and instead implement my own clunky dump methods for every object I had hoped to serialize. Unfortunate, but I don't have time for all the nonsense.
What a pity. I guess you cannot get hold of a ppc to do a native build, can you? Cross compilation has always been difficult. It's not related to boost. Frank
Frank Birbacher <bloodymir.crap <at> gmx.net> writes:
Hi!
Bruce Reid schrieb:
This effort is proving to be so problematic every step of the way, that I believe I will have to abandon my decision to use the boost library entirely, and instead implement my own clunky dump methods for every object I had hoped to serialize. Unfortunate, but I don't have time for all the nonsense.
What a pity. I guess you cannot get hold of a ppc to do a native build, can you? Cross compilation has always been difficult. It's not related to boost.
Frank
Hi Frank, Yes, it is regrettable, but unfortunately, building with native tools is not an option for this application. Bruce
Bruce Reid wrote:
Yes, it is regrettable, but unfortunately, building with native tools is not an option for this application.
Instead of asking bjam to build it for you, why don't you use your own build system? It would be much less headache in this case. There isn't really much that isn't transferable (besides the conciseness.)
Sohail Somani <s.somani <at> fincad.com> writes:
Bruce Reid wrote:
Yes, it is regrettable, but unfortunately, building with native tools is not an option for this application.
Instead of asking bjam to build it for you, why don't you use your own build system? It would be much less headache in this case. There isn't really much that isn't transferable (besides the conciseness.)
Hi, and thank you for this suggestion. I have had no prior experience with the Boost tools, and until this recent attempt to use the serialization lib, had never before heard of bjam, 'build systems', etc. I'm an old-fashioned makefile kind of guy; I might have some hope of succeeding with this effort if I were dealing with a familiar environment like that. My management has encouraged and agreed with the decision to abandon my attempt to apply a third-party tool to this project. With that, and due to time constraints, I have moved on. If I should have occasion to try again in the future, and have the luxury of sufficient time to embark on the research needed to understand what you mean by a 'Build System', then I'll be more fortunate than I am currently. Thanks again for the suggestion, Bruce
Bruce Reid wrote:
Sohail Somani <s.somani <at> fincad.com> writes:
Instead of asking bjam to build it for you, why don't you use your own build system? It would be much less headache in this case. There isn't really much that isn't transferable (besides the conciseness.)
Hi, and thank you for this suggestion. I have had no prior experience with the Boost tools, and until this recent attempt to use the serialization lib, had never before heard of bjam, 'build systems', etc. I'm an old-fashioned makefile kind of guy; I might have some hope of succeeding with this effort if I were dealing with a familiar environment like that.
My management has encouraged and agreed with the decision to abandon my attempt to apply a third-party tool to this project. With that, and due to time constraints, I have moved on. If I should have occasion to try again in the future, and have the luxury of sufficient time to embark on the research needed to understand what you mean by a 'Build System', then I'll be more fortunate than I am currently.
You're welcome. Though it sounds like a case of NiH to me ;-) Best of luck. Sohail
Hi! Bruce Reid schrieb:
Hi, and thank you for this suggestion. I have had no prior experience with the Boost tools, and until this recent attempt to use the serialization lib, had never before heard of bjam, 'build systems', etc. I'm an old-fashioned makefile kind of guy; I might have some hope of succeeding with this effort if I were dealing with a familiar environment like that.
My first approach using boost was to copy the source files into my project and just compile them like my other sources, too. This way they where compiled using the same compiler and same options as the rest of the program. I've done this until I got familiar with bjam. :) Frank
Hello Bruce! I cannot say if things got easier with bjam-v.2 but using v.1 I had lots of troubles cross-compiling. Although it is possible to specify the compiler name and include-directories directly the same is not true for the minor tools involved in the linking process. The solution I came up with was to create a directory containing default named links (like g++, ld, ar, objcopy) to my ppc-binaries (ppc_6xx-g++, ppc_6xx-ld, ppc_6xx-ar, ppc_6xx-objcopy) and include that directory into the path before system's native binaries. Even if this solution works I do not like it and would appreciate if some of the experts could point out the proper way to do it. I am aware I could write my own toolset and I was told to do so before but I find it very hard to deal with the internals and see no real need since I am using a gcc. Christian Pfligersdorffer PS: The first thing to do is examine the object files and shared libraries using the 'file'-command. It tells you which architecture the files are compiled for and thus you may tell what part of your tool chain is failing. boost-users-bounces@lists.boost.org wrote:
I am trying to use linux-x86 platform to cross-build for linux-ppc. I have followed Vladimir's suggestion to specify my cross-compiler/archiver by updating user-config.jam with:
using gcc : : /path/to/my/linux-ppc-g++ : <archiver>/path/to/my/linux-ppc-ar ;
I have confirmed this works IF I build one of the [header-only] example programs. This proves that user-config.jam (located in my home directory) is being found, and the compiler/archiver are specified correctly, since the resulting executable runs on the correct target (ppc) platform.
However, when attempting to apply the same user-config.jam file to build boost/serialization, it appears my cross-compiler/archiver directives are ignored, and the resulting libraries are in the native x86 format, since attempting to build a program with one of them using my ppc-g++ compiler produces a spew of link errors. Modifying my makefile to use the native g++ compiler permits a successful linkage with the boost/serialization library, and the resulting executable runs fine on the x86 platform.
The command I used to build boost/serialization is:
bjam --toolset=gcc --with-serialization --prefix=/my/prefix/path --exec-prefix=/my/exec-prefix/path/linux_ppc --libdir=/my/exec-prefix/path/linux_ppc/lib install
I also saved the output from the build, but can't see any clues to explain where things went wrong. Any ideas why I seem to be so close, but still cannot produce boost library binaries for the desired target platform?
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Bruce Reid -
Frank Birbacher -
Pfligersdorffer, Christian -
Sohail Somani -
Vladimir Prus