LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Build Separate Debug Symbols Package (http://www.linuxquestions.org/questions/slackware-14/build-separate-debug-symbols-package-921106/)

Woodsman 12-29-2011 02:45 PM

Build Separate Debug Symbols Package
 
I'm looking for script examples for creating a separate debugging symbol package when building a package.

The compiler options must be set (--enable-debug=full, -ggdb). Yet with that option set, traditionally slackbuild scripts strip the debugging symbols from the package like this:

Code:

( cd $PKG
  find . | xargs file | grep "executable" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
  find . | xargs file | grep "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded 2> /dev/null
)

Leaving those lines in the build script strips the debugging symbols despite building with the appropriate compiler options.

Commenting out those lines will build a package with debugging symbols, which creates a much larger package.

I want to build once and create two packages: the binaries and the debugging symbols.

I found this thread.

I have been trying various options based upon what I have read around the web, but no success. :(

Thanks!

Cedrik 12-29-2011 03:30 PM

You want to create 2 packages and compile one time for both or compile 2 times ?

I guess it is just a matter of copying all the slackBuild lines and paste them after the makepkg command,
then change PKG and BUILD/TAG variables, so you end with 2 packages created

wildwizard 12-29-2011 03:40 PM

Have a look at the kde.SlackBuild I made in this as it does exactly what you want.

http://wildwizard.abnormalpenguin.co...build-2.tar.xz

Woodsman 12-29-2011 08:57 PM

Thanks much wildwizard.

I more or less have massaged your script to mine. Yet there are some things I don't understand:

1. Why tar-1.13 and not the more recent tar?

2. The directories inside the package all have epoch zero time stamps rather than the current time. Why?

3. When viewing the package with Ark, the directories change ownership to that of the viewer's account rather than remain root:root. Why? When I view them as root the ownership shows root.

4. Why delete files inside the package greater than 50 bytes in size? Is this something unique to the package you are building?

Thanks much!

gnashley 12-30-2011 02:00 AM

Segregate the debug files before doing the strip step. About root/user, it's always best to be root when you build packages.

The tar-1.13 question is a very old which I would have thought you had seen discussed before. tar-1.13 has a couple of unique behaviours which are essential to creating a proper Slackware package -no other version exhibits the desired characteristics. It works perfectly, so there is no need to worry yourself about eh old version number.

wildwizard 12-30-2011 04:08 AM

Quote:

Originally Posted by Woodsman (Post 4561430)
1. Why tar-1.13 and not the more recent tar?

gnashly beat me to this

Quote:

2. The directories inside the package all have epoch zero time stamps rather than the current time. Why?
probably a bug

Quote:

3. When viewing the package with Ark, the directories change ownership to that of the viewer's account rather than remain root:root. Why? When I view them as root the ownership shows root.
don't trust ark

EDIT: Did you get the directory timestamps from ark too?

Quote:

4. Why delete files inside the package greater than 50 bytes in size? Is this something unique to the package you are building?
Actually this is not deleting files inside the package it is deleting packages less than 50 bytes in size as they would not actually contain any data and are thus duds

Woodsman 12-30-2011 09:18 AM

Quote:

About root/user, it's always best to be root when you build packages.
I am root --- in a chroot. That's the mystery. :)

Quote:

probably a bug
Reducing the script commands in a terminal showed the date stamp problem occurs at this point:

find . -type f -name *.debug | cut -b3- | xargs -r tar-1.13 cvf

I didn't like that weird behavior and I came up with this instead:

WAS:

Code:

find . -type f -name *.debug | cut -b3- | xargs -r tar-1.13 cvf - | xz -c > $OUTPUT/$PRGNAM-${VERSION}_debugsymbols-$ARCH-$BUILD${TAG}.${PKGTYPE:-tgz}
find . -name *.debug -delete
find $OUTPUT/ -size -50c -name $PRGNAM-${VERSION}_debugsymbols-$ARCH-$BUILD${TAG}.${PKGTYPE:-tgz} -delete

CHANGED TO:

Code:

PKG_DEBUG=$TMP/debug-$PRGNAM
mkdir -p $PKG_DEBUG
DEBUGDIR=`find . -type d -name .debug`
cp -r --parents $DEBUGDIR $PKG_DEBUG
find . -name *.debug -delete
cd $PKG_DEBUG
makepkg -l y -c n $OUTPUT/$PRGNAM-${VERSION}_debugsymbols-$ARCH-$BUILD${TAG}.${PKGTYPE:-tgz}
rm -rf $PKG_DEBUG

Seems to segregate fine. I don't have the weird date stamps and when opened in Ark the ownerships all read root regardless of who views the package contents. I still have to install and find a known bug to verify I can produce a meaningful backtrace.

Darth Vader 12-30-2011 12:00 PM

Quote:

Originally Posted by Woodsman (Post 4561765)
I am root --- in a chroot. That's the mystery. :)

Well, being root in chroot is not exactly the same situation as being root directly, because bash don't read its configuration files, I believe.

Anyway, to trick the chroot to behave like a direct login, I use

Code:

chroot $NEWROOT su -l

Woodsman 12-30-2011 12:57 PM

Quote:

chroot $NEWROOT su -l
Yup, that's what I do. :)

ruario 01-02-2012 03:58 AM

Quote:

Originally Posted by gnashley (Post 4561545)
tar-1.13 has a couple of unique behaviours which are essential to creating a proper Slackware package -no other version exhibits the desired characteristics. It works perfectly, so there is no need to worry yourself about eh old version number.

For package creation only one characteristic matters and that is the formatting of the storage of subdirectories of '.', which can easily be simulated with more modern versions of GNU tar.

@Woodsman Here is a comparison so you can see the difference.

GNU tar 1.13:
Code:

$ tar -cvzf ../test.tgz .
./
install/
install/slack-desc
usr/
usr/bin/
usr/bin/example

GNU tar 1.26:
Code:

$ tar -cvzf ../test.tgz .
./
./install/
./install/slack-desc
./usr/
./usr/bin/
./usr/bin/example

It is relatively trivial to work around this problem using tar's transform option and a regex to make modern tar save the directories in tar 1.13 format, e.g.:

GNU tar 1.26:
Code:

$ tar --transform="s,^\./\(.\),\1," --show-stored-names -cvzf ../test.tgz .
./
install/
install/slack-desc
usr/
usr/bin/
usr/bin/example

Alternatively, on a system with a tar more modern than 1.13 but not modern enough to have the transform option, you could pre-format the list of directories by using find and sed and then pipe this to tar instead:

Code:

$ find ./ -print | sed "s,^\./\(.\),\1," | tar --no-recursion -T- -cvzf ../test.tgz
./
install/
install/slack-desc
usr/
usr/bin/
usr/bin/example

As a third alternative, you could make use of cpio's ability to save in ustar (The POSIX.1 tar) format and send it the formatted list instead:

Code:

$ find ./ -print | sed "s,^\./\(.\),\1," | cpio -ovHustar | gzip > ../test.tgz
./
install/
install/slack-desc
usr/
usr/bin/
usr/bin/example
8 blocks

There are other methods as well but you get the idea. ;)

I have thoroughly tested these methods of tar-1.13 style directory formatting and had no issues whatsoever. Slackware's pkgtools cannot tell the difference and treat the packages created exactly the same way as files created with tar 1.13.

P.S. There is a whole thread about why tar 1.13 is used. It is long but an interesting read.

Alien Bob 01-02-2012 04:08 AM

The file listing is only one of the issues and indeed that can be circumvented. But the difference in handling of symbolic links is the reason for sticking with tar-1.13. If you ever upgrade a package containing for instance a "/usr/share/man" directory then you will see what happens when upgradepkg uses plain tar instead of tar-1.13.

Eric

ruario 01-02-2012 04:49 AM

Quote:

Originally Posted by Alien Bob (Post 4563629)
The file listing is only one of the issues and indeed that can be circumvented. But the difference in handling of symbolic links is the reason for sticking with tar-1.13. If you ever upgrade a package containing for instance a "/usr/share/man" directory then you will see what happens when upgradepkg uses plain tar instead of tar-1.13.

Sure, but I specifically italicised package "creation". ;) Installation does indeed have other issues if you were to try and take tar-1.13 out of Slackware. I wasn't suggesting or advocating that.

Edit: The summary from the thread I linked earlier was that pkgtools could in theory use a modern tar if you made certain changes. IIRC, in addition to handling the differences in formatting sub-directories of '.', installpkg's extraction would also need to be altered (i.e. to no longer use '-l' '-U' as their meanings have changed).

One of the conclusions from Patrick's comments was that he doesn't do this as it is less maintenance to stick with one version of tar that reacts exactly as his tools expect, rather than having to update them again every time the GNU tar authors decide to change (or break) something. Which seems entirely sensible, so no complaints from me.

Since pkgtools is likely to stick with tar 1.13 for the foreseeable future, when making packages I agree it is best to use makepkg where possible otherwise you have to remember to handle directory formatting accordingly (and you would also have to handle conversion of symlinks to shell script format).

P.S. As a side note, I actually occasionally use spkg (the reimplemnation of pkgtools that SalixOS uses) on other distros as a kind of secondary package manager for handling any software I build from source. I do this because it is far easier to create Slackware packages than any other common format. However, since spkg does not provide a makepkg, I knocked up a very basic makepkg, which only handles directory formatting and conversion of symlinks to shell script code, since these seem to be the only things that SlackBuild scripts typically use makepkg for these days.


All times are GMT -5. The time now is 05:16 AM.