How to compile a program for different target machine than host machine?
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How to compile a program for different target machine than host machine?
At work, we have a project that compiles and runs on Debian Jessie. Typically, we use build servers for compiling, but I would like to move compilation to my own Linux box. I have tried to compile the program on Mint Sarah and Debian Stretch with no luck. I have tried installing Jessie, but the drivers are too out-of-date for my Linux box.
I can compile on Stretch, but won't run on the target machines because the shared library versions don't match. When I match library versions in Sarah and Stretch to the ones in Jessie I get linking errors.
So, can I compile a program for Debian Jessie on another Debian variant with newer libraries? I am coming to the conclusion that it is not. I am looking at using a VM, but if I go that route I want something that is light weight and preferably using only the command line. Any suggestions?
Distribution: Mainly Devuan, antiX, & Void, with Tiny Core, Fatdog, & BSD thrown in.
Posts: 5,510
Rep:
Cross compiling, or is it just another version of Linux, use an older version of gcc possibly?
Install the same version of the target machine in a VM & compile it in there?
The reason why you have build servers is that they are configured to compile for the exact outcome desired.
Ask the persons who set up the build servers to help you with this. It's not that you haven't given us enough information (you haven't), but it is also that you cannot give us enough information. I feel there are things which you do not fully know about how those build servers are configured.
Sorry for the shotgun approach. The following are packages on the build servers. I have installed these on my Debian Stretch (matching versions):
gsoap=2.8.17-1
g++=4:4.9.2-2
libboost-dev=1.55.0.2
libstdc++-4.9-dev
libssl-dev=1.0.1t-1+deb8u6
libpcap-dev=1.6.2-2
libmysql++-dev=3.2.1+pristine-1
libxerces-c-dev=3.1.1-5.1+deb8u3
xsdcxx=4.0.0-1
libxerces-c3.1=3.1.1-5.1+deb8u3
When I try to link the program "foo" together, I get the following errors:
Code:
g++ -ggdb -DWITH_OPENSSL -std=c++11 -O3 ../build/obj/Foo.o -L../build/obj/ -L/home/josarlo84/.local/lib -lpthread -lssl -lcrypto -lgsoapssl++ -lmysqlclient -lboost_thread -lboost_system -lpcap -lboost_date_time -lboost_filesystem -lboost_regex -lxerces-c ../build/obj/foo_api.a ../build/obj/shared_api.a -o ../build/Foo
../build/obj/foo_api.a(FooApiHandler.o): In function `boost::cpp_regex_traits<char>::transform_primary(char const*, char const*) const':
/home/josarlo84/.local/include/boost/regex/v4/cpp_regex_traits.hpp:923: undefined reference to `boost::re_detail::cpp_regex_traits_implementation<char>::transform_primary(char const*, char const*) const'
../build/obj/foo_api.a(FooApiHandler.o): In function `boost::cpp_regex_traits<char>::transform(char const*, char const*) const':
/home/josarlo84/.local/include/boost/regex/v4/cpp_regex_traits.hpp:919: undefined reference to `boost::re_detail::cpp_regex_traits_implementation<char>::transform(char const*, char const*) const'
../build/obj/foo_api.a(FooApiHandler.o): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match_prefix()':
/home/josarlo84/.local/include/boost/regex/v4/perl_matcher_common.hpp:333: undefined reference to `boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >::maybe_assign(boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > > const&)'
../build/obj/foo_api.a(FooApiHandler.o): In function `perl_matcher':
/home/josarlo84/.local/include/boost/regex/v4/perl_matcher.hpp:374: undefined reference to `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::construct_init(boost::basic_regex<char, boost::regex_traits<char, boost::cpp_regex_traits<char> > > const&, boost::regex_constants::_match_flags)'
../build/obj/foo_api.a(FooApiHandler.o): In function `boost::re_detail::perl_matcher<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > >, boost::regex_traits<char, boost::cpp_regex_traits<char> > >::match_match()':
/home/josarlo84/.local/include/boost/regex/v4/perl_matcher_non_recursive.hpp:991: undefined reference to `boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > >::maybe_assign(boost::match_results<__gnu_cxx::__normal_iterator<char const*, std::string>, std::allocator<boost::sub_match<__gnu_cxx::__normal_iterator<char const*, std::string> > > > const&)'
collect2: error: ld returned 1 exit status
Makefile:50: recipe for target '../build/Foo' failed
make: *** [../build/Foo] Error 1
Boost headers and libraries and installed at /home/josarlo84/.local so as not to interfere with the boost libraries needed for Stretch. I get similar linking errors in Mint. I cannot figure out how to resolve this linking error. If it can't be resolved with my configuration, then I would want to look into a VM solution.
(You know what Gautama Buddha said: C++ leads to suffering)
Are you sure you cannot install these components from official packages instead of manually copying something into nonstandard places?
All packages are installed using aptitude with Jessie repository except for boost libraries. I manually downloaded and compiled boost because when I tried to install from apt-get Jessie and Stretch versions clashed.
The Makefiles, which I assume you have as part of the source
The environment variables established on these build servers
The specific link libraries which these build servers are using for these builds. It's not about mimicking the installed applications or libraries from the build server, but mimicking the libraries which are being used specifically for these builds
The Makefiles, which I assume you have as part of the source
Correct, I have those as apart of source
Quote:
The environment variables established on these build servers
How can I tell which environment variables are being used?
Quote:
The specific link libraries which these build servers are using for these builds. It's not about mimicking the installed applications or libraries from the build server, but mimicking the libraries which are being used specifically for these builds
I can get Foo to compile and link, however, when I run it on the target machines it attempts to access the wrong version of shared libraries. The list I posted is from that trial and error -- build, run, identify mismatched library, install missing library version, repeat. The last mismatched library was libstdc++.so.6. The errors I got was GLIBCXX_3.4.21 not found: required by ./Foo, and GLIBCXX_3.4.22 not found: required by ./Foo.
After downgrading g++ from 4.6 to 4.4, to match the build servers, I get the linking errors described above.
How can I tell which environment variables are being used?
This is the part where I told you to speak to your build system administrators. Remember, when you install tools, there's usually a README that tells you what environment variables those tools require. So ... you can either continue to hunt and peck at it, or you can look it up/ask. Is there a problem asking?
Quote:
Originally Posted by josarlo84
I can get Foo to compile and link, however, when I run it on the target machines it attempts to access the wrong version of shared libraries. The list I posted is from that trial and error -- build, run, identify mismatched library, install missing library version, repeat. The last mismatched library was libstdc++.so.6. The errors I got was GLIBCXX_3.4.21 not found: required by ./Foo, and GLIBCXX_3.4.22 not found: required by ./Foo.
After downgrading g++ from 4.6 to 4.4, to match the build servers, I get the linking errors described above.
You can likely get anything to "compile", as well as "link" using the proper libraries.
HOWEVER, as you're saying, they won't properly run on the target.
Now ... this target is either matching the CPU from where you're compiling, or it is entirely different. Once again, we don't know if this is cross compilation, or something else.
Just because you link something successfully only means that you satisfied the library requirements on the build machine you're using. However if those linked-to libraries are not matching the ones on the target environment, then they won't work.
@OP: I cannot follow you. If you want to use the program on computer X, then compile it from source on computer X. That's how things work in Unix (unlike Windows, for example.)
Forget distribution, you've already described this.
What are the hardware specifications for your build machine? The one you are using.
What are the hardware specifications for your target?
Both the target and the host have the same hardware architecture. I can (and have) installed Debian Jessie on my host machine and can build and run Foo using Jessie packages installed with aptitude. I only have problems when I upgrade to Stretch or Mint.
Quote:
Originally Posted by rtmistler
This is the part where I told you to speak to your build system administrators. Remember, when you install tools, there's usually a README that tells you what environment variables those tools require. So ... you can either continue to hunt and peck at it, or you can look it up/ask. Is there a problem asking?You can likely get anything to "compile", as well as "link" using the proper libraries.
The system administrator told me that I just needed to match package versions.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
.
