LinuxQuestions.org
Register a domain and help support LQ
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 12-29-2011, 02:45 PM   #1
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,472

Rep: Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523
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!
 
Old 12-29-2011, 03:30 PM   #2
Cedrik
Senior Member
 
Registered: Jul 2004
Distribution: Slackware
Posts: 2,140

Rep: Reputation: 242Reputation: 242Reputation: 242
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

Last edited by Cedrik; 12-29-2011 at 03:31 PM.
 
Old 12-29-2011, 03:40 PM   #3
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 226Reputation: 226Reputation: 226
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
 
1 members found this post helpful.
Old 12-29-2011, 08:57 PM   #4
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,472

Original Poster
Rep: Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523
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!
 
Old 12-30-2011, 02:00 AM   #5
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,746

Rep: Reputation: 458Reputation: 458Reputation: 458Reputation: 458Reputation: 458
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.
 
Old 12-30-2011, 04:08 AM   #6
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 226Reputation: 226Reputation: 226
Quote:
Originally Posted by Woodsman View Post
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
 
Old 12-30-2011, 09:18 AM   #7
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,472

Original Poster
Rep: Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523
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.
 
Old 12-30-2011, 12:00 PM   #8
Darth Vader
Member
 
Registered: May 2008
Location: Romania
Distribution: DARKSTAR Linux 2008.1
Posts: 593

Rep: Reputation: 108Reputation: 108
Quote:
Originally Posted by Woodsman View Post
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

Last edited by Darth Vader; 12-30-2011 at 12:02 PM.
 
Old 12-30-2011, 12:57 PM   #9
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.0
Posts: 3,472

Original Poster
Rep: Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523Reputation: 523
Quote:
chroot $NEWROOT su -l
Yup, that's what I do.
 
Old 01-02-2012, 03:58 AM   #10
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,795

Rep: Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803
Quote:
Originally Posted by gnashley View Post
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.

Last edited by ruario; 01-02-2012 at 04:19 AM. Reason: simplified to avoid confusion
 
Old 01-02-2012, 04:08 AM   #11
Alien Bob
Slackware Contributor
 
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 5,184

Rep: Reputation: Disabled
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
 
Old 01-02-2012, 04:49 AM   #12
ruario
Senior Member
 
Registered: Jan 2011
Location: Oslo, Norway
Distribution: Slackware
Posts: 1,795

Rep: Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803Reputation: 803
Quote:
Originally Posted by Alien Bob View Post
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.

Last edited by ruario; 01-02-2012 at 05:49 AM. Reason: added some more thoughts; spelling
 
  


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
debug symbols dudkosk Linux - Newbie 3 07-28-2011 07:42 AM
Others have gdb debug symbols but I don't... williawh Programming 7 01-26-2011 08:55 AM
[SOLVED] KDE debug symbols igadoter Slackware 2 06-27-2010 02:21 AM
Not able to get the debug symbols when process crashes meganath831 Programming 1 07-18-2008 03:00 AM
Building with debug symbols? Omni Programming 3 08-29-2006 08:11 AM


All times are GMT -5. The time now is 09:53 PM.

Main Menu
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
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration