In Linux From Scratch during the 1st pass of GCC we have a case command that changes -m64 to ../lib instead of lib64. I am aware that this patch is to eliminate a compile time error but why can't we set the -m64 variable to ../lib64? I am also wondering about the LSB compatibility symlink on glibc in chapter 5. There is also a hardcoded path in ldd that we fix after the install of glibc. the path points to /usr/lib. We patch the ldd to point to /lib but we set the default directory path for our libraries to /usr/lib during configure. I am aware of fedoraprojects usr/move and how the developers have been working on the start up of the boot loader. So we put everything in /usr/lib /usr/bin and /usr/sbin. I guess my confusion is why we can't put libraries in lib64 on LFS if LFS is a pure 64 bit system. I am wondering if they're any 32 bit libraries that still come with glibc or 32 bit legacy programs that we build in blfs even though lfs is a pure 64 bit system and that is why we cannot use lib64? Any help appreciated. GLAWMAN
Related
I am trying to build c file included by ndk under cygwin
In Android.mk, I add -I/usr/include to LOCAL_FLAGS like
LOCAL_FLAGS := -I/usr/include
And I have checked that openssl does under /usr/include
But when I run ndk-build under by project dir, it output
"fatal error: openssl/ssl.h: No such file or directory"
I think I have specified the include directory, but not solve this problem.
Is there any other way can I try?
You seem to have some gaps in your knowledge:
C code compiles to processor's native instruction set. Your desktop/build machine probably has a different architecture from your Android device(thus a different instruction set).
NDK doesn't just compile, it cross-compiles. It means that the NDK runs on the build machine, but the executable it produces cannot run on the build machine(different instruction sets).
All libraries on your desktop are in your desktop's processoer's instruction set. Thus, you cannot link any program build by the NDK using the desktop's libraries. This means:
No includes from '/usr/include/'
No libs from /lib, /usr/lib, /lib64 or /usr/lib64
No Cygwin packages under on Windows
What you need to do is build your own openssl using the NDK and use that to link against when you build your executable.
Please note that the answer is missing a lot of information (at least 3 Bachelor's level Computer Science courses worth of information).
I set up an ancient machine with SUSE Linux 10.1, and am trying to build a current distro of gcc, but that wants gmp, mprf and mpc.
Now, I installed gmp successfully, and I find it in /usr/local/include and /usr/local/lib. I also find the shared library libgmp.so.10 in /usr/local/lib. Alas, when I run make check for mpfr, it complains that it can not open the shared object file libgmp.so.10
The question, then, is what do I need to do to tell it where the shared object file is?
Thanks
Ted
Make sure /usr/local/lib is on the LD_LIBRARY_PATH environment variable.
Alternatively, configure mpfr with the --with-gmp=/usr/local/ option. You'll have to do the same with mpc when you build that, but you'll have to also add the --with-mpfr=/usr/local option when configuring it.
I am running prelink on an ARM system with Linux 2.6.35. I am using Glibc 2.12.2. I would like to prelink my libraries and application executables. However, I can't seem to link anything that relies directly upon glibc. When prelink tries to run on /lib, it errors out with:
Could not write /lib/libc-2.12.2.so: Layout error: section size too small for data
Is there a way for me to fix this or perhaps convince prelink to prelink everything except what resides in /lib? I am aware of the blacklisting feature in /etc/prelink.conf, but then prelink will error out because it cannot find dependencies located in that directory.
Edit:
Here is my prelink.conf
~ # cat /etc/prelink.conf
-h /usr/local/Qt-4.7.4/lib
-h /usr/lib
-h /lib
-h /usr/local/dbus/lib
-h /usr/local/sqlite/lib
-h /usr/local/ncurses/lib
-h /usr/local/expat/lib
-h /usr/local/ssl/lib
I am on the i.MX51 platform by Freescale. It is an ARM Cortex-8. Being that I have compiled everything with the GCC/G++ version that came with our development kit, I assume that the ELF binaries are 32-bit.
Edit:
I changed the -h flags to -l's and moved the system libs to the front of the list. I still get the same error.
I am running prelink on the device, not on my cross-building machine.
LD_LIBRARY_PATH contains /lib and /usr/lib
Tried running prelink as:
prelink -a
prelink -amR
and got the same result both ways.
I am running gcc 4.4.6 cross compiler.
I am running ld 1.12.1 ld.
The error Layout error: section size too small for data is called in libelf on the following line https://github.com/path64/compiler/blob/master/src/libelf/lib/update.c#L230.
This gets called by prelink in write_dso
if (elf_update (dso->elf, ELF_C_WRITE) == -1)
return 2;
write_dso gets called by update_dso which gets called in main.c of prelink along with a few other places.
This happens because the size of the section data being relocated is larger than the section size it is being relocated to.
What prelink command are you running ?
What is your prelink.cache ?
Are your binaries / libraries ELF32 or ELF64 ?
The file utility will tell you.
What are the gcc version, binutil version, libelf and prelink versions?
gcc -V will tell you. Along with ld -V and prelink -V.
What is your LD_LIBRARY_PATH ?
The set or env command will tell you.
What options was glibc compiled with ? Specifically with regards to -fPIC ?
Are you running prelink on the device itself ? or in a cross compile environment ?
Why does your prelink configuration have no -l lines ? -h lines will follow symlinks which might not be what you want if your build root has symlinks in library directories ? Also normally the /lib and /usr/lib entries go first in a prelink.conf like the example here.
Are you running prelink with the -m switch to converse virtual memory?
If you blacklist everything in /lib, then I believe you can't prelink any library or binary that links to a library in /lib, similarly if you blacklist /lib/libc-2.12.2.so then you can't prelink to anything that links to it , as a prelinked file needs its libraries to be prelinked as well.
As for a possible fix, without having more information, it is hard to say, but it could be related to incorrect switches passed to prelink or mixing 32 bit or 64 bit libraries in the same directory in prelink cache or configuration file.
Further information on linking and prelink is avaliable
Executable and Linkable Format
prelink
Is there any way to link against RedHat static libraries while building on Ubuntu and using GCC?
Copy over the RedHat library and header files to a directory preserving directory structure and give GCC the --sysroot directive to tell it to look in that directory as prefix for searching libs and headers
I see two obvious solutions:
Copy /usr/lib, /lib and /usr/include from a Red Hat system into a subtree and point -I and -L to this subtree.
Install a minimal RedHat into a chroot and compile there.
The first solution is the easiest, but you might run into libc version issues. The second solution is guaranteed to work, but not far from running a complete RedHat for compilation.
Good morning,
on a 64bit RedHat box we have to compile and run a 32bit application. Meanwhile I managed to compile the gcc version needed (4.0.3) and all required runtime libraries in 32bit and have set the LD_LIBRARY_PATH to point to the 32bit versions, but now during the remaining build process, a small java program needs to be executed which is installed in /usr/bin as a 64bit program, which now finds the 32bit version of libgcc_s.so first.
In general, if I set the LD_LIBRARY_PATH to the 32bit versions, I break the 64bit programs and vice versa.
How it this supposed to work at all? I am certain I am not the first person with this problem at hand. How is it solved usually?
Regards,
Stefan
Add both the 32-bit and 64-bit directories to the LD_LIBRARY_PATH.
If you do this, then the ld.so for 32-bit or 64-bit will use the correct libraries.
e.g. A 32-bit test app "test32" and 64-bit test app "test", with a locally-installed copy of a (newer version of) gcc and binutils in a user homedir, to avoid clobbering the system-wide install of gcc:
=> export LD_LIBRARY_PATH=/home/user1/pub/gcc+binutils/lib:/home/user1/pub/gcc+binutils/lib64
=> ldd ./test32
libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib/libstdc++.so.6 (0x00111000)
libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib/libgcc_s.so.1 (0x00221000)
=> ldd ./test
libstdc++.so.6 => /home/user1/pub/gcc+binutils/lib64/libstdc++.so.6 (0x00007ffff7cfc000)
libgcc_s.so.1 => /home/user1/pub/gcc+binutils/lib64/libgcc_s.so.1 (0x00007ffff7ad2000)
(Less interesting library paths removed)
This shows that the loaders know to ignore the libraries of the wrong architecture, at least on this Scientific Linux 6.3 (RHEL-derived) system. I would expect other distros to work similarly, but haven't tested this.
This may have only started being the case more recently than your (unspecified) distro version, however.
On Solaris one can use LD_LIBRARY32_PATH and LD_LIBRARY64_PATH, but that isn't supported on Linux.
In general, you should just never need to set LD_LIBRARY_PATH at all in the first place:
either install needed libraries into
/usr/lib32 or /usr/lib64 as
appropriate, or
build your 32-bit application with -Wl,-rpath=/path/to/32-bit/libs
As a workaround, wrap the Java call in a small shell script which unsets LD_LIBRARY_PATH and then calls the executable. Alternatively, this might also work:
LD_LIBRARY_PATH= java...
Note the space between "=" and the name of the executable.
Just set LD_LIBRARY_PATH to both paths (use colons to delimit). The linker will ignore the libraries that it cannot read.
I have faced this exact same problem when remastering a 32bit tinycore64 system running a 64bit kernel.
After much searching, I have discovered why these comments would make sense to both of them.
"That would be nice, but - at least in my environment - it did not
appear to work. The loader did complain; it did not simply skip the
libraries that do not match the bit-ness. Sadly!" - struppi
"This is very strange, could you describe how things failed? Also,
perhaps post the output of ldd?" - Adam Goode
And why this comment might appear to be true but is actually incorrect.
The linker will ignore the libraries that it cannot read.
This link shed's some light on it.
http://www.markusbe.com/2009/09/about-running-32-bit-programs-on-64-bit-ubuntu-and-shared-libraries/
And more to the point, you will find the ld.so manpage enlightening.
It turns out the path name can make a difference in what the runtime linker ld.so chooses as the library to load. On my 64bit linux system I have a range of odd directory names in addition to the standard ones. e.g. /lib/x86_64-linux-gnu. I actually thought I'd experiment by moving the libraries in that path to /lib64. When I did that, guess what happened? suddenly my 64bit app (brctl in this case) didn't work and complained with "Wrong ELF class". Hello... now we're onto something.
Now I'm not 100% certain but the key seems to be related to rpath token expansion.
I suspect the ${PLATFORM} expansion may have something to do with it. And the name x86_64 must be part of that.
In any case, I found when I put my 64-bit libraries in library paths named
x86_64-linux-gnu as apposed to just lib64, then they were preferred over the 32bit ones and things worked.
In your case, you probably want to do something very similar for 32bit libraries on 64. Try i386-linux-gnu.
So in my case where I am installing 64bit shared libraries onto a 32bit userland, I created the following paths:
mkdir /lib/x86_64-linux-gnu/
mkdir /usr/lib/x86_64-linux-gnu/
ln -s /lib/x86_64-linux-gnu /lib64
ln -s /usr/lib/x86_64-linux-gnu /usr/lib64
Add your 64bit libraries to the 64bit paths and 32bit libraries to the 32bit /lib & /usr/lib paths only.
Then add the 64bit specific paths to ld.so.conf and update your cache with ldconfig
Now your 32-bit & 64-bit applications will run seamlessly.