I've downloaded, built and installed glibc many times before and all was ok, this time ldconfig binary is not created and hence I am unable to update the /etc/ld.so.cache file correctly leading to a problem finding shared objetcts. The version of glibc with this behaviour is glibc-2.20, I am using a custom linux distribution built initially with the help of the Linux From Scractch Book, custom linux also and x86_64 architecture.
I've tried changing the configure options and also tried to compile without any option at all.
I solved it, there is a variable in the configure script use_ldconfig it was set to no, setting it to yes did solve the problem.
Related
i trying to create a appimage for my Linux system. Using qt-creator i have completed the programing and ran the app successfully . but when i am trying to make it appimage using linuxdeployQt i am facing some errors
linuxdeployqt 5 (commit 37631e5), build 631 built on 2019-01-25 22:47:58 UTC ERROR:
The host system is too new.
Please run on a system with a glibc version no newer than what comes with the oldest still-
supported mainstream distribution, which currently is glibc 2.20.
This is so that the resulting bundle will work on most still-supported Linux distributions.
For more information, please see
https://github.com/probonopd/linuxdeployqt/issues/340
i don't know what this issue is. when i visit the website, it is not clear also. So anyone familiar with this kind please put your help here.
It means that your glibc is too new.
That's correct, to work around this issue while using linuxdeployqt you have to choose as build environment an older system such as Centos 6 or Ubuntu 14.04.
As an alternative, you can use appimage-builder which allows producing AppImages on newer systems.
It means that your glibc is too new. I think it is supported glibc version comes with Ubuntu 14.04 as it is mentioned in herr https://github.com/probonopd/linuxdeployqt/issues/340. I have faced the same problem and still struggling to solve this issue.
im trying to solve this issue for a few days now and i cant find any solution.
I got myself an Atmega88A and i want to program it on fedora.
I tried to program C with gcc and that went well. But as i tried to include the avr/io.h, i always get the failure that it didnt found anything. I tried to get the new version of gcc, but that gives me an error too. Would it be enough to just download the avr/io.h library and implement it somewhere in my files? or is there any way to download this all together, including also all the other libraries that i need (e.g. util/delay.h)
You need to use a version of GCC that is specifically built to target AVR chips, you cannot just use the normal gcc executable for your system because it will produce the wrong kind of program. If you download a correctly-configured toolchain, then lines like #include <avr/io.h> should work automatically because the toolchain's default include search paths will be set up properly.
Many Linux distributions provide an avr-gcc package that you can just install with your package manager, including Fedora. You might have to install the avr-libc package to get the avr/io.h header.
If that doesn't work for some reason, you could try downloading Microchip's official AVR toolchain from this page:
http://www.microchip.com/avr-support/avr-and-arm-toolchains-(c-compilers)
What fixed this problem for me was this missing package: avr-gcc-c++. Running the command:
dnf install avr-gcc-c++
fixed it.
I have a problem connected to a version of the openmpi library. Recently I had installed the newest stable version of the openmpi (1.10.2) and one of the programs I use stopped working. There is an error message when I run it:
error while loading shared libraries: libmpi.so.1: cannot open shared object file: No such file or directory
Indeed, there is no such a file in my system. There is however a newer version of the library - libmpi.so.12 and libmpi.so.12.0.2. Other programs, which are using openmpi, work without any error, which proves that the library was installed correctly (at least I think so (: ).
Unfortunately, I don't know which version of the openmpi was used to compile the program. I don't have access to its source code, so I cannot compile it against the newer library. I noticed that I can make the program run if I copy the libmpi.so.12 to the file called libmpi.so.1
Therefore, I have two questions:
Is it reasonable to use the workaround I've found? I have some doubts, although the program appears to run well.
Is there a way to check which version of the openmpi library was used during a compilation?
Thanks in advance.
EDIT:
I use Linux Mint 17.3.
Trying to compile Linux kernel for arm platform on a Ubuntu virtual machine
$make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi-
It fails as follows
arm-none-linux-gnueabi-gcc: not found
Tried to install
$sudo apt-get install arm-none-linux-gnueabi-gcc
E: unable to locate package arm-none-linux-gnueabi-gcc
Where to find the correct package? how to include it in the system? (I found a couple of links on line that didn't work for me). It would be great if you could provide a correct solution or reference.
The Ubuntu package names are gcc-arm-linux-gnueabi/gcc-arm-linux-gnueabihf.
For building the kernel, which one you use does not make much difference. For building anything else, "gnueabihf" is the hard-float version. For any modern ARM processor (this statement excludes the Raspberry PI), this is the one you would want.
Download arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 from https://sourcery.mentor.com/GNUToolchain/
or https://sourcery.mentor.com/sgpp/lite/arm/portal/subscription?#template=lite
Get correct version of the arm-none-linux-gnueabi toolchain (i.e. targetting GNU/Linux rather than EABI).
untar it
tar xvf arm-2013.05-24-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2
open bashrc
vi .bashrc
at the end add below comand
export PATH=$PATH:{path to toolchain}arm-2013.05/bin
e.g export PATH=$PATH:/home/vinay/under_linux/arm-2013.05/bin
save it and quit the terminal.
then you can cross-compile without everytime export.
Also take of correct toolchain there are two toolchain available choose according to your requirement.
Cross compile error "arm-none-eabi-g++ cannot find entry symbol"
Can I install an older version of gcc/g++ (4.1.3) on the latest Ubuntu (which comes with 4.4.3) and use it to compile a .so which should run on CentOS? The binary compiled with the Ubuntu version of gcc fails to load on CentOS because of missing imports (GLIB_2_11, ...). I need C++ (including exceptions), so I can't just statically link against glibc, which I already tried.
Can I install the older gcc without removing the newer one? How do I go about the libs required by the older gcc?
I'm currently developing code in CentOS, but it's such a pain to use. I really want to move to an Ubuntu desktop.
g++-4.1 is available for Ubuntu; just run apt-get install g++-4.1 then run g++-4.1 instead of g++. However, simply using an older compiler may not fix all of your library issues.
Like Joachim Sauer said, your best bet is to do your development on Ubuntu then do the final compilation on CentOS.
Even though you're using C++, static linking should still be an option. (However, you're much better off compiling on CentOS and using dynamic linking.)
Edit: A virtual machine is the most straightforward way to build on CentOS, but if you want to avoid the memory and CPU overhead of running a VM and don't care about differences between Ubuntu's and CentOS's kernel, then you can create a subdirectory containing a CentOS or Fedora filesystem and chroot do that to do your builds. This blog posting has details.