Cross-compile libraries on Linux - part 2 of 2
ฝัง
- เผยแพร่เมื่อ 16 ก.ย. 2024
- In this video, I give a practical demonstration for how to cross-compile libraries on Linux. It shows how to cross-compile zlib and openssl (with zlib compression). This is part 2 of a two-part set.
First video: • Cross-compile librarie...
This is such a great series which covers an intersection area of compilers, computer architecture, linker and dynamic/static library.
It was one of the very few inspiring videos on this topic: I do like the clear concept explanation and self illustration demo session.
Looking forward more videos from you !
Thank you. I'm glad you find them useful. I'm hoping to get back to making new videos very soon.
I am making my first comment ever on a TH-cam channel video. I am really thankful to you on creating this amazing content. I was facing the same shared library issue when debugging on target device. But many thanks to you that you have explained it very well. Looking forward to more videos on some topics like cmake list, and yocto. Thank you
Great! I'm glad it was helpful.
Your explanation of reflect deep understanding of the topic, thank you for your effort.
This is a great series! Thank you!
Thanks!
Very good video! Thank you so much! -David
Very straight-forward great content. Thanks.
Thanks!
very useful videos, its a reference for the cross-compiler, thanks much!
I wonder why this series got stopped. Such amazing content.
Thank you for your comment. I do these videos when I have spare time and just have been very busy this last year. I do have some more content I plan on creating when I have time.
@@embeddedarmdev Do you have anything I can read after this? What should I learn about next?
I guess it depends on what you want to learn about. What are you interested in?
@@embeddedarmdev I'm a self taught software developer and I've been thinking about bridging a few gaps. Current I'm learning about OSDev, kernels, networking etc. I've worked on embedded devices as a hobby. I guess the next thing I want to learn about is virtualization, ie, how processor, memory, disk and network each one of them is virtualized with minimal overhead.
Great video :)
so helpful ,thank you!
great video brother
Hello, first of all thank you for creating such an amazing video for cross compilation.
My query is: I'm trying to build openssl for QNX7.1 target and ARM architecture. Which cross-compile-prefix should I use?
When telling ssl's configure where to find zlib, why can't you just give it the prefix only, and then it looks in the usual place that zlib would live in that prefix? Is it because usr/local/include is not the usual place? Or is it normal to have to give the include/lib location of all dependencies manually?
The prefix only tells the config what the base name of your cross-compile toolchain is. In this video, the prefix is arm-linux-gnueabi-. So, for example, when it wants to use the cross-compiler, it would call arm-linux-gnueabi-gcc because it takes the prefix and appends 'gcc' to it to determine the correct compiler to call.
The directories we specify for zlib are a different matter. In order to compile ssl with compression, it needs to know two things about zlib; where the zlib header files (include files) are and where the zlib library is (the shared object .so). The location of these files has nothing to do with the prefix we specified. They are not in any standard location because we have created our own little cross-compile environment, so we have to tell it where to look.
Also keep in mind that the zlib library (.so) in this video is a cross-compiled shared library. We keep it in a separate directory specifically so we don't corrupt our local native compile shared libraries. When we cross-compile ssl, it needs a cross-compiled version of zlib to link into.
Does that answer your question?
Hi, really good video! I have one question tho. Most of the libs that I'm using don't have a configure file so i'm using cmake DCMAKE_C_COMPILER=/path_to_compiler -DCMAKE_AR=/path_to_ar -DCMAKE_LINKER=/path_to_linker and it works great for compiling most librarys. Problem is when a library needs an other library to compile. How would i link the libs and include dir using my method?
Could you do more videos similar to this where you discuss sanitizing your build environment? I've been wanting to eliminate having to use chroot for building LFS. I want to write a build system similar to buildroot where I do not need root privileges to build my rootfs.
Thanks for your comment. Can you clarify what you mean by "sanitizing"? Are you referring to keeping the cross-compile development environment separate from the host environment? For example, when I use the --prefix option in the .configure step to tell it where to install the newly-compiled files?
As far as using chroot, I have never done this. I always have a rootfs directory that will be the root FS that ends up on the target machine and I always ensure that I know how to specify where to install the new files. I have done this successfully without ever using chroot. There is a risk though, if you ever configure incorrectly and then run make install, you could clobber your host binaries with binaries intended for your target architecture. This is why I always develop in a virtual environment, so I can recover it if I hose it.
You might actually consider having two separate directories for your project:
The first one is more of a development environment. This is where all of the files will get installed when you build/compile and serves as your cross-development environment. For what I did in this video, that would be the rootfs directory (which probably wasn't the best choice of words).
The second directory would be where you will put files that will be used to create the root file system image. You would only copy files that are needed on the target machine itself. For example, you probably don't need the header files, man pages, etc on your target.
I do have some plans for more videos like this in the future, I will try to stress separating host, development, and target environments.
I hope this helps. Feel free to ask more questions.
I don't know if you can assist me building a linux operating system...
Thank you so much for these tutorials, I wanted to ask whether can I compile code for a LPC2148 processor which is presumably ARMv4
I am not familiar with that board or which ARM version it uses. However, you should be able to cross-compile for that board as long as you can find a cross-compiler that supports the correct version (ARMv4 or whatever). That version is pretty old and I'm not sure how easy it would be to find a cross-compiler for that version.
I'm trying to run this command "bash build-tool-chain -m tx6 -pg" to build tool-chain for Tx6 board. but it gives me an error. My cross compiler is "arm-cortexa9-linux-gnueabi-gcc" that I successfully installed.But the error says: make[1]: arm-linux-gnueabi-gcc: command not found and also scripts/gcc-version.sh: line 25: arm-cortexa9-linux-gnueabi-gcc: command not found .... I have been spending 4 months on it and no solution on internet for me
Are you getting both of these errors each time you run? It seems odd because it is looking for two different cross-compilers: arm-linux-gnueabi-gcc and arm-cortexa9-linux-gnueabi-gcc. If it is looking for the arm-linux-gnueabi-gcc and you don't have that installed, obviously it won't work. Normally build scripts have some sort of way of specifying the compiler to use. If one isn't specified it uses it's default, which in this case may be arm-linux-gnueabi-gcc. It may be an option inside a config file, or you maybe need to pass it in as a configuration option on the command line.
As far as the line 25 where it says "arm-cortexa9-linux-gnueabi-gcc: command not found" makes me think the path is not set correctly so when it runs it is unable to find arm-cortexa9-linux-gnueabi-gcc. Make sure where that is installed is in your current path.
@@embeddedarmdev
Thanks for your reply. Actually, it's looking for 1 cross-compiler which is arm-cortexa9-linux-gnueabi-gcc. I copied it wrong.
I did the install for arm-cortexa9-linux-gnueabi-gcc and after I install it and I run arm-cortexa9-linux-gnueabi-gcc -v, and I get this massage:
Using built-in specs.
COLLECT_GCC=arm-cortexa9-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/usr/local/arm/cross-gcc-7.2.0-armv7a-soft/x86_64-pc-linux-gnu/libexec/gcc/arm-cortexa9-linux-gnueabi/7.2.0/lto-wrapper
Target: arm-cortexa9-linux-gnueabi
Configured with: /home/armsdk/starterkit/tool-chain/cross-gcc/configure --target=arm-cortexa9-linux-gnueabi --prefix=/usr/local/arm/cross-gcc-7.2.0-armv7a-soft/x86_64-pc-linux-gnu --with-sysroot=/usr/local/arm/cross-gcc-7.2.0-armv7a-soft/x86_64-pc-linux-gnu/arm-cortexa9-linux-gnueabi/sys-root --enable-shared --enable-threads --enable-languages=c,c++ --disable-multilib --disable-nls --with-float=soft --with-fpu=neon --enable-__cxa_atexit --with-abi=aapcs-linux --with-arch=armv7-a -v
Thread model: posix
gcc version 7.2.0 (GCC)
I am completely lost in it. I also think that you are right regarding the path. I just struggle to understand. I'm a newbie in this linux stuff.
I have to cross-compile glibc library for armv7, should i make it static or shared object? (linux on my device have not any libraries) . I will be gratefull for advice.
I am not sure if you mean you need to cross-compile libc itself or if you mean that you just need to be able to cross-compile your target executables and not sure if you should link into libc statically or dynamically.
If you are asking about cross-compiling libc itself, then I would say you shouldn't need to do that. The cross compiler is actually one component of a toolchain. One of the other components of the toolchain is some version of the c library. It may be glibc, or it could be a lightweight one like uclibc-ng, musl, etc. Whichever compiler you are using, it should already come with the version of libc that was used to create the compiler as part of the toolchain. This would include all of the header files (.h), static archives (.a), and shared objects (.so) for the version of libc it used. This is the version of libc you should use with the cross-compiler.
If you are asking about whether you should link into libc statically or dynamically, then it depends on how you will be using the shared library. You may actually want to provide both. This applies to any library that you may use.
When you compile a library statically, you are really just creating an archive of the compiled non-executable object files. This has the .a extension. You would want to use this static library on your host computer (the one with the cross-compiler on it). You would not put this static library on your target machine unless for some reason you thought you might be compiling on the target machine. Whenever you want to compile some executable program and you want to compile in components of your library statically, then you would need the static archive of your library. The advantage to doing this is the executable program will be able to function on the target system without the need for the library to exist on the target system. The disadvantage is that the compiled executable program will be much larger in size.
When you compile the library as a shared object (.so), then you would use this shared object in two locations. The first would be on your host machine when you are compiling the target executable. When you want to compile a target executable and use dynamic linking, the linker needs access to this shared object in order to correctly link the program. This shared object would also need to be located on your target system somewhere so the target executable can use it. The advantage to compiling this way is that your target executable is much smaller in size. The disadvantage is that your target executable would require that shared object to exist on the target system in order for it to load and execute.
So, if your target does not have any libraries on it, including libc, then you would not be able to use dynamic linking. You would have to compile your target executable with static linking. However, if you were able to copy the libc shared library over to the target machine, then you could compile your target executables using dynamic linking.
If you haven't already watched them, you should check out my videos on static and dynamically linking. You may find them informative.
th-cam.com/video/t5TfYRRHG04/w-d-xo.html
th-cam.com/video/mUbWcxSb4fw/w-d-xo.html
@@embeddedarmdev thanks for the detailed answer.
I'd like to run Java SE Embedded on my armv7 device, to do that it's only necesarry to download appropriate jre file for arm and copy it to device's file system. However Java Embedded requeires glibc installed on arm-device. So my question was about glibc istalled on arm-linux. But fortunatly my device has preinstalled libc, I didn't have to do anything.
Now I need to cross-compile libpcap for arm, I'm sure your videos will be helpful. (I watched some of them several times)
27:34 Why didn't you chose *linux-x86_64*?
The tuple I am discussing here is for the target machine, not your host. So, you want to choose the architecture that the binary is expected to run on. In this video, we are compiling for an ARM processor, so I chose an ARM tuple.
@@embeddedarmdev Ok, I see, like compiling for a raspberry pi. Is that I was expecting to see you using the library with some examples and not just compiling it. Thanks for the videos.
Yes, that is correct. So for the Raspberry Pi, you might choose linux-armv4 for a 32-bit Pi and linux-aarch64 for a 64-bit Pi (assuming they are running Linux).
One thing I should also add is that the tuples you see in this video are what the Config utility is set up to use for this particular library (SSL). We see linux-armv4, so that would support armv4 instructions and would run on any processor that supports armv4 - armv7 since they are backwards compatible. Other libraries you find might use armv5 or higher. It just depends on the library.
This video was focused specifically on cross-compiling a library, not really how to use a specific library in your code. The idea was to walk you through how to set up the configuration and specify all of the compiler options, include directories, library directories, etc. in order to cross-compile a library for some other architecture.
does this cross compiler work for every arm devices , i have an armv7 32 bit
I don't think I would say this compiler works for every arm device, but I do think this is an armv7 32-bit compiler, so it should work for your device.
@@embeddedarmdev is their a guideline to compile for ffmpeg library ,that would be very helpful , btw great video!!