I have an application that I build on both windows and linux using cmake. I want to distribute my linux version, but can't find a way via cmake to make it statically compile/include SDL. I'd rather not assume/require any users have SDL already installed.
Related
I have dependencies in my code that requires libc. When building (cargo build --release) on Ubuntu 20.04 (glibc 2.31) the resulting executable doesn't run on CentOS 7 (glibc 2.17). It throws an error saying it requires GLIBC 2.18.
When build the same code on CentOS 7 the resulting executable runs on CentOS 7 and Ubuntu 20.04.
Is there a way to control which GLIBC version is required to build this version on Ubuntu 20.04 too?
If your project does not depend on any native libraries, then probably the easiest way would be to use the x86_64-unknown-linux-musl target.
This target statically links against MUSL Libc rather than dynamically linking against the system's libc. As a result it produces completely static binaries which should run on a wide range of systems.
To install this target:
rustup target add x86_64-unknown-linux-musl
To build your project using this target:
cargo build --target x86_64-unknown-linux-musl
See the edition guide for more details.
If you are using any non-rust libraries it becomes more difficult, because they may be dynamically linked and may in turn depend on the system libc. In that case you would either need to statically link the external libraries (assuming that is even possible, and that the libraries you are using will work with MUSL libc), or make different builds for each platform you want to target.
If you end up having to make different builds for each platform, a docker container would be the easiest way to achieve that.
Try cross.
Install it globally:
cargo install cross
Then build your project with it:
cross build --target x86_64-unknown-linux-gnu --release
cross take the same arguments as cargo but you have to specify a target explicitly. Also, the build directory is always target/{TARGET}/(debug|release), not target/(debug|release)
cross uses docker images prebuilt for different target architectures but nothing stops you from "cross-compiling" against the host architecture. The glibc version in these docker images should be conservative enough. If it isn't, you can always configure cross to use a custom image.
In general, you need to build binaries for a given OS on that OS, or at the very least build on the oldest OS you intend to support.
glibc uses symbol versioning to preserve the behavior of older programs while adding support for new functionality. For example, a newer version of pthread_mutex_lock may support lock elision, while the old one would not. You're seeing this error because when you link against libc, you link against the default version of the symbol if a version isn't explicitly specified, and in at least one case, the version you linked against is from glibc 2.18. Changing this would require recompiling libstd (and the libc crate, if you're using it) with custom changes to pick the old versioned symbols, which is a lot of work for little gain.
If your only dependency is glibc, then it might be sufficient to just compile on CentOS 7. However, if you depend on other libraries, like OpenSSL, then those just aren't compatible across OS versions because their SONAMEs differ, and there's no way around that. So that's why generally you want to build different binaries per OS.
I have a C++ project that I'm currently building using dynamic linking to various system libraries. It's on a RHEL 7 system. I've been using devtoolset-9 to get a more modern version of g++ (the system one is 4.8.5, I think). It all works fine, but I'd like to now build a static executable that I will be able to run on a non-RHEL linux system. I've tried specifying -static-libstdc++, but it appears to still be dynamically linked, looking at the ldd output. I've read that devtoolset compilers use some link-time trickery to link in both the system libstdc++ dynamically and any new C++ functionality statically. Is this true? It doesn't work for me; if I copy the executable over to the non-RHEL system and try to run it, I get a bunch of things like this (from memory, so hopefully correct):
/lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found
Is there any way to build a fully static executable using g++ from devtoolset-9? Thank you.
I'm trying to generate the lib files for freeglut library. I've installed cygwin and according to README file that comes with the library,
Building and Installing the Libraries with Cygwin
=================================================
To build "freeglut" under Cygwin, you have two choices:
- You can build a normal Cygwin library, which depends on Cygwin's X11
libraries. To do this, you can just use the normal autotools incantation:
./configure && make install
- Alternatively, you can build a DLL which does not depend on X11 and links
against the opengl32 DLL. To do this, configure need a few more flags:
./configure CPPFLAGS=-mno-cygwin LDFLAGS=-mno-cygwin --without-x && make install
If you don't have MSVC, Open Watcom or Cygwin
=============================================
But If I run ./configure, I got this error
$ ./configure CPPFLAGS=-mno-cygwin LDFLAGS=-mno-cygwin --without-x && make install
-bash: ./configure: No such file or directory
Is there something I need to install in order to solve this issue? The contents of the folder doesn't have configure. These are the files in the folder
If you need freeglut, you need to install the cygwin package libglut-devel
Looking inside setup.ini you will find its description:
libglut-devel
sdesc: "OpenGL Utility Toolkit library"
ldesc: "freeglut
is a completely OpenSourced alternative to the OpenGL Utility Toolkit
(GLUT) library. GLUT was originally written by Mark Kilgard to support
the sample programs in the second edition OpenGL 'RedBook'. Since
then, GLUT has been used in a wide variety of practical applications
because it is simple, widely available and highly portable. GLUT (and
hence freeglut) allows the user to create and manage windows
containing OpenGL contexts on a wide range of platforms and also read
the mouse, keyboard and joystick functions."
category: X11
Actually i installed QT creator in my debian linux system which is having i386 processor.Now i need to cross compile the QT for debian linux with ARM processor.
So for this cross compile process i installed the compiler arm-linux-gnueabi-gcc-4.4 manually and add it in the QT creator "Tools->Options->Build&Run-->Compiler".
After that i have no idea of how to configure the installed (arm-linux-gnueabi-gcc-4.4) compiler in kit option. Because in kit option "Device Type" , it is expecting for the Qmake file of arm-linux-gnueabi-gcc-4.4.Here my doubt is
Is it possible to create Qmake file for the compiler (arm-linux-gnueabi-gcc-4.4)
If that case what is the procedure to create Qmake file for the compiler (arm-linux-gnueabi-gcc-4.4)
If not in the case any dependencies need to install.
By googling around for this solution finally i felt my head rotate because in QT documentQT document they mention 5 steps.Among 5 steps i stuck in 2nd step itself (./configure -embedded arm -xplatform qws/linux-arm-g++ ).In this step im not able to understand what is configure , embedded, arm, xplatform etc...
In some link link number 2 they suggested to install bitbake and some steps.Here im not able to install bitbake also.
In some qt documents they mentioned embedded linux (is embedded linux is a OS like debian) and mkspecs etc..
Finally i decided to create Qmake file for the compiler arm-linux-gnueabi-gcc-4.4 but not having the single clue also.So if anybody knows what exactly i need to configure QT creator (either Qmake for compiler arm-linux-gnueabi-4.4 or something else ) so that i will follow exactly the required thing without any confusion.
Qt cross compiling for arm based board can be sucessfully done using Angstrom cross compiler. Just download Angstrom cross compiler as per your board configuration , unpack it and create cross compiler using that package.
I have connected FFTW library (http://www.fftw.org/)to a custom mentalray DLL that I have created in C++(A DLL file I have compiled on Linux (CENTOS) Using netbeans. I put this DLL in the software (Autodesk Maya) in a folder for adding custom plugins. The problem is I have installed FFTW on the computer and I dont know how to link Maya to the FFTW library. On windows I would put the FFTW dll in the folder that contains the maya.exe file that is the application Launch exe file.
Basically my question to a normal LINUX programer is if I install the FFTW libraries on linux and create a .dll for a software that links to it how do I get the software to link to the FFTW libraries?
let me know if you need me to provide anymore info..
You don't need to do anything special - so long as the FFTW libraries are at the expected location (/usr/local/lib) then you can just link to then as normal (gcc ... -lfftw3 ...).
Make sure to compile the right version: fftw floats (i.e., fftwf) versus fftw doubles. You should have a libfftw3f.3.so file, for example.
If you are using dlopen to call functions in fftw, place the .so file you generated somewhere in your $PATH.
If the mental ray "DLL" is a static library, you should configure fftw with --enable-static --disable-shared and run sudo make install.
If the mental ray "DLL" is a dynamic library, you should configure fftw with --disable-static --enable-shared and run sudo make install.
To be safe, you can do both.
sudo make install will place the fftw "DLLs" in the right place, as long as your mental ray "DLL" is using fftw conventionally (i.e., importing a fftw.h file).
Check for linker errors when you try to build your "DLL." If you see linker errors, you neglected to run sudo make install and your DLL won't work at all regardless of what you do with fftw.