I'm trying to build llvm 3.4.2 on CentOS 7 with GCC 4.8.5. I can successfully build all of the libs, except libLLVM-3.4.so doesn't want to build - everything else gets created except that one. What's worse is I've managed it previously in the past, but can't do it again now.
I've tried both with CMake and autotools, with the same result. Is there an option I'm missing? Or some error in configuration possibly?
Found it - it was the --enable-shared flag to configure which causes the main shared library to be built. Confusingly this does something completely different from the CMake BUILD_SHARED_LIBS variable, which causes each of the individual libraries to be built as a shared library instead of static, but doesn't build the main shared library.
You can use
LLVM_BUILD_LLVM_DYLIB
when building from source.
The official docs say
BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.
source: https://llvm.org/docs/CMake.html
Related
Right now, I have a modified version of a open-source dependency library (mylib.a file) in my project and thus I have it statically linked via gcc command(s). I am getting the error that...
"statically linked applications require at runtime the shared libraries from the glibc version used for linking"
My translation: my static dependency library cannot dynamically use glibc; it must also be compiled and dynamically linked. Thus, I'm trying to compile and statically link glibc.
I've gather that they would need to be compiled, the *.a library placed in a folder within the project, the "-I//location//" added in for the include headers, and the "-L//location//" added in for the libraries themselves.
But, for the question itself...
How to you compile glibc (32-bit and 64-bit)?
Through open-source research, I've found this link and I have cloned the repo but I cannot find any documentation on how to actually compile it.
git clone git://sourceware.org/git/glibc.git
Any thoughts or suggestions are welcomed.
My translation: my static dependency library cannot dynamically use glibc; it must also be compiled and dynamically linked. Thus, I'm trying to compile and statically link glibc.
As n.m. pointed out, your translation is wrong.
You are trying to link a fully static executable, and GLIBC is warning you that such executable will not run correctly on any machine with a different version of GLIBC installed.
Instead of trying to build a fully-static executable, build it such that it uses libc.so.6 (you can still link mylib.a into such executable).
IF the reason you added -static to your link is that you have both libmylib.a and libmylib.so, and would like to link in the former instead of the latter, read this answer.
I'm attempting to cross-compile from Linux (NixOS) to Windows and encountering some frustrations.
There seem to be two parts that together are breaking the build:
Code in my Rust project requires multithreading, and as such requires a version of libpthread for Windows.
To build properly, I need a build.rs file. For some reason, Rust requires a version of libpthread for Linux for that.
What's the problem? Well, the build.rs has to be built with regular GCC and not MinGW because it needs to execute on my system. But for some reason, GCC is attempting to link to the Windows libpthread library instead of the system one, and as such is failing with an error about not supporting the library format.
(Failed) Alternatives
If I remove the build.rs, the project builds fine. Unfortunately, I need it for full functionality.
If I remove the Windows version of libpthread the build.rs builds and runs correctly, but MinGW fails with a missing library error when building the rest of the project.
Solution Paths?
Either I have to figure out why GCC's linking to the wrong version of libpthread, or I have to disable -lpthread entirely for the build.rs. I have no idea why it would need pthreads, considering for testing I stripped it down to only fn main() {}.
I have no idea where to start on either of these, and I've already spent a couple of days getting the problem down to this. I'd appreciate some help!
I am trying to build gstreamer using gst-build: https://gitlab.freedesktop.org/gstreamer/gst-build
Glib is one of the subprojects it is downloading and compile. But I am thinking of replacing it with the previously compiled version. How should I do it in the cross-file? Or there is no way other than hacking meson.build
Thanks
Regrds
It depends on the discovery methods that dependency supports, if it uses pkg-config, it's probably as easy as setting [built-in options]:pkg_config_path in your cross file (or the various $PKG_CONFIG_PATH environment variables) to include the pkg-config file. I'm pretty sure that glib uses pkg-config.
In my project, I am trying to use two libraries those are already compiled and generated. Let us say liba.so(our own library created sometime back) and libssl.so.10.(It is available in the Linux).
Now liba.so is having dependency libcurl.so.3 &
libssl.so.10 is having dependency libcurl.so.4 (latest)
Both libcurl.so.3 and libcurl.so.4 are available in the system.
Hence When I try to use both of them in my project, I am getting version conflict. Is it expected? If yes, how do I solve this problem?
Is there any way to modify liba.so dependency with latest libcurl.so.4 without building this library again?
Or do I need to build liba.so again with latest libcurl.so.4?
Thanks for your help
Hence When I try to use both of them in my project, I am getting version conflict. Is it expected? If yes, how do I solve this problem?
There are two solutions.
First, you would carry around the versions of libcurl.so & libssl.so you want to use. You would then use the linker's rpath or LD_LIBRARY_PATH to ensure you load the shared objects you included.
Second, you would build your liba.so to statically link against libcurl and libssl.
If you are working on Android, then number two is your choice. That's because OpenSSL is included on Android, zygote loads it, and you always get the downlevel version 0.9.8 after the fork from zygote.
On Android, you would even need to build a wrapper shared object if all you wanted was a modern OpenSSL like 1.0.1 (that looks a lot like what you are experiencing with libcurl.so.3 and libcurl.so.4).
Good day
Currently, I'm working on an embedded device based on arm-linux. I want to build GCC for my target architecture with Glibc. GCC builds successful, but I have trouble with Glibc build.
I use the latest version of Glibc (ftp.gnu.org/gnu/glibc/glibc-2.12.1.tar.gz) and port for them (ftp.gnu.org/gnu/glibc/glibc-ports-2.12.1.tar.gz)
my configuration line:
../../glibc-2.12.1/configure --host=arm-none-linux-gnueabi --prefix=/home/anatoly/Desktop/ARM/build/glibc-build --enable-add-ons --with-binutils=/home/anatoly/Desctop/ARM/toolchain/arm/bin/
configuration script work fine, but i get some compile error:
...
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/libmemusage_pic.a(memusage.os): In function me':
/home/anatoly/Desktop/ARM/src/glibc-2.12.1/malloc/lmemusage.c:253: undefined reference to__eabi+read_tp'
...
I also tried using the old version (2.11, 2.10) but have the same error.
Does anybody know the solution for this problem?
Use a precompiled toolchain, like those provided by code sourcery.
If you want to make your own, optimised (premature optimization is the root of all evil), use crosstool-NG, which is a tool dedicated to cross-compilation toolchain building.
If you are not convinced, and want to do everything with your own hands, ask your question on the crosstool-NG mailing list.
Try substituting arm-linux-gnueabi for arm-none-linux-gnueabi. Check that a compiler, loader etc. with the prefix you used for "host" exist on your path.