Find the answer to your Linux question:
Results 1 to 10 of 10
Can anyone help me figure out how to redirect ldconfig from using the original prefix that i used to install (ie. /mnt/lfs/etc/ld.so.cache) it to point to a different location to ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    Jul 2012
    Location
    USA
    Posts
    8

    ldconfig redirection!!!!


    Can anyone help me figure out how to redirect ldconfig from using the original prefix that i used to install (ie. /mnt/lfs/etc/ld.so.cache) it to point to a different location to update/generate a new ld.so.cache file located in a different directory (ie. chroot /etc/ld.so.cache ). I have tried manually linking within my chroot environment, giving it the ld.so.conf file, still no luck.

    One other thing, Why hasn't anyone never thought of just producing the ld.so.cache as a regular text file so porting would be easier. For example installing with a prefix=/usb/drive then to relink everything just edit the ld.so.cache text file to point to new chroot or environment. Or has that been done, cause I have searched for days. Thanks.

  2. #2
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by abercite View Post
    Can anyone help me figure out how to redirect ldconfig from using the original prefix that i used to install (ie. /mnt/lfs/etc/ld.so.cache) it to point to a different location to update/generate a new ld.so.cache file located in a different directory (ie. chroot /etc/ld.so.cache ). I have tried manually linking within my chroot environment, giving it the ld.so.conf file, still no luck.

    One other thing, Why hasn't anyone never thought of just producing the ld.so.cache as a regular text file so porting would be easier. For example installing with a prefix=/usb/drive then to relink everything just edit the ld.so.cache text file to point to new chroot or environment. Or has that been done, cause I have searched for days. Thanks.
    can't you just use the -r flag with ldconfig? e.g.:

    Code:
    ldconfig -r /mnt/lfs
    if not, then i don't understand your problem. can you give a specific example/command?

  3. #3
    Just Joined!
    Join Date
    Jul 2012
    Location
    USA
    Posts
    8
    I have tried using ldconfig -r /mnt/lfs

    See I have tried statically linking every program that's required by LFS base system, so it would not require shared libraries, because for some reason everything in linux evolves around them. I wanted to just chroot into the new environment and recompile everything. So I couldn't figure out how to statically build glibc, which in turn could not compile within the chroot environment because it was looking the shared libraries. I have also noticed to when compiling these binaries that little pieces of code gets built into them so the prefixes you give them is pointing to where to look for the libraries or include files. This is the reason why I don't understand why someone decided to create ld.so.cache as a binary form instead of a regular text file. When you compile glibc with a --prefix=/mnt/lfs that's what you get. So when chroot into the new environment the end result is that the ld.so.cache is pointing to /mnt/lfs/lib. I figured instead of following the book from the site, which isn't geared toward beginners id take a short cut and build everything as is to an external directory like a USB device, that I could just chroot into it and everything would work. It's funny I can copy over the required libraries for a new chroot environment and that will work just fine until I decide to compile something within it. The only reason I am here asking for help is because I wanted to build something that was simple and organized and everything had a place. Since its an open community the entire FHS is kinda open and loose.

  4. #4
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by abercite View Post
    I have tried using ldconfig -r /mnt/lfs

    See I have tried statically linking every program that's required by LFS base system, so it would not require shared libraries, because for some reason everything in linux evolves around them. I wanted to just chroot into the new environment and recompile everything. So I couldn't figure out how to statically build glibc, which in turn could not compile within the chroot environment because it was looking the shared libraries. I have also noticed to when compiling these binaries that little pieces of code gets built into them so the prefixes you give them is pointing to where to look for the libraries or include files. This is the reason why I don't understand why someone decided to create ld.so.cache as a binary form instead of a regular text file. When you compile glibc with a --prefix=/mnt/lfs that's what you get. So when chroot into the new environment the end result is that the ld.so.cache is pointing to /mnt/lfs/lib. I figured instead of following the book from the site, which isn't geared toward beginners id take a short cut and build everything as is to an external directory like a USB device, that I could just chroot into it and everything would work. It's funny I can copy over the required libraries for a new chroot environment and that will work just fine until I decide to compile something within it. The only reason I am here asking for help is because I wanted to build something that was simple and organized and everything had a place. Since its an open community the entire FHS is kinda open and loose.
    i see. the "ldconfig -r" won't help you there. what i've done in the past is build a minimal root environment, complete with a GCC toolchain. then i chroot into that environ and build my binaries, using the default prefix for them (i.e., /usr). this didn't work if my target had a different CPU, though.

  5. #5
    Just Joined!
    Join Date
    Jul 2012
    Location
    USA
    Posts
    8
    Quote Originally Posted by atreyu View Post
    i see. the "ldconfig -r" won't help you there. what i've done in the past is build a minimal root environment, complete with a GCC toolchain. then i chroot into that environ and build my binaries, using the default prefix for them (i.e., /usr). this didn't work if my target had a different CPU, though.


    So what would be the bare essentials for a root environment. I know it would need binutils, gcc and libs. Like i said before I have tried just copying that stuff over. But it stumps me that i won't work when the libraries are suppose to be shared. Kinda defeats the purpose of being shared. I would like to know, cause I want to relocate certain files from the FHS that better suites my needs and simplicity. Thanks.

  6. #6
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by abercite View Post
    So what would be the bare essentials for a root environment. I know it would need binutils, gcc and libs.
    not as much as you'd think. start with /bin/bash (your shell) and go from there. e.g.:
    Code:
    mkdir -p /mnt/newroot/bin
    cp /bin/bash /mnt/newroot/bin
    then if you try to chroot to that new dir, chroot will automatically look for /bin/bash, and find it...but fail to execute it b/c of the libs it depends on.

    so find those libs that the binary requires using the 'ldd' utility, e.g.:

    Code:
    ldd /bin/bash
    on my system, that returns:
    Code:
            linux-gate.so.1 =>  (0xffffe000)
            libtermcap.so.2 => /lib/libtermcap.so.2 (0x426e4000)
            libdl.so.2 => /lib/libdl.so.2 (0x42523000)
            libc.so.6 => /lib/tls/libc.so.6 (0x423d2000)
            /lib/ld-linux.so.2 (0x423b9000)
    so then copy all those libs to the appropriate location in the new dir (e.g., /tmp/newroot/lib/). then you should be able to execute /bin/bash and chroot. you'll have to do that w/all binaries, but you'll find lots of overlap as you go.

    another way to do it is to install a Virtual Machine (if your host pc can handle that). then use that as your build environment.

    another way: if you are using an RPM-based host system, you could use mock to created your chrooted build environment.

  7. #7
    Just Joined!
    Join Date
    Jul 2012
    Location
    USA
    Posts
    8
    Ok, I have tried what you said and was doing really well up to the point to where the linker was having problems out of crt1.o crti.o and crtn.o with undefined references. So i googled some stuff about it, and basically where slackware is built with i486 standards or generic my processor is a Xeon W3565 which build a generic i686, so my processor is producing 64-bit although i instructed the build for the ABI to be 32-bit, so I am having problems with that. So i went back and tried configuring the config file to use -march=corei7 and it bombs. So it sucks not being able to produce the right binaries to run. I was going to ask you to is if there was a way when compiling binutils-2.22 to make the ldscripts produce i686 or whatever it's suppose to produce instead of i386 or i486.

  8. #8
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by abercite View Post
    Ok, I have tried what you said and was doing really well up to the point to where the linker was having problems out of crt1.o crti.o and crtn.o with undefined references. So i googled some stuff about it, and basically where slackware is built with i486 standards or generic my processor is a Xeon W3565 which build a generic i686, so my processor is producing 64-bit although i instructed the build for the ABI to be 32-bit, so I am having problems with that. So i went back and tried configuring the config file to use -march=corei7 and it bombs. So it sucks not being able to produce the right binaries to run. I was going to ask you to is if there was a way when compiling binutils-2.22 to make the ldscripts produce i686 or whatever it's suppose to produce instead of i386 or i486.
    So you have a 64-bit CPU and you are trying to compile for 32-bit? Have you tried passing the -m32 arg to GCC at compile time?

  9. #9
    Just Joined!
    Join Date
    Jul 2012
    Location
    USA
    Posts
    8
    Yes I have tried the -m32 and -m64 arg to GCC at compile time. I know having a 64-bit CPU can process either 64-bit instructions or 32-bit instructions, and can run at the same time. When i purchased my CPU (Xeon W3565) I thought it was 32-bit, but the more i started looking into it over this issue it has 64-bit extensions, with support for msse4.2 instruction set. But what is really strange is not being able to chroot into the new environment regardless of what extension it is, but I guess the chroot program needs to be upgraded to support either 32-bit or 64-bit shared libraries so it could adjust to let you create a new environment. I downloaded the 64-bit Slackware today and going to start over and try it with this. Hopefully there will be no problems.

  10. #10
    Trusted Penguin
    Join Date
    May 2011
    Posts
    4,353
    Quote Originally Posted by abercite View Post
    Yes I have tried the -m32 and -m64 arg to GCC at compile time. I know having a 64-bit CPU can process either 64-bit instructions or 32-bit instructions, and can run at the same time. When i purchased my CPU (Xeon W3565) I thought it was 32-bit, but the more i started looking into it over this issue it has 64-bit extensions, with support for msse4.2 instruction set. But what is really strange is not being able to chroot into the new environment regardless of what extension it is, but I guess the chroot program needs to be upgraded to support either 32-bit or 64-bit shared libraries so it could adjust to let you create a new environment. I downloaded the 64-bit Slackware today and going to start over and try it with this. Hopefully there will be no problems.
    okay, i see. yeah, hopefully, the 64-bit OS will make the difference. Otherwise, i think maybe a VM (like VirtualBox) might be a good solution.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •