LinuxQuestions.org
LinuxAnswers - the LQ Linux tutorial section.
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 03-29-2012, 12:49 PM   #1
FeyFre
Member
 
Registered: Jun 2010
Location: Ukraine, Vinnitsa
Distribution: Slackware
Posts: 308

Rep: Reputation: 22
Question [dead question] Unstripped binaries?


Hi

Since I am not only ordinary desktop user, but software developer, I'm very interested in full versions(where it is possible) of software on my development and testing boxes. Under "full versions" I mean virgin binaries as they were born by builder and/or additional data files which can provide me all possible information about binaries, which is normally excluded or intentionally not included into packaging/distribution. In two words: debugging information.
So question: can I and where can I get such of/from Slackware distribution?


regards, FeyFre
 
Old 03-29-2012, 01:02 PM   #2
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,474

Rep: Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901
you will have to rebuild the packages you need with debugging turned on and avoid stripping them, modifying the corresponding slackbuilds: you will usually find debug turned off explicitly.

build scripts are made for end users that don't need heavier binaries/libraries with debug information (and gotta say that usually also developers don't like a slow O.S. )

Last edited by ponce; 03-29-2012 at 01:12 PM.
 
Old 03-29-2012, 04:07 PM   #3
FeyFre
Member
 
Registered: Jun 2010
Location: Ukraine, Vinnitsa
Distribution: Slackware
Posts: 308

Original Poster
Rep: Reputation: 22
Quote:
you will have to rebuild the packages you need with debugging turned on and avoid stripping them, modifying the corresponding slackbuilds: you will usually find debug turned off explicitly.
Yes, I know I can. But consumed time almost equal infinity to achieve that.
Quote:
build scripts are made for end users that don't need heavier binaries/libraries with debug information
Well, storage size is not problem any more. And it is possible to strip-out most debug info, but it is impossible to recreate it from nothing. If user do not care about space. They always can run famous "find $ROOT | xargs file | grep -e "executable" -e "shared object" | grep ELF | cut -f 1 -d : | xargs strip --strip-unneeded" as post-install action(in the same stage as creating initrd)
Quote:
and gotta say that usually also developers don't like a slow O.S.
OS speed have nothing with developers' love. That is end-user illness, not developers' one. Vice versa, slower development OS - more time left for developer to think out his task. In any case, presence of debug-info practically does not influences performance - another few second to load program does not make any problems, but another two hours to figure-out what means that segfaulted offset in that 3rd-party module does.
 
Old 03-29-2012, 10:09 PM   #4
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Slackware does not provide a separate debugging symbols package. Writing the build scripts to support both would seem a nice win-win for everybody. Perhaps this thread will help:

http://www.linuxquestions.org/questi...ackage-921106/

If building only for yourself, you could comment out the stripping commands in the build scripts and add the appropriate cmake/automake debugging option to the build flags. Yeah, I know, a lot of work to rebuild everything. Been there, done that.
 
Old 03-30-2012, 02:48 AM   #5
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,771

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
One assumes that if the end-user knows what to do with debugging binaries, then he will certainly know how to create them. Hats off to those distros which *do* provide debug packages separately -but what a job to maintain them! Slackware used to provide a debugging package for glibc, but no longer does.
 
Old 03-30-2012, 10:44 AM   #6
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Quote:
but what a job to maintain them!
Indeed. Sometimes I wish the stock Slackware build scripts, or those scripts provided by the main repositories, would design the scripts so users could rebuild the packages along with a separate debugging symbols package. The default would be not to create them, but with a change in a single environment variable users could create the additional package. Just a wish.
 
Old 03-30-2012, 11:46 AM   #7
FeyFre
Member
 
Registered: Jun 2010
Location: Ukraine, Vinnitsa
Distribution: Slackware
Posts: 308

Original Poster
Rep: Reputation: 22
Quote:
One assumes that if the end-user knows what to do with debugging binaries, then he will certainly know how to create them.
As I said already, despite I know how to use "debugging binaries", I don't know how to create the from NOTHING. Yes, I can rebuild binaries from source but that will be other binaries no the same as in distribution, so any debugging information is unusable.
Quote:
The default would be not to create them, but with a change in a single environment variable users could create the additional package. Just a wish.
Little trick, which lefts unstripped binaries after SlackBuild(substitute strip by non-harmful binary)
( STRIP=$(which strip) ; mv "$STRIP" "$STRIP-real"; ln -s $(which true) $STRIP )
Spent a few hours to find possibility to set global flags for gcc/g++ - failed.
 
Old 03-30-2012, 12:02 PM   #8
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,474

Rep: Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901
Quote:
Originally Posted by FeyFre View Post
I don't know how to create the from NOTHING. Yes, I can rebuild binaries from source but that will be other binaries no the same as in distribution, so any debugging information is unusable.
why nothing? if you build them from the sources editing the slackbuilds (for CFLAGS, debug options and removing/commenting the stripping section) they will be like the distributed ones but with usable debug informations.

Quote:
Little trick, which lefts unstripped binaries after SlackBuild(substitute strip by non-harmful binary)
( STRIP=$(which strip) ; mv "$STRIP" "$STRIP-real"; ln -s $(which true) $STRIP )
Spent a few hours to find possibility to set global flags for gcc/g++ - failed.
I'm afraid you can't avoid editing the slackbuilds.
 
Old 03-30-2012, 12:36 PM   #9
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,771

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
"if you build them from the sources editing the slackbuilds (for CFLAGS, debug options and removing/commenting the stripping section) they will be like the distributed ones but with usable debug informations" Unfortunately, this is not really true on Slackware. You'd have to rebuild them with the same mix of already-re-compiled libraries which were in use *at the time* the official build was made -which could be anytime during the last few years. Building the same versions from the same SlackBuilds is in no way a guarantee that you will get the same result as the standard package. This is because things only get re-compiled when 'needed' -which usually means when a bug/segfault gets noticed and reported by someone. In other words, binary compatibility and consistency is a hit-and-miss proposition.
 
1 members found this post helpful.
Old 03-30-2012, 01:26 PM   #10
ponce
Senior Member
 
Registered: Aug 2004
Location: Pisa, Italy
Distribution: Slackware
Posts: 2,474

Rep: Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901Reputation: 901
you're right Gilbert, I exxagerated a little ;P
 
Old 03-30-2012, 09:41 PM   #11
Woodsman
Senior Member
 
Registered: Oct 2005
Distribution: Slackware 14.1
Posts: 3,482

Rep: Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534Reputation: 534
Quote:
Little trick, which lefts unstripped binaries after SlackBuild(substitute strip by non-harmful binary)
( STRIP=$(which strip) ; mv "$STRIP" "$STRIP-real"; ln -s $(which true) $STRIP )
Spent a few hours to find possibility to set global flags for gcc/g++ - failed.
Comment out the stripping commands in the build script. Then add the following environment variables:

automake: DEBUG_AUTOTOOL_OPT="--enable-debug=full"
cmake: DEBUG_CMAKE_OPT="-ggdb"

For automake packages the $DEBUG_AUTOTOOL_OPT variable gets added to the ./configure options as another option.

For the cmake packages the $DEBUG_CMAKE_OPT variable gets added to the -DCMAKE_CXX_FLAGS option like this:

-DCMAKE_CXX_FLAGS:STRING="$CPUOPT $DEBUG_CMAKE_OPT"

Doing those steps will create a larger single package, but as long as you are building for your own purposes or limited distribution, everybody will be happy because they then can use the debugging symbols.

Be forewarned, in some case the new package will be significantly larger.
 
Old 03-31-2012, 02:29 AM   #12
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,771

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
"significantly larger" can be up to 300 times larger in some cases! Not very ofetn, I'll admit, but it does happen. Usually it i2 more like 50%-100% larger.
 
Old 03-31-2012, 06:52 AM   #13
wildwizard
Member
 
Registered: Apr 2009
Location: Oz
Distribution: slackware64-14.0
Posts: 755

Rep: Reputation: 227Reputation: 227Reputation: 227
Quote:
Originally Posted by gnashley View Post
Unfortunately, this is not really true on Slackware.
Not sure where your going with this.

If you recompile library A with debugging symbols kept in, you now have library A with debugging symbols and will then see them when using gdb, et al.

You will however have to recompile everything in the dependency chain to see everything or some symbols will have a very nondescript number instead of a name.

Quote:
In other words, binary compatibility and consistency is a hit-and-miss proposition.
This is a bit more of an issue, as recompiling library A may actually stop the error that your trying to debug.
 
Old 03-31-2012, 08:53 AM   #14
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,771

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
What I mean is this. Take the gtk2 libraries for instance. There is no way to tell which version of glib2, glibc, etc was installed when they were compiled. It is quite likely that it was linked against a previous version of its' requirement, than the ones which are installed right now -whether you are running current or any of the standard install mixes. Slackware rarely recompiles dependent libraries when a library which is depended *on* gets upgraded, patched or re-compiled. Just in the last few days there has been a thread here where some program was segfaulting until it was re-compiled against the just-upgraded glibc -IIRC.

My point is that when you re-compile a Slackware source, you may or may not get resulting binaries which are functionally equal to those contained in the official package for that version. Compile-time configuration options and the mixture of what is installed and not installed at compile time can also effect the functionality/content of the resulting binaries.
 
  


Reply

Tags
debug


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
question about different checksum of binaries marozsas Linux - Security 8 08-23-2010 01:38 PM
[SOLVED] how does unstripped version help in ffmpeg sumeet inani Linux - Newbie 4 02-13-2010 04:41 AM
Dead Pixel Question Daedra Slackware 1 10-18-2006 07:58 AM
Yum & "Core Binaries" Question The00Dustin Linux - Software 2 09-26-2006 12:15 PM
question about installing binaries correctly jimjamjahaa Linux - Software 4 05-11-2006 03:09 AM


All times are GMT -5. The time now is 01:14 AM.

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