Dependencies checking

[bigfoot]

I think I was lucky in creating my first pet file. When installing there is no missing dependency puppy yells about.
But what if there was? I haven't found a good Howto which tell's about that. Can someone point me to it, please?

[Dingo]

I think you can use ldd command

Code: Select all

List dynamic dependencies of executable files or shared objects.

Syntax

ldd [-d | -r ] [ -f ] [ -i ] [ -l ] [ -s ] [ -v ] filename
-d 	Check references to data objects.
-r 	Check references to both data objects and functions.
-f 	Force ldd to check for an executable file that is not secure. When ldd is invoked by a super user, by default, it will not process any executable that it finds not secure. An executable is not considered secure if the interpreter it specifies does not reside under /usr/lib or /etc/lib, or if the interpreter cannot be determined.
-i 	Displays the order of execution of initialization sections.
-l 	Forces the immediate processing of any filters so that all filtees, and their dependencies, are listed.
-s 	Displays the search path used to locate shared object dependencies.
-v 	Displays all dependency relationships incurred when processing filename. This options also displays any dependency version requirements. See pvs.
filename 	The name of the file.

[technosaurus]

ldd /path/to/binary
using the pfix=ram boot parameter (so that you don't have any stray libraries)
if any libraries are missing you can get them from tttuuxxx's library repo at puppylinux.ca/tpp/ttuuxxx
just put the actual library in /usr/lib and then create the appropriately named links to it (can be done with right click) - usually the one that is over 1KB (the others are just copied symlinks that don't work after downloading in a traditional way so it is usually easier to just re-symlink them)

[bigfoot]

Thanks, thought dependencies would also hit other pet packages.

Now the next question. If I'd build a pet package which has dependencies, can I download the nescessary files and put them into my DESTDIR to the corresponding place and build the pet package with them? Or is this dangerous and can produce problems on other hosts?

[technosaurus]

I often compile the pet according to "pet packaging 101" then drop the missing libraries into the pet's corresponding ...-486/usr/lib folder

or if you have compiled all of the packages yourself, you can simply open up all of the corresponding package-...-486 folders and dragndrop copy all the contents to the main package-...-486 folder and run dir2pet on it

[bigfoot]

Ok, thank you, I can work with this information so far. Now I have another question.

I am working on creating a pet file, pidgin-otr-3.2.0

Pidgin-otr depends on libotr-3.2.0 and libotr has the following dependencies:
At least libgpg-error-1.0 and libcrypt-1.2.0, so I attempt to use the following versions:
ftp://ftp.gnupg.org/gcrypt/libgcrypt/li ... 4.4.tar.gz
ftp://ftp.gnupg.org/gcrypt/libgpg-error ... 1.7.tar.gz

What to do now, libgpg-error is no puppy package, yet, and putting it in I expect no troubles.

But an older version of libcrypt already resides on the puppy system and dietlib path, also. /etc/ld.so.conf has /usr/lib first, /usr/local/lib follows, so I expect troubles creating a pet package with prefix=/usr/local and I think I have to avoid overwriting already existing system libs so I can't use prefix=/usr, can I?

Can you help me solving this?

[bigfoot]

I have tried /usr/local as prefix and this works fine. The only thing that hinders me to compile pidgin-otr-3.2.0 is that it requires glib >=2.6 which is not the case.

What a pity. Changing glib would need to recompile everything, wouldn't it? So creating this pet package currently is impossible.

BTW: I have seen another new pet file for pidgin compiled for i686 at this forum. As I have understood puppy compatibility, I advise to use the following configure options when compiling compatible pet files for the masses:

--program-transform-name='s,^i486-t2-linux-gnu-,,'
--build=i486-t2-linux-gnu
--host=i486-t2-linux-gnu
--target=i486-t2-linux-gnu

[technosaurus]

you can actually edit the configure script so that it looks for an earlier version of programs. This works ~50% of the time and the other 50% you can //comment out (or fix/patch) code that doesn't work with the old lib (when you run make it will tell you the line# and filename where it fails)

Note that if you comment out the code that function won't be in the final program and it could fail to function properly. I did this with a recent dev version of abiword and ended up with no menus.

[sikpuppy]

What a pity. Changing glib would need to recompile everything, wouldn't it? So creating this pet package currently is impossible.

You may be thinking of Glibc, whch is a bit different.

Glib is the GNU libraries, a part of GTK+ (The GIMP Tool Kit). Here is a (i686) compiled pet of the latest version: http://cid-da097326680e08e6.skydrive.li ... 3-i686.pet

If you want to update your GTK2 you can here too: http://cid-da097326680e08e6.skydrive.li ... 2-i686.pet