LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 06-12-2006, 04:01 PM   #1
drkstr
Senior Member
 
Registered: Feb 2006
Location: Seattle, WA: USA
Distribution: Slackware 11.0
Posts: 1,191

Rep: Reputation: 45
How can I find out if libraries are hard coded into the binary (QT specificly)


Hello,

I am trying to install the QT libraries and headers on my system but it does not support dynamic install directories (DESTDIR, or make --prefix=dir install) I don't install anything to my system before turning it into a Slackware package first, so I was wondering if I would run into any problems if I did './configure --prefix=<build dir>' then turn the build dir into a package that installs to the root drive.

I am interested more in general how I can figure out if libraries are stacily linked to their path rather then knowing just QT.

Any suggestions?

thanks for yoru time!
...drkstr

Last edited by drkstr; 06-12-2006 at 04:02 PM.
 
Old 06-12-2006, 08:28 PM   #2
kodon
Member
 
Registered: Jul 2004
Location: [jax][fl][usa]
Distribution: Slackware64-current
Posts: 796

Rep: Reputation: 31
the library's extension should give you a clue
ldd should also help
 
Old 06-13-2006, 03:05 PM   #3
drkstr
Senior Member
 
Registered: Feb 2006
Location: Seattle, WA: USA
Distribution: Slackware 11.0
Posts: 1,191

Original Poster
Rep: Reputation: 45
Thanks for the reply

Quote:
the library's extension should give you a clue
I am kind of new to this stuff. Where can I find out which extensions mean what?

Quote:
ldd should also help
I couldn't really figure out what the output meant.

Also please note I could be using the wrong terminology. As an example to what I am referring to, gcc runs into problems if you install it to a temporary directory and then move it into the desired location later. Is this because of staticly linked libraries, or am I talking about something else here?

thanks!
...drkstr
 
Old 06-13-2006, 03:21 PM   #4
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,559

Rep: Reputation: 8116Reputation: 8116Reputation: 8116Reputation: 8116Reputation: 8116Reputation: 8116Reputation: 8116Reputation: 8116Reputation: 8116Reputation: 8116Reputation: 8116
Did you look at the way the Slackware slackbuild script for Qt works? Quite convoluted, and with a lot of comments from Pat Volkerding about the steps he took.

Eric
 
Old 06-13-2006, 05:02 PM   #5
osor
HCL Maintainer
 
Registered: Jan 2006
Distribution: (H)LFS, Gentoo
Posts: 2,450

Rep: Reputation: 79
Quote:
Originally Posted by drkstr
I am interested more in general how I can figure out if libraries are stacily linked to their path rather then knowing just QT.
I'm not sure exactly what you're asking. First, your probably talking about shared libraries (since static ones need to be found only at compile-time), which makes your use of the word static confusing. I am going to assume that you want to know how to tell if a shared library's path is hardcoded into the file itself.

All correctly-compiled shared libraries have the extension .so (static ones are .a), and should have a property called the soname. The soname attribute was created to allow multiple versions of libraries to coexist on the same system (kind of like anti-dll hell). The command ldd shows what shared libraries are needed by the file(s) given in the arguments. A way to find the soname of an actual library is to use `objdump -x /path/to/lib.1.2.3 | grep SONAME' (assuming elf executables). A properly configured library should have no `absoulte path' and should end in at most two version numbers (usually only one). So, the path should not be hardcoded in.

But...

Some (misguided) programmers feel the need to have paths hardcoded into programs (and libraries). This, however, is not easy to find by objdumps or similar. You actually have to look at the Makefiles (after configuring, of course), searching for something like `CFLAGS+=-DMY_COOL_PATH=${PATH}' or similar. This is basically passing a `#define' statement containing the indicated path at compile time. There is rarely a time when such a thing actually makes sense; nevertheless, many programmers don't seem to notice the flaw. I am pretty sure that this does not happen with QT.

Sometimes, a similar thing happens with documentation. Maybe the document-writer decided it would be helpful to put the path of an executable in its manpage. Although this is not as serious, it is still kind of bad.
 
Old 06-18-2006, 04:48 AM   #6
drkstr
Senior Member
 
Registered: Feb 2006
Location: Seattle, WA: USA
Distribution: Slackware 11.0
Posts: 1,191

Original Poster
Rep: Reputation: 45
err... sorry, I started working on something else and sort of forgot about this thread.

Quote:
Did you look at the way the Slackware slackbuild script for Qt works? Quite convoluted, and with a lot of comments from Pat Volkerding about the steps he took.
Thanks for the advise Eric! I got a much better understanding of how QT fits together with KDE after reading the SlackBuild.


Quote:
I'm not sure exactly what you're asking. First, your probably talking about shared libraries (since static ones need to be found only at compile-time), which makes your use of the word static confusing. I am going to assume that you want to know how to tell if a shared library's path is hardcoded into the file itself.
You would be assuming correctly. Sorry for the confusion, I'm just now starting to figure out what all of this stuff means. I didn't realize what I was getting myself into when I decided to switch to Linux. At least I will come out a better man for it.

Quote:
The command ldd shows what shared libraries are needed by the file(s) given in the arguments. A way to find the soname of an actual library is to use `objdump -x /path/to/lib.1.2.3 | grep SONAME' (assuming elf executables). A properly configured library should have no `absoulte path' and should end in at most two version numbers (usually only one). So, the path should not be hardcoded in.
I think I'm starting to get it now. It looks like I will be OK "prefixing" QT into a temporary build directory. Thanks for the help, this will be useful knowledge down the road.

Thanks all!
...aaron
 
Old 06-18-2006, 01:25 PM   #7
drkstr
Senior Member
 
Registered: Feb 2006
Location: Seattle, WA: USA
Distribution: Slackware 11.0
Posts: 1,191

Original Poster
Rep: Reputation: 45
Oops. I tried asking a moderator to change the title so it more adequately represented what I was asking but I told them the wrong thing. I mean "How can I find out if the library paths are hard coded..." I basically asked them to change it to the same thing but in different words. Oh well, I'm not going to bother them about it again.

I have another question quick question though if anyone has the time. When I was doing my Linux From Scratch, they got around some hard coded library paths for gcc by using a sed script. Is this something I can use for other stuff as well or does it just relate to gcc?

I am trying to redo my Linux From Scratch with an actual understanding of what's going on, instead of just following directions. I realized that I don't know much about how the system libraries work and will need to get a better grip on this before I can make my LFS the way I want it.

Thanks for the help!
...aaron
 
Old 06-18-2006, 09:17 PM   #8
osor
HCL Maintainer
 
Registered: Jan 2006
Distribution: (H)LFS, Gentoo
Posts: 2,450

Rep: Reputation: 79
Quote:
Originally Posted by drkstr
I have another question quick question though if anyone has the time. When I was doing my Linux From Scratch, they got around some hard coded library paths for gcc by using a sed script. Is this something I can use for other stuff as well or does it just relate to gcc?

I am trying to redo my Linux From Scratch with an actual understanding of what's going on, instead of just following directions. I realized that I don't know much about how the system libraries work and will need to get a better grip on this before I can make my LFS the way I want it.

Thanks for the help!
...aaron
IIRC, you get around the hardcoded path of the libary linker (part of binutils) when compiling gcc. They use a cool sort of trickery: give a name to a directory on the to-be-lfs root partition (they use `/tools'). Then create a symlink on the host computer's root directory to aforementioned file (for the standard lfs build I think it's `/mnt/lfs/tools'). Then, in the first path, any references to `/tools/foo' will be correct. It will also carry over in the chroot phase, where the minimal system (theoretically) knows nothing about the host (except kernel). This ingenious trick makes it seem very easy for the first-time-LFSer, and it seems to work automagically. (This is not, however, the only method of creating a toolchain. For example, having only statically linked stuff in the first pass.).

AFAIK, this is another case of certain applications, (sometimes major) like gcc, having hardcoded stuff. In this case, it is pretty much fine, since it can be changed in a specs file (not truly hardcoded), and it represents only the state of the system at compilation without giving too many details of the place of compilation. As far as I can remember, you never actually have to patch the source of gcc (well, not for this reason, anyway).
 
Old 06-18-2006, 09:35 PM   #9
drkstr
Senior Member
 
Registered: Feb 2006
Location: Seattle, WA: USA
Distribution: Slackware 11.0
Posts: 1,191

Original Poster
Rep: Reputation: 45
Quote:
Originally Posted by osor
IIRC, you get around the hardcoded path of the libary linker (part of binutils) when compiling gcc. They use a cool sort of trickery: give a name to a directory on the to-be-lfs root partition (they use `/tools'). Then create a symlink on the host computer's root directory to aforementioned file (for the standard lfs build I think it's `/mnt/lfs/tools'). Then, in the first path, any references to `/tools/foo' will be correct. It will also carry over in the chroot phase, where the minimal system (theoretically) knows nothing about the host (except kernel). This ingenious trick makes it seem very easy for the first-time-LFSer, and it seems to work automagically.
Yes, this is a handy little trick. I'm actually planning to take it one step further this time through and have /tools --> /mnt/hlfs/tools --> /mnt/hlfs/root. This way I will have my toolchain in the /root directory once I become independant of the host system. I'm sure I will have loads of fun trying to figure out how to then make my toolchain independant of the 'tools' link. It will be the ultimate lesson in library paths.

...aaron
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Where can I find the libraries? clau_bolson Mandriva 1 11-08-2005 08:40 PM
where can I find binary xmx abd_bela Linux - Software 1 12-28-2002 02:19 PM
Can't find any libraries..? Halz Linux - Software 1 04-25-2002 06:46 PM
How to find the directory of a binary (in C) DiscoStoo Programming 1 03-22-2002 04:29 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 05:18 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration