[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

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

Yes, I know I can. But consumed time almost equal infinity to achieve that.
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) 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.

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

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.

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

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

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.

I'm afraid you can't avoid editing the slackbuilds.

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

you're right Gilbert, I exxagerated a little ;P

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

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

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.

This is a bit more of an issue, as recompiling library A may actually stop the error that your trying to debug.

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.