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

the library's extension should give you a clue
ldd should also help

Thanks for the reply

I am kind of new to this stuff. Where can I find out which extensions mean what?

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

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

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.

err... sorry, I started working on something else and sort of forgot about this thread.

Thanks for the advise Eric! I got a much better understanding of how QT fits together with KDE after reading the SlackBuild.


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.

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

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

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).

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