I recently compiled a perl script using "pp" (Perl Packager) on an x86 linux box running Manjaro. I had someone test it on their x86 Debian 10 box, but it wouldn't run.
He said that since Libperl.so has a dependence on glibc v2.29. Since his OS release only allows up to a v2.28, that it's preventing it from executing.
Is there a way for me to compile my script with my version of the libraries so it will run on any x86 linux machine?
I ran the following command to compile my code:
pp -o oag1025 oag1025.pl
I tried using some of the options outlined here, but I couldn't get anywhere:
http://perl.mines-albi.fr/perl5.8.5/site_perl/5.8.5/pp.html
I work for buildroot. My purpose work GUI on my buildroot with Gtk3.0 and Gstreamer1.0. I use Olinuxino A13 so I wrote GUI code(Gtk3.0 hello world example) on this with codeblocks. I use Debian wheezy. I want transfer this code from Debian wheezy to buildroot.
I tried this:
I transferred /path_to_proectfile/bin/Debug/my_program.my_program created by codeblocks. I wrote ./my_program on terminal and code work. I transferred this file to my buildroot but ./my_program does not work. It returns No such file or directory error.
I thought the problem might be compiling and tried compiled on terminal. I use gcc -o my_program main.c 'pkg-config --cflags --libs gtk+-3.0' again work on Debian wheezy terminal. After I transferred to buildroot but result does not change. I tried different compile kind like cc,arm-linux-gnueabi-gcc etc. but every time No such file or directory error.
Finally when I don't use gtk library(Just use printf Hello World), I saw Hello world. When I add gtk library returns No such file or directory error. Have you any suggestion?
You need to cross compile your program with the corresponding buildroot toolchain. It looks like you have transferred a binary which was built against a different libc (this gives a "No such file or directory" error).
The buildroot cross compiler with the correct libc can be used by setting CC to "path_to_buildroot_output/host/bin/arm-linux-*-gcc" (the exact name depends on which toolchain options you have chosen).
I am trying to build an operating system using Yocto and the recipe keeps flaking out on a mismatch in Perl libs:
MiscXS.c: loadable library and perl binaries are mismatched (got handshake key 0xde00080, needed 0xdb80080)
When it is building qemu.
Any idea which what this actually means? Do I need to "downgrade" the perl libs on the build host?
The build of Perl that is attempting to load the module is different than the build of Perl that installed (compiled) it.
perldiag:
(P) A dynamic loading library .so or .dll was being loaded into the
process that was built against a different build of perl than the
said library was compiled against. Reinstalling the XS module will
likely fix this error.
I was trying to build only gcc using yocto. I tried with "bitbake-layers show-recipes" it was showing multiple recipes for gcc, similarly for bitbake -s.
#bitbake-layers show-recipes
gcc:
meta 4.8.2
gcc-cross:
meta 4.8.2
gcc-cross-canadian-arm:
meta 4.8.2
gcc-cross-initial:
meta 4.8.2
gcc-crosssdk:
meta 4.8.2
gcc-crosssdk-initial:
meta 4.8.2
gcc-runtime:
meta 4.8.2
gccmakedep:
meta 1:1.0.2
#bitbake -s
gcc :4.8.2-r0
gcc-cross :4.8.2-r0
gcc-cross-canadian-arm :4.8.2-r0
gcc-cross-initial :4.8.2-r0
gcc-crosssdk :4.8.2-r0
gcc-crosssdk-initial :4.8.2-r0
gcc-runtime :4.8.2-r0
gccmakedep 1:1.0.2-r3
Please guide me to understand why there are multiple recipes related to gcc and which one I have to build.
In yocto, is there one to one match for recipe and package. i.e for creating each package there is a corresponding only one recipe?
To explain each one in turn:
gcc is the recipe for gcc that runs on the target machine itself.
gcc-cross is the cross-compiler that the build system uses. If you build any recipe for the target that needs to be compiled with gcc, this is what will be used to compile that.
gcc-cross-canadian- is the final relocatable cross-compiler for the SDK, in this case for the ARM architecture.
gcc-crosssdk is an intermediate step in producing gcc-cross-canadian.
the *-initial are the initial versions of the compiler required to bootstrap the toolchain separately for the standard cross-compiler and for the SDK.
gcc-runtime builds the runtime components that come as part of gcc (e.g. libstdc++).
gccmakedep isn't really part of gcc itself, it's a script that comes as part of the X11 utilities that some projects need to determine dependencies for each source file.
When you say "you only need to build gcc", it's not entirely clear what you mean, but I suspect it's either gcc for the target (in which case it's "gcc", though I suspect you'll probably need more than that - packagegroup-core-buildessential may be what you want) or you want a cross-compiler you can install separately in which case you probably ought to bitbake meta-toolchain or bitbake -c populate_sdk imagename. That'll contain more than just gcc but it's likely gcc alone isn't going to be enough anyway.
GCC is a huge project. Maybe this recipe could help you understand GCC and Yocto a little bit better. The following information is some information paraphrase from "Embedded Linux Projects Using Yocto Project Cookbook" by Alex Gonzalez
GNU toolchain contains the following components:
Assembler (GNU as): part of the binutils package
Linker (GNU Id):
part of the binutils package
Compiler (GNU gcc): support for C, C++,
Java, Ada, Fortran, and Objective C
Debugger (GNU gdb): GNU debugger
Binary file tools (objdump, nm, objcopy, readelf, strip, and so on):
these are part of the binutils package
These components are enough to build bare metal applications
bootloaders like u-boot, Linux Kernel because they do not need C
library and they implement C library functions they need.
POSIX-compliant C library is needed for LInux user space applications.
glibc is the default C library used in the Yocto Project.
On Embedded Systems, we need a cross-compilation toolchain. We build
in a host computer but run the result binarines on the target which is
usually different architecture. There are several types of toolchains
based on build machine, target machine.
The most common combinations are:
Native: An example of this is an x86 machine running a toolchain that >has also been built on an x86 machine
producing binaries to run on an x86 machine. This is common in desktop
computers.
Cross-compilation: This is the most common on embedded
systems; for example, an x86 machine running a toolchain that has also
been built on an x86 machine but producing binaries to run on a
different architecture, like ARM.
Cross-native: This is typically the
toolchain running on targets. An example of this is where a toolchain
has been built on an x86 machine but runs on ARM and produces
Canadian: Rarely seen, this is where the build, host, and target
machines are all different.
I am trying to compile the Armadillo C++ Library under Windows 32 using MinGW32 and OpenBLAS.
I've tried every tutorial and stackoverflow.com question on the topic, but still can't seem to disable the compilation of the wrapper.obj which produces link errors "undefined reference to `sdot_'" and so on. These are BLAS symbols that cannot be found by the wrapper.
I have no other BLAS/LAPACK libraries installed, and in the cmake output it confirms that libopenblas.dll has been found.
How can I disable the compilation and linking of the wrapper.obj? Editing config.hpp has no effect.
You don't have to use the cmake-based installer to use Armadillo. The installer simply creates the wrapper library which links with BLAS and LAPACK. You can instead directly link Armadillo-based programs with BLAS and LAPACK:
g++ prog.cpp -o prog -O2 -I armadillo-4.500.0/include -DARMA_DONT_USE_WRAPPER -DARMA_USE_BLAS -DARMA_USE_LAPACK -lblas -llapack
Change armadillo-4.500.0/include to point where the Armadillo include folder resides.